cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reinhard Poetz" <reinh...@apache.org>
Subject Thoughts on Woody ...
Date Tue, 21 Oct 2003 08:06:44 GMT

After (nearly) finishing a project where we implemented our own little
forms frameworks (... we had already started when Woody became part of
Cocoon) I want to share some ideas with you.

To be able to make a comparisons I dived into the current implementation
of Woody. Now I can say that I'm really impressed by the architecture
and I also like it very much *how* you did it.

So here a few (random) thoughts what could be useful for Woody:

Global widget definition repository 
-----------------------------------

Currently we have a strict binding between widget definition and the
template where the widgets are instantiated:

         1           :           1
   +------------+         +------------+
   |            |         |            |
   |   widget-  |         |   widget-  |
   |  defintion | ----->  |  instances |
   |            |         |            |
   |            |         |            |
   +------------+         +------------+
 
This goes so far that all defined widgets must be instantiated in order
to get no (hidden) errors during validation. This also means for
applications that consist of more than one form you sooner or later have
to define your widgets (e.g. an email address) as often as you
instantiate them.

I think we should decouple this behaviour into following:


   +------------+ 
   |            | 
   |   global   |
   |   widget   |\
   | repository | \
   |            |  \
   +------------+   \use
         |           \
         | ext        \
         V             \
   +------------+       \ +------------+
   |            |         |            |
   |   widget-  |  use    |   widget-  |
   |  defintion | ------- |  instances |
   |            |         |            |
   |            |         |            |
   +------------+         +------------+


The global widget repository contains widgets that can be reused in all
forms within your Cocoon installation. I also think that it could be
possible to extend global widget defintions:

  <wd:field id="glEmail" required="true">
    <wd:datatype base="string">
      <wd:validation>
        <wd:email/>
      </wd:validation>
    </wd:datatype>
  </wd:field>

  <wd:field id="supplierEmail" extends="glEmail">
    <wd:label>Supplier's email address:</wd:label>
  </wd:field>

  <wd:field id="customerEmail" extends="glEmail">
    <wd:label>Customer's email address:</wd:label>
  </wd:field>


Multi page forms
----------------

We have already discussed this several times on the dev-list and at the
GetTogether in Gent. IIUC Thorsten, Bruno and I agreed that we don't
like some kind of a "phases" concept because everything you need can be
found at the template and why should you declare things twice. If you
think of dynamic forms (e.g. wheter a widget is show depends on the
rights of the user) you also come into troubles because your phases will
have to become dynamic too!

As mentioned the list of the required widgets is already known because
the template transformer instantiates all widgets. But there is a
problem (or at least I'm not sure how to solve it) with this approach:
The template transformer is the last step before a new continuation is
created. So it would be possible to save a list of all required widgets.
That's fine. The problem is that this list has to be connected to a
certain continuation because otherwise you would get serious troubles if
the user clones the window. OTOH if we save the list of the required
widgets with the continuation it can become expensive from a memory POV,
can't it?

Are there other thougts how to solve the multi page forms problem? 
Sylvain, you mentioned at the end of your presentation something at the
GT Hackaton but I can't remember. Could you help us (me)?


Lookup values
-------------

We already have some helpers to make it easy to enter correct data into
your fields. One thing missing is the possibility to lookup values.
Suppose you have a field "country". One possibility would be to a drop
down field the other possibility a usual input field with an icon on its
right side. If you click on this icon another window opens (inline like
in Eclipse or a popup) and you get a list of all countries. You can
select one and the value is copied into the main form. So what's the
advantage compared to a selection list:

 * You don't need to load such a long list like all countries
   in the world at form load time but then when the user
   wants to fill in the value
   (this makes no real difference for one field but if you have e.g.
    10 fields containing so many possible values there is one, believe
me!)
 * You can provide additional information: e.g. you have to
   select a customer - you could show the address, the birthdate, ...
   to make the choice for the user easier
 * You can structure your date  e.g. you can create
   a tree where all countries can be found in a tree
 * You can provide help when a selection list is not
   good enough. Think of a search form e.g. you can search in your
   customers database for the right one and select it. The
   selected customer is filled in the form.
 * You can fill in more than one field with one selection (think
   of a row in a table --> with one selection the whole row
   could be completed)


Thoughts?

Cheers,
Reinhard

P.S. Thanks to Michael Gerzabek because the first and the third point
are definitly inspired by him :-)



Mime
View raw message