cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: [RT] forms
Date Thu, 19 Jul 2001 12:11:31 GMT
On 18.Jul.2001 -- 06:38 PM, Torsten Curdt wrote:
> > Well, I would like to tackle forms in a vew days, but frankly,
> > I would reckon multipage forms to be too complex for an initial
> > release...
> I don't think it will make much sense to try a simple form
> first when we don't have an idea which direction to go!

To quote XForms WD 8.5:

 As the name implies subpage is not specific to XForms--our intent is
 to design subpage so that it can be used within XForms--and more
 generally within XHTML to create presentations where document views
 are presented to progressively reveal the document structure and

So this is perhaps an issue external to forms. Of course such a thing
is translatable to XSP code plus an actions that keeps feeding the
same XSP until the last subpage has been shown.

> > I would prefer a "XForms logicsheet" or a "XForms stylesheet" to
> > anything else. After all, you will probably want to use it on XSP.
> As far as I was teached ;) XSP should be not a lot more than presentation
> logic! A XForms Logicsheet would probably put a lot more logic into
> the XSP pages than necessary.

I'm not sure about that. Forms are 70% markup (-> stylesheet) plus
some housekeeping, e.g. filling the form, switching between views, and
some 35% validation (-> action).

> > Of course this does not rule out a FormTransformer but I'm not sure
> > about a FormPopulator -- a transformer might work as well. But I feel
> > that's not within the scope of such a package.
> What package should do it then?

I think it will be a combination of action(s) + logicsheet + stylesheet

> So how would you address some of the common problems?
> 1. making a form stateful (keeping the input of e.g. textboxes and comboboxes)

Read request parameters to fill in the form. Add a special parameter
to the form, to find out if the user has seen the form before.

> 2. prevent a combobox be filled from the database on each request

Hard one. I think it's not sensible to do. The DBMS should cache
frequent queries, it would be a bit like reinventing the wheel to do
our own caching. Especially, as we can't have a clue if the underlying
table has changed in between.

> 3. have a media independent definition of forms

XForms does that.

> 4. i18n of the form label/captions

No problem to combine i18n with arbitrary tags.

> 5. i18n of the comboboxes (they probably need to load their options on change of the

Again, that's a problem of the i18n package, not of forms.

> 6. the most important thing: multipage form navigation

If you insist, this could be done by

   	 <caption> Part I</caption>
   	 <caption> Part II</caption>

translated to

     switch (RenderView) {
     case 1:
     case 2:

Plus an action that allows to advance only if the current view has
been validated OK.

> I'd really like to get rid of the PHP style of form coding...

Sure, but that's why an XSP should contain only one view of a page and
the decision should be made in the sitemap.

> I'm with you to get this on!

Great! I will definitely need help on this. At the moment I'm struck
with some action coding doing it the avalon way and after that I will
concentrate on forms. I hope that'll be top of next week.

It would be great to discuss some of the issues raised in the
discussion on cocoon-user in more detail. Especially if we want to
(re-)construct an XML representation of the request parameters before
processing them. That would enable us to delegate the validation to
xerces, I think. But it might be expensive in terms of computing
resources. OTOH it's required for XForms compliance.


C h r i s t i a n       H a u l
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

To unsubscribe, e-mail:
For additional commands, email:

View raw message