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 Mon, 10 Oct 2005 06:20:56 GMT
Max Pfingsthorn wrote:

>...
>  
>
>>>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.
>
Can you point to a graph-like relationships model that cannot be modeled 
in SQL? Maybe I don't got your point.

>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.
>  
>
No. The initial thread discussion was about patterns. The idea is to 
follow a pattern in order to get the code generated. I am not telling 
the initial form model is exactly as our current form definition. We 
believe we just  need to define few more attributes in the form 
definition. We don't want to just figure out what people is writing. If 
this was the case, then Druid is already done for 2 years now. We want 
to make a step further in the current approach. And in this case why the 
initial point for building the application are the forms not the db schema.

>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).
>
Yes, it is a code generator, but no a simpler one. We are not talking 
about a simple XSL transformation. If this generator was so simple, it 
might be already implemented. We talk about parse the whole application 
form definition set , analyze it and get a DB schema for them.

>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.
>  
>
This is what I pointed from the begining. We think that starting from an 
DB model is the wrong way. The starting point should be the forms. In 
the form definition, we already have identifiers, datatypes, 
validations, constrains, relationshisps, etc. There is a lot information 
that can be reused for building a db schema. And once we have a db 
schema, we can reuse druid or an improved version to make this more 
complete.

>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.
>  
>
Don't get the point. Can you provide an usecase of this?

Best Regards,

Antonio Gallardo.


Mime
View raw message