You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Simone Gianni <s....@thebug.it> on 2006/05/10 17:41:35 UTC
Cocoon CRUD (was GSoC Proposals)
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.
Description of our project follows.
--- Main ojbectives and requirements ---
The goal of the project is to provide a configurable and customizable
framework for Cocoon Forms that allows Cocoon developers to build a
simple cforms application. Traditionally, developers need to do this by
writing 3 xml files and a flow, not considering setting up a persistence
layer, which can be overkill for simple apps.
The application will basically comprise some java classes that operate
on a "database" performing the following operations :
- Fetching of metadata (column names, column types, column length limits
etc..)
- Perform a "select * where" to retrieve all the rows and display a list
- Perform an "insert" to add a new row in the table
- Perform a "select * where" to retrieve a single row
- Perform an "update" to update an existing row
- Perform a "delete" to remove an existing row
This set of classes will be realized in the conventional
insterface/abstract base/concrete implementation fashion, thus
permitting a power user to implement their own persistence components to
realize CRUDs on, say, an LDAP directory, a CSV file or whatever else
they can manipulate with a CRUD.
The default implementation will work on a relational database, using
JDBI as a persistence layer, and will require a configuration indicating
only database connection parameters (datasource name, or Spring bean
name, see later) and the table names.
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.
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.
Point 6 will be used to define some hooks on the controller, so that it
will be easy to customize also the controller without having to write a
custom flow. This a brief and partial list of hooks we were thinking about :
- loadData : permits to operate on the Map containing data before this
data is binded to the form
- sendForm - initializes the Form object before the form is sent to the user
- formSubmitted - operates on the Form object after the user submitted it.
- saveData - operates on the Map containing data before this data to
perform custom operations; this can also be used to perform custom
(application scoped) server-side validations, and eventually send Form
execution from the beginning or dispatch the request to a custom cocoon URI.
We will strive not to introduce completely new XML grammars, so we will
try to reuse as much as possible already defined ft:, fd: and fi:
elements in a way that only custom parts can be written by the user and
merged with default settings.
--- 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).
The Form Binding will be totally managed by JDBI, loading and saving
data using SQL Maps; no extra work is needed since the introduction of
the formToMap and mapToForm methods.
Using the custom Javaflow hooks the developer is allowed to implement
predefined interfaces or define javascript snippets and operate on the
Form object as well as the database information.
JDBI already has a bean written for Spring environments, that will
simplify the configuration process. Spring usage will obviously not be
mandatory, so that code will work also on 2.1.X without other
dependencies, but code will be written taking Spring in consideration so
that 2.2 integration will be complete.
--- Planning ---
The realization of the project is composed of 3 milestones (+1 that
still need to be defined but we think it's worthwhile to mention it)
Milestone 1
-----------
- Basic implementation of persistence classes, but not with matadata
extraction
- Basic Javaflow implementation to provide list, write, edit and delete
operations
- User will need to write cform Form Definition
Milestone 2
-----------
- Form Definition generated by database metadata
- Spring integration
Milestone 3
-----------
- Suport for foreign keys (one to many relations)
- Additional configuration parsing: validations, styling, listeners,
foreign keys and flow hooks
Milestone 4
-----------
- Adding search criterias in a "Query by example" style as an
alternative to a plain list.
- Some way of integration or migration to-from Ruby on Rails.
- Some way of migration to use penrose libraries to define relationship
between tables, so that data can be translated to other data models,
such as LDAP.
WDYT?
Simone and Maurizio
--
Simone Gianni
Re: Cocoon CRUD (was GSoC Proposals)
Posted by Simone Gianni <s....@thebug.it>.
Hi Andrew,
Andrew Savory wrote:
> Ciao!
Ciao :)
>
> Simone Gianni wrote:
>
>> The default implementation will work on a relational database, using
>> JDBI as a persistence layer, and will require a configuration indicating
>> only database connection parameters (datasource name, or Spring bean
>> name, see later) and the table names.
>
>
> It ought to be possible to require just the database connection
> parameters (no table names); by default the tables should be
> automagically discovered.
Yep, sure, I was thinking of it in a "single table" operation. Obviusly
a side component (flow) will generate a list of tables with proper links
to "thistable-list.do", "thattable-list.do" etc..
>
> This might be a cool orthogonal thing to do at the Hackathon for those
> that aren't able to work on Cocoon 2.2, as well. If you haven't
> finished it by then, that is ;-)
Sure!
Simone
--
Simone Gianni
Re: Cocoon CRUD (was GSoC Proposals)
Posted by Andrew Savory <an...@luminas.co.uk>.
Ciao!
Simone Gianni wrote:
> The default implementation will work on a relational database, using
> JDBI as a persistence layer, and will require a configuration indicating
> only database connection parameters (datasource name, or Spring bean
> name, see later) and the table names.
It ought to be possible to require just the database connection
parameters (no table names); by default the tables should be
automagically discovered.
> WDYT?
I'd love to see this happen. There was some discussion along similar
lines after last year's GetTogether, I'll dig out some links to the mail
archive later.
This might be a cool orthogonal thing to do at the Hackathon for those
that aren't able to work on Cocoon 2.2, as well. If you haven't finished
it by then, that is ;-)
Thanks,
Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/
Re: Cocoon CRUD (was GSoC Proposals)
Posted by Maurizio Pillitu <m....@thebug.it>.
>
> Milestone 4
> -----------
> - Adding search criterias in a "Query by example" style as an
> alternative to a plain list.
> - Some way of integration or migration to-from Ruby on Rails.
> - Some way of migration to use penrose libraries to define relationship
> between tables, so that data can be translated to other data models,
> such as LDAP.
>
>
For more informations about penrose, see here
http://docs.safehaus.org/display/PENROSE/Home
> WDYT?
>
> Simone and Maurizio
>
>
Re: Cocoon CRUD (was GSoC Proposals)
Posted by David Crossley <cr...@apache.org>.
Simone Gianni wrote:
> Hi Sylvain,
> you're right, I do agree with you. I was searching for a way to
> cooperate without having to make a couple of patches every day.
>
> Anyway, we can reduce the amount of patches (and thus the tedious part
> of them) by organizing wisely the developement effort, like assigning
> entire parts that can be developed in a rather independent way between
> me, Maurizio and Jason.
It is also important to do any discussion on
the dev@ mailing list so that others can participate.
-David
Re: Cocoon CRUD (was GSoC Proposals)
Posted by Sylvain Wallez <sy...@apache.org>.
Simone Gianni wrote:
> Hi Sylvain,
> you're right, I do agree with you. I was searching for a way to
> cooperate without having to make a couple of patches every day.
>
> Anyway, we can reduce the amount of patches (and thus the tedious part
> of them) by organizing wisely the developement effort, like assigning
> entire parts that can be developed in a rather independent way between
> me, Maurizio and Jason.
>
That a good way to organize things and effectively avoids people to step
on each other's toes!
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Cocoon CRUD (was GSoC Proposals)
Posted by Simone Gianni <s....@thebug.it>.
Hi Sylvain,
you're right, I do agree with you. I was searching for a way to
cooperate without having to make a couple of patches every day.
Anyway, we can reduce the amount of patches (and thus the tedious part
of them) by organizing wisely the developement effort, like assigning
entire parts that can be developed in a rather independent way between
me, Maurizio and Jason.
Simone
Sylvain Wallez wrote:
>I am strongly against hat! The way to become a committer is by
>contributing (remember how you became one?)
>
>So, even if a bit tedious, Jason has to provide patches that will be
>evaluated by the community up to a point where his contribution are
>considered good enough and frequent enough for him to be voted committer.
>
>Using other code repositories can only lead to community fragmentation
>and hiding valuable contributions of people that are hidden because
>they're proxied by someone else.
>
>Sylvain
>
>
>
--
Simone Gianni
Re: Cocoon CRUD (was GSoC Proposals)
Posted by Sylvain Wallez <sy...@apache.org>.
Simone Gianni wrote:
> Hi Jason,
>
> Jason Johnston wrote:
>
>> 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.
>
I am strongly against hat! The way to become a committer is by
contributing (remember how you became one?)
So, even if a bit tedious, Jason has to provide patches that will be
evaluated by the community up to a point where his contribution are
considered good enough and frequent enough for him to be voted committer.
Using other code repositories can only lead to community fragmentation
and hiding valuable contributions of people that are hidden because
they're proxied by someone else.
Sylvain
--
Sylvain Wallez - http://bluxte.net
Re: Cocoon CRUD (was GSoC Proposals)
Posted by Simone Gianni <s....@thebug.it>.
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"
>translation.
>
>
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.
>><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.
>
>
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 crud-users-list.do
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
--
Simone Gianni
Re: Cocoon CRUD (was GSoC Proposals)
Posted by Jason Johnston <co...@lojjic.net>.
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"
translation.
> --- 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.
> ...
> WDYT?
>
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.
--Jason
Re: Cocoon CRUD (was GSoC Proposals)
Posted by Jean-Baptiste Quenot <jb...@apache.org>.
Hello Simone,
CRUD apps with CForms is something we all dream about.
My 2 cents however:
> These informations will be used to generate a form definition
I would rather say: will be used to generate a form library. It
is much more convenient to import the generated library in a
minimal form definition because then the user will be able to
customize the generated interface and override some fields. If
you generate the form definition directly, changes made by the
user will be overwritten at next generation. Using a library
allows for iterative programming.
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/