[Zope-Moz] Re. mozillation project?

[Jerry Spicklemire]

(Disclaimer: You don't EVEN want a listing of all the stuff I don't
understand!)

Shalabh Chaturvedi wrote:

>>Jerry Spicklemire :
>>
>>. . . consider the possibility of providing a GUI Builder with
>> user selectable widgets, which generate component descriptions in a very
>> high level, declarative language.

>(Disclaimer: I do not fully understand the mozillation project or the
inference
>facilities it provides)

>Could you elaborate on this? How different would these widgets be from the
>usual GUI widgets (buttons, editboxes etc)? Why is a high-level declarative
>lanugage needed?

An ease of use feature, something like:

	at top center create title with text = name

	at next line left create dropdown with options type = "file"

	at next line center create input validate with list_users

The old dBaseIII menu based command generator worked this way, but the 
most important feature was the text that appeared at the bottom of the
screen. 
That's where the user could see the command being generated as each 
selection was executed. Sort of like a "Query By Example" SQL generator.

>> The resulting application would in effect
>> be the interpretation of the composite GUI, built by inference from
>> patterns within the Zope Studio RDF. Maybe even the Widgets themselves
>> could be built this way, so that a customizable, "standard" tool set can be
>> available to all content managers of a site.

>I'm not sure if a full-fledged inference engine is required for doing
something
>like this. The way I see it - currently the components used to create an
>application in Zope are not at a 'higher lever' than those that Zope
provides.
>Are you talking of providing the user with 'higher-level' components to build
>appications?

The nice part about an inference engine is that it could inspect available
resources 
and make reasonable "assumptions" about which widgets, and widget properties, 
fit within the context of a folder. As the GUI Builder is operated, the
selections 
available would be inferred from existing resources, so that the user can
only 
choose options that "make sense". Of course, the generated commands could 
be hand edited by the local Guru for finer control, but that should not be
required. 

Since the final product is a description, rather than a bunch of hard coded
objects, 
the application will stay current as resources are updated, replaced, moved.

>If you look at the mokups[1] - in the top left panel there is a tab 'drop-in
>components'. There is no description about it anywhere but I think it will
>provide some components that are not from Zope's 'basic set'. These will be
>build out of the 'basic set' of components. The users will probably be
able to
>add their components to the drop-in components.

>[1] http://www.zope.org/Resources/Mozilla/Projects/MozillaOME/Mockups

Cool!