cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mr Quinn" <jer...@apache.org>
Subject Re: svn commit: r694389 - /cocoon/branches/BRANCH_2_1_X-dojo1_1/src/blocks/forms/resources/org/apache/cocoon/forms/resources/
Date Sat, 13 Sep 2008 20:27:01 GMT
Hi Guys
The first problem is that the changes are not complete yet, furthermore
there needs to be a cleanup and rationalisation of these xslts. I think
eventually that 'forms-field-styling' should provide only the subset of
renderings of Cocoon Widgets to work in a non-Dojo/non-JS environment (plus
common non-js templates), while forms-advanced-styling (and it's includes)
will provide rendering for the Dojo environment. This way you can choose to
have a plain html simple rendering or a full-blown Dojo rendering by
choosing between those two XSLTs from your application's forms XSLT.

In general the changes are :

1. Moving status reporting to the client-side widgets. Meaning the XSLT no
longer adds "*", "!" required and error markers itself, it sends status and
messages to the widget, which then shows it. This is to support client-side
validation and allow for a cleaner visual design with a much more powerful
level of control from CSS, inherited from Dojo.

2. Pretty much every Cocoon Widget has an equivalent client-side widget.
Most of the changes and additions to the XSLT are to do with deciding what
widget to make based on it's state and meta-data (fi:styling, fi:datatype
etc. and eventually fi:validation), then rendering it in a way that allows
it to become a client-side Widget. Requiring the right classes, setting the
@dojoType, adding attributes, validation constraints and inner data to allow
the widget to build.

3. All BrowserUpdate ids now have a ':bu' suffix to remove all potential ID
conflicts (BU tags and Widgets often shared the same ID).

4. New Group stylings. New Repeater rendering, generic DnD handler and
control params. New FlowScript Lib for making JS Objects Suggestable. New
Editors for datatypes: richtext, validating text, numbers, currency, date,
time, suggestion selects etc. etc.. More Widgets on the drawing
board. Several old Widgets yet to be deleted.

As far as possible, the cocoon.forms.* are a thin wrapper on their
dijit.form.* equivalent, to adapt the Dojo Widgets to the legacy CocoonForms
environment. As few changes to existing parameters as possible. As few
additional parameters as possible. As much code-reuse as possible via the
set of Mixins (Dojo Widgets commonly use multiple inheritance).

The mapping from Cocoon Widgets to Dojo Widgets is still incomplete. No
Multiselects yet, not everything is ErrorAware yet (file inputs and a few
others). No combined DateTime field yet, FilteringSelect using JS-based
suggestion-list in-Widget not working yet. An loads of other niggles.


Far from complete, but I hope it helps as a start.


regards Jeremy

On Sat, Sep 13, 2008 at 12:51 AM, David Crossley <crossley@apache.org>wrote:

> Joerg Heinicke wrote:
> > Grzegorz Kossakowski wrote:
> > >>
> > >>URL: http://svn.apache.org/viewvc?rev=694389&view=rev
> > >>Log:
> > >>many changes to cforms xslt, many more to come
> > >
> > >Jeremy,
> > >
> > >before I dive into your changes could you give more descriptive overview
> > >of these changes. It would be great if you could outline the most
> > >important changes or at least give some reasoning why your changes were
> > >necessary.
> > >
> > >I know that this is tedious but for some else such piece information is
> > >crucial and recovering it himself is even more tedious.
> >
> > Don't be too strict, Grek ;-)
> >
> > With such major changes it's hard to separate them from each other.
> > Sometimes it's just not feasible.
>
> I know what Grek is saying though. If the committer can
> manage to prepare a little summary, even if not complete,
> then it has manifold benefit for those trying to follow on.
> Easier for the original developer to describe.
> The words might even lead to documentation.
>
> -David
>

Mime
View raw message