[Gobble-dev] gobble is ...

[Hannes Wallnoefer]

Andreas Bolka wrote:

>three observational approaches:
>
>1) ... a web application comprised of
>- a wiki-style "page"-concept and gong-style linking (*pagename*)
>- hiearchies: every page is also potentially the parent of n other
>  pages
>- forms: every page has an associated type which determines it's
>  how it will be rendered for display and for editing.
>- granular (page-level) access control
>  
>

There's even sub-page-level per-property access control. You can use it 
to have some form properties only edited by specially authorized persons.

>2) ... an extension of helma concepts for web application
>_development_ onto an web application itself. this comes to mind, if
>we consider forms to be "classes" or "prototypes". pages are objects
>(instances) that can have multiple child-pages (helma-like). 
>

Yep, that's right.

>obviously
>not (yet?) present in gobble is a way to associate actions with
>forms/objects.
>
>  
>
No, you can't currently add extra actions to forms. But I'm not even 
sure that would be needed.

On the one hand, you can still make extended Item prototypes in the 
classic Helma style if you need it. Helma-style sub-prototypes and 
Gobble forms coexist and complement each other in Gobble, in fact both 
User and Form are "classical" Helma extended prototypes, because the 
required functionality would have been too heavy for the Form approach.

On the other hand, the functionality of an item's main page will be very 
flexible using flexible macros (that don't yet exist ;-). It should be 
easy to query child Items according to Form/properties and display using 
any combination of custom skins.

>under this aspect, gobble stands in an interesting light compared to
>e.g. zope or microsoft access.
>
>
>3) taking thought 2) even further, one could state that "gobble is
>naked objects for the web"
>  
>

Although this sounds slightly like an insult, I guess it may be true ;-)

>ps: excuse me if this sounds weird :) those are just some thoughts
>floating around in my brain for a while. also note that i do not claim
>those approaches to be anywhere near the "truth" or even near hannes'
>intentions of what gobble ought to be. further, do not hesitate to
>correct or add to the above. finally, i have not had a look at the
>source to gobble (yet) ...
>  
>

No worry, that's what this list is for.

Another aspect of Gobble that seems important to me is the goal to limit 
interfaces through which objects interact. Two pages which further 
explain this goal:

http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage   (RESTWiki)
http://www.namesys.com/v4/v4.html#why_strictly    (ReiserFS)

Helma always had some of this by making everything a HopObject, with its 
simple add(), get() and remove() semantics. However, that implementation 
had two shortcomings:

    1) Although it tried, it didn't really work the same across embedded 
and relational db. Before Gobble (or the bugfixes in Helma that it 
brought about ;-) you had to write extra code for embedded or relational 
db. Now with gobble, you just drop in a Zip file with some extended 
type.properties and you switch from embedded db to relational, same 
code, same features.

    2) Although the HopObject interface is shared by all persistent 
objects, applications usually work with special prototypes that need 
special kind of handling. Thus, you need to build an ImageManager to 
manage Image objects, a SkinManager to manage Skins, a StoryManager to 
manage Stories and so on. And you always start from zero (the more or 
less blank HopObject), reimplementing the same kind of functionality 
again and again. Gobble solves this by making everything an Item, which 
knows how to manage itself, so every extension or new feature starts 
much higher up, and everythign turns out simpler and more flexible.

In addition to the basic edit/list/new/manage/remove functionality in 
Item I just implemented a general feature to create typed directed links 
between any two Items, which can be used by application code through a 
simple API. This will be pretty cool, more on it later today when I 
check it in.

Well, I hope this makes sens, at least some sense to some of you ;-)
hannes