[Zope] "Dialog Boxes" entity in Zope ( Re: Still trying. )

[Paul T]

> > "Components need not be persistent, nor provide a management interface." -
> I think
> > this is a mistake. They should. Any component / bean has to be configured
> > and the best way for the end user is to configure it through the GUI.
>  Windows 3.0 ).
> 
> Not necessarily.  Take for instance a component "XMLParser".  There's no
> configuration that needs to be done to it.  It's a black box.  It needn't be
> persistent, because it is instantiated on the fly as needed.  It needn't be
> configured because there are no knobs to it.  Yet it has an introspectable
> interface.

There is no black boxes in this world, I think.

Even XMLParser could be configured. Ideally, each and every component in 
this world has at least one confugurable property.  Debug="on/off"  and it 
is convinient if this property could be set from the GUI at any point of time.

For XMLparser it can also be "Validating/non-validating". In fact, it could also be :
"report all the errors into separate log-file". Not talking about configurable 
extrenal entity resolver ( for complex XML cases ). Also it could be "cache
the XML file storing it into SAX-bytecode to avoid the parsing" e t.c. e t.c. 

Well, in fact, even it is not a big deal to make Zope's log-file rotating, 
hacking the z2.py with rotating_file_logger(LOG_PATH, freq='daily'),
I think you should agree that this configuration should be done with the 
GUI. 

I agree that there are some entities which will have no need in GUI configuration,
but I think the number of those entities is actually small and ( more important )
I'm interested *not* in such entities, but in the easy way of building some really 
trivial thinghs ( like TutorialPoll ) in straightfoward way in the assumption, 
for example,  that each such thing will have not more than just one configuration 
screen, but it seems that this configuration screen *has* to be in the design.

Again - think about Windows 3.0. For complex things there was Window, 
for 'no-GUI' things there is no APIs, but there was also Dialog box! Modal
Window with straightforward auto-adjustable GUI.

Current Products are 'Window'
Components are 'no GUI'

I'm talking about the 'Dialog Box'  things. 

Again - if we're talking about turning Zope into unbeatable "Windows 3.0".

> Some instances of components will definitely need to be configured via a GUI
> (just like Products are now).  But the definition of "component" as it
> stands is just an object with an introspectable interface.  What we think of
> now as "Products" will likely be special components that happen to offer a
> web interface (possibly via one or more "adapters") and a set of
> instantiable classes.  But some components may not offer a web interface,
> and others may not offer persistent instantiable classes.

This means there is simply no entity for the "Dialog Box" because 
I'm talking neither about the Producs, nor about the Compoments, but 
about the 'Simplified Products'.  ( TinyTable, ParsedXML e t.c. )

> > I understand the desire to stay out of XML, but try to use simple text
> formats.
> > The problem is that simple text formats do not scale.
> >
> > I mean that
> >
> > requires "Zope" "2.3" or better
> > requires "FooProduct" "1.0" exactly
> > requires "SpamProduct" "0.1" or "0.2" or "0.5"
> >
> > could occasionally become
> >
> > requires "FooProduct" "1.0" exactly
> > requires "SpamProduct" "0.1" or "0.2" or "0.5"
> >
> > exports "something_here"
> >
> > Or  god knows what. Designing really good ProductDescriptor
> > It is like designing the *darn* complex  SQL  schema and going
> > with the "simple table" first in the hope that it will be possible
> > to tune the schema "when needed" may by suspicious step.
> 
> This needs to be thought out more.  We need to understand the requirements
> better, and work out a design.  Will the product machinery need to resolve 
> circular dependencies?  What does "or better" mean?  This is something for
> the Fishbowl at http://dev.zope.org.  The design step is the hardest part,
> and this is where we can use the most help!

I see two things here.

1. 'Dialog Boxes' ( simplified Products with GUI )
2. 'CPAN' ( first - for Dialog Boxes )

I think it could initially all the things could be placed in just 
one ProductDescriptor.XML file This will be a foundation for 
most complex things and will significantly decrease a mess. 

BTW - writing XML for DialogBoxes could be done manually with no 
problem. No need in any tool. 

1. Write The Python file which implements the  
semantics of TrivialPoll. 

2. Write the XML, describing dependecies 
and configurable things ( This describes Zope integration )

Pretty clear separation, no ?

The interaction with Zope  will be generated for you. 
( this is the point ).

I think this may help to productize a lot of things.

> > What particular list is appropriate for this discussion?
> 
> The Zope list probably (zope@zope.org).  Amos Lattierer asked for comments
> on the roadmap document on the Zope list, so it's certainly on-topic.

Rgds.Paul.

PS. See also.

http://www.pault.com/X/983148775/index_html
http://dev.zope.org/Wikis/DevSite/Proposals/FinishedProductGuidelines