cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <>
Subject Re: Cocoon CRUD (was GSoC Proposals)
Date Thu, 11 May 2006 12:02:14 GMT
Hi Jason,

Jason Johnston wrote:

>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. :)
Veeery well :)

>>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.
Yep, you are right, it's just a "numbering issue" given by the final
revision of the specs before posting them here. Only point 3 will
directly affect template generation, all the rest will be in definition.
Anyway, we will see how to make it work when we get there.

>>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"
Yep, I thought about it too. Unfortunately this would require a
modifiction of the i18n transformer, since it does not provide a "fall
back text" to use when a key is not found. We could add this to i18n
transformer, create a subsclass of the i18n transformer to add this
functionality, or have another component generate a default i18n bundle
with this automagically generated labels.

Don't know which one of these solutions is the better one.

>>            --- 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.
>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.
yep, we should study how RoR works and try to get closer to it, but I'd
like to do something more than a "Cocoon RoR implementation". The
simplest way would be to have a <map:match pattern="crud-*-*.do"> where
{1} is the table, {2} is the operation, for example
will produce a list of the records in table users. Same applies for the
files, <map:match pattern="crud-*-*.def.xml"> will be pipe that produces
the definition, first checking if the user provided a custom definition
file, otherwise generating them from metadata and configuration file.

>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. :)
Yep, customization file will get in place at milestone 3, or maybe some
parts in milestone 2, we can decide that. Up to that point the only way
of customizing it would be to "extract" the generated
definition/template, save it in a properly named file, and customize it.
but it will be completely optional starting from milestone 2, since all
the "missing" files wil be generated from database metadata.

>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 ;)
We have a CVS/SVN public server, and can easily setup other cooperation
services, like an issue tracking and a wiki. I can then move the
released code and documentation to the cocoon tree.


Simone Gianni

View raw message