cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Pfingsthorn" <>
Subject RE: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)
Date Sun, 09 Oct 2005 22:09:52 GMT

> >Druid looks great. But wouldn't it be better to let users 
> make an ER diagram and take it from there? i.e. create db, 
> java classes, ojb mapping, some default forms with the right 
> definition and binding. Then, the "only" thing left to do is 
> adjust the template and you are done! :)
> >  
> >
> Unfortunately, this does not solve the problem:
> 1. In a form we can have some fields that are calculated, hence there 
> does not exists a corresponding DB field for it.
> 2. In other situation, you don't want to use all the DB table 
> fields in 
> the form.
> IMHO, there is no a correct way to go from the DB table to the form. 
> More often than we though a DB table cannot be mapped to a 
> form due the 
> defined interface.

Hmm, okay. But how do you generate a database schema from a few forms? Especially if there
are graph-like relationships between the entities you cannot model in a form definition. If
you think about it, the form code that is generated is not more than a skeleton anyway. No
application will use the exact generated code.
I think it would be much easier addind these extra bits (add extra fields or remove ones you
don't want to edit) by hand than trying to figure out what people meant when they were writing
their forms.
After all it would be "just" a code generator to cover those 80% of work you have to do anyway,
it does not have to be completely correct all the time (working, yes, but not correct for
the specific application). Ruby on Rails does the bare minimum of code generation also basically
on top of an ER representation, yet still, they do cover enough ground to build stuff fast.

I was also thinking about the views... It might be nice to have a state as to which view to
show. Some actions might change this state in a state-machine-like fashion. You might also
have a way to directly change the current view. This would make it much easier to translate
requests to the server as actual method calls on a controller or even model object (something
like /shoppingcart/addItem). After calling the method giving a hashmap of parameters or something
similar, the current view would be rendered. Now, it would be especially cool to do this ajax-style
and send back a document containing changes to the current view. Without ajax, you get weird
urls which are not bookmarkable at all but you translate the "old" request/response model
in a more appropiate action/reaction sort of thing.

Now, if you define views also in terms of other views (like an eclipse perspective), this
might work quite nicely.



View raw message