cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Gallardo <agalla...@agssa.net>
Subject Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)
Date Sun, 09 Oct 2005 00:01:52 GMT
Bertrand Delacretaz wrote:

> Le 7 oct. 05, à 17:09, Berin Loritsch a écrit :
>
>> ...As to the sample apps--I agree to a point.  If you don't have the 
>> convention to build the sample app with, how is the potential user 
>> going to know what they are looking at?  In other words what are they 
>> going to walk away with when the look at a sample app?...
>
>
> I've been thinking about this after the discussions at the GT 
> yesterday, and generating an app like bricks-cms from a data model 
> could be very helpful.
>
> Starting from a database schema (or our own schema definition maybe, 
> more flexible and easier to parse), here's what you'd need to generate 
> (not talking about views at this point, so this covers only part of 
> what you're after):
>
> -Java data objects (1:1 mapping with name conventions)
> -OJB repository.xml file (same)
> -For each object, the CForms model, binding and template files
> -A menu of available CRUD forms

Since day 1 we had been using cocoon to build web enable DB 
applications. It was at that time, when cocoon was still advertised as 
just a publishing framework. We had have been working with this pattern 
for long time now, since early days of the old woody and JS flow. Well 
all of this is just a history now. ;-)

For the 1st 2 steps we use Druid [1] and it works very well. An 
advantage is that you get DB docs almost for free and it is able to 
generate DDL's for most used DB engines.

>
> The slightly tricky bit is to manage relations between objects, but at 
> least for simple relations it shouldn't be too hard.

We had been thinking in improving Druid a little bit more or use the new 
Lepido platform for that.

Yes, The"slightly tricky bit" problem for some people is that they don't 
have enough SQL knowledge to build up the database. The good news is 
that this  problems can be solved. For that, I believe, we should need 
to start thinking in a different way:

1. The user defines the form definitions and templates.
2. A specialized builder (in Druid or Lepido) build the needed DB 
structure based on the user input from step 1.
3. Build the DB schema, the java data object, the forms bindings, etc.. 
from step 2 output.

Since this solution has not been our primary project, we had been 
thinking in how to solve this problems only at our "copious free time". 
We already fine grained some more ideas to accomplish this builder. But, 
for more than a year, we don't had the time to start implementing them. 
Perhaps, this should be implemented as part of the Lepido effort.

Summary: "Input the form definitions and templates and let Lepido build 
the whole cocoon application for you!" ;-)

Sounds good?

Best Regards,

Antonio Gallardo.

[1] - Yes, it is the same old Druid that I had been advertising for long 
time in this list - http://druid.sourceforge.net/


Mime
View raw message