cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Johnston <>
Subject Re: Cocoon CRUD (was GSoC Proposals)
Date Thu, 11 May 2006 02:55:28 GMT
Simone Gianni wrote:
> Hi all,
> me and Maurizio were very interested in this GSoC too. Unfortunately,
> none of us could apply as a student for it, but it was our intention to
> produce something similar even before it was proposed as a GSoC.
> So, we'd like to share our thought with all the list, and plan to work
> on this starting from the end of this month.
> Jason, you are *obviously* invited to share your thoughts and to
> cooperate in developement as much as you want, we all think cocoon needs
> this stuff done in the best way, as soon as possible, and with friendly
> and open cooperation. So let's merge our efforts in the most productive way.

Absolutely!  I'm glad to contribute ideas to this team effort, more so
than taking it on by myself. :)

There are a lot of really great ideas here!  Much more thorough than
what I'd come up with so far.  I've got a few comments right off; see below.

> Description of our project follows.
> ...
> Since metadata will not be enought to relize a smooth user experience,
> we think that the basic configuration should be, optionally, expanded
> using an XML configuration file that defines:
> 1 - the foreign keys, and/or details on their operation (for example,
> which columns use as labels, wether to use a dropdown, a popup etc..)
> 2 - custom validations
> 3 - custom field styling
> 4 - custom listeners
> 5 - custom javascript/java hooks
> These informations will be used to generate a form definition and
> template. We don't think we will need a binding file, since we will use
> the form to Map paradigm to send and receive data from JDBI and other
> possible implementations of the persistence classes.
> The first three are used to create a cforms Form Definition; starting
> from that, using 4 and 5, the Form Template is created.

Wouldn't 4 and 5 be used to build the definition too?  I'm not sure how
they apply to building the form template.

> As you can see there is no mention of labels. Labels will be delegated
> to i18n, using well defined i18n keys, for example
> label.<table-name>.<column-name> or similar.

I think it's important to allow custom i18n, but to fall back to
reasonable defaults if no i18n is supplied, based on the column names.
Some simple translation should be sufficient, e.g. a column
"recipe_name" would be translated to "Recipe Name".  Then the author
could supply custom i18n translations for "Recipe Name" as key.  Or, if
you prefer, find a way to try finding a label.<table-name>.<column-name>
i18n key, and if it doesn't match then fall back to the "friendly"

>             --- Technical draft ---
> The file generation is performed using a processPipelineTo from the
> JavaFlow, that allows the definition of the Form Definition and/or the
> Form Template from scratch by simply adding a sitemap match that follows
> a predefined name convention (e.g.
> <table_name>-<crud_operation>-<def|tpl>.xml).

I didn't see in your writeup how the CRUD operations will be launched,
i.e. by what URL patterns will the flow(s) be started.  Personally I
think something close to the Ruby on Rails pattern would be good, though
the automatic pluralization/singularization might be overkill.

> ...

Looks good so far.  I do have a little bit of a concern that it's moving
too far down the "inifinite customization" track too early, rather than
concentrating on making a light framework that lets you get a simple
CRUD app up and running with a minimum of effort.  Like it or not, any
CRUD framework in today's market has to compete with RoR, so IMO it's
got to be at least as easy, period.  I'm sure it'll get there. :)

Do you have a plan for where this development will occur?  I'd like to
be able to help out with code but I'm not a committer so somewhere
outside the official repository would be easier for me ;)

Nice work.

View raw message