[Zope3-dev] Re: A possible component architecture interpretation of workflow

[yuppie]

Hi Jim!


Sorry for ignoring the 'workflow' part of your "collection of thoughts", 
but it's easier for me to approach this from the 'form processing' 
perspective.

Jim Fulton wrote:

> yuppie wrote:
> 
> [...]
>> There are different kinds of buttons. While most buttons are used to 
>> invoke controllers, there are other buttons that just modify views or 
>> redirect to other views.
>>
>> I guess the most common case is the "Search" button. Other examples 
>> are the 'Import/Export' button in Zope 2 or the 'New...' button in CMF.
> 
> 
> But typically these buttons would point at different pages anyway, so
> they wouldn't affect the form.

That might be the case with 'Search' buttons. But the 'Import/Export' 
and 'New...' examples are buttons that are part of the main HTML 'form' 
element. Unless you propose to use ':action' converters or some 
javascript magic they point to the same page as the rest of the 'form' 
element.

> [...]
>> But please don't forget events triggered by links. The 'Undo!' link 
>> would be an example.
> 
> 
> Sure.  Remember the document I sent, while long, was just a sketch.
> It wasn't a proposal. In particular, if this seems to be a good idea,
> the next step is to start fleshing out some details with prototypes.
> 
> ...
> 
>> Wouldn't it be better to configure the UI detail 'button' somewhere 
>> else and to define events for form variables?
> 
> 
> I dunno.  This is a UI we're defining here.  This was just a very
> rough suggestion.  I do think it's a good idea to provide ways
> to specify forms in one place.

Ok. A prototype would be useful to flesh these things out. I'm still 
trying to make myself familiar with Zope 3, but please let me know if I 
can be of any help with that.


Let me try to summarize what already exists for form processing. Please 
correct me if I'm missing something.

1. The pre-processing in zope.publisher.browser:

Similar to what exists in Zope 2. Includes the converter machinery which 
provides some basic form processing, but is not very helpful for 
advanced tasks.

2. The processing in zope.app.form:

A widget/schema based machinery. Quite sophisticated, but not very 
helpful if your forms are not schema based.


Thats all I found. If I understand your new approach right, the result 
would be a new layer between these two existing ones. Based on that new 
layer zope.app.form would become more lightweight and non-widget forms 
could use that machinery as well. Right?


Cheers,
	Yuppie