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 Sat, 15 Oct 2005 18:47:41 GMT
Max Pfingsthorn wrote:

Sorry for the delay in my reply. It is hard to follow 100 mails daily on 
the list. ;-)

>Hi everyone!
>
>Sorry, this one turned out to be quite long with the quotes inside. Bear with me, please!
:)
>
>...
>  
>
>>>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.
>>    
>>
>
>Sure. Imagine you have a multi-component web application (as in it has a forum, a calendar,
and a wiki) and you want all components to have file attachments. You wouldn't want to have
a separate implementation for each of the components, but rather use a common one for all
of them. Now, you don't have a tree structure of relationships anymore, but a DAG (directed
acyclic graph, http://en.wikipedia.org/wiki/Directed_acyclic_graph).
>These can of course be modelled in SQL using foreign keys, but that is not the point.
How do you know when you are actually referring to the same entity in your forms?
>

Very easy. Since the talk is about conventions as in Rails, then here we 
introduce a new development rule again:

"The field name should be unique in the whole application. If you use 
the same name in 2 different forms, then they refer to the same field in 
the database."

Tha means, if we decide a field is called "userName", then whenever we 
use this name we are refering to the same field! Even if the name is in 
2 different forms.

>Meaning, do you have a good algorithm to extract an ER-diagram from a bunch of forms?
>

Well, still not, but the above rule, allow to create it. WDYT?

>I think, that would be pretty hard... Especially if you say you might have multiple forms
for the same table, where these forms might have different amounts of fields (some left out,
some added for processing).
>  
>
Maybe not. ;-)

>I guess it could work with Sylvain's suggestion that the user makes a library for each
entity and uses those for building the final forms. However, this is a rather rigid assumption...
and still hard to analyze.
>  
>
The forms library is still valid. It address another user need: 
Reutilization of user predefined field types. Of course we should also 
provide a default cform field library.

>  
>
>>>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.
>>    
>>
>
>Aha.
>
>  
>
>>We believe we just  need to define few more attributes in the form 
>>definition.
>>    
>>
>
>Wouldn't it become a sort of ER diagram then?
>

Yes, somehow. But an E-R diagram from wich can be very easy to build the 
database model in DDL (Data Definition Language).

>Plus the calculated/processing fields?
>  
>
Yes. Since the sum of calculated fields is less than the sum of 
non-calculated (hence persisten) fields, we can also introduce a new 
attribute to define then. That way we can also use the form library to 
have some predefined calculated fields. As a sample. The sum of the 
column in a invoce. The calculated field can also use the value of 
another calculated field to calculate itself. ie: the tax field in an 
invoice. or the subtotal + shipping. I hope it explain the idea.

If we think more about the caculated fields, they are not persistents. 
The calculated are showed in the form just to provide more info to the 
user. Often, they are not going to be store in the database. Sometimes, 
we need to store also calculated fields in the database for DB 
performance reasons.

>  
>
>>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.
>>    
>>
>
>I just don't see how explicitly not using the model the application is built on (db schema),
but trying to infer it through some obscure means is better...
>
Some reasons:

1-Faster development time.
2-Easier for people that does not understand SQL or write bad SQL.
3-Bring O/R mapping to the masses.

... between others that I cannot think right now are IMHO, full valid 
reasons to make a try to that. ;-)

>Maybe it would be more worthwhile to make an effort to write a graphical form editor for
the lepido project which operates on a certain model of the data the application edits.
>
This is also a part of the game. Yes, we need the editor too.

>I believe, Dreamweaver does something like this already. Then the last 20% of making new
forms or adjusting generated ones goes quickly.
>  
>
I think we should think in Open Source tools only. Maybe this is just 
me, sorry.

>  
>
>>>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.
>>    
>>
>
>Okay, but I think this will be very hard. Much harder than letting people do it the other
way and edit generated stuff by hand.
>  
>
Yes, it is. And this is exaclty why we don't have it now. And why I 
explained we don't found the time to work on that. I just wanted to 
share the idea to see what other people can contribute to this.

I think it is posible to build something like this here. To me there is 
no project that cannot be done is a Open Source community. As a sample, 
I remember how M$ pointed out for years that a project like a browser 
(Mozilla) should never becomes a reality in a Open Source community. We 
know now the reality. ;-)

>  
>
>>>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 have the feeling we are talking about the same thing, but call it differently. If we
can augment an ER representation with some extra validation (which might actually happen in
some databases as well, like using the CHECK constraint in postgresql for ranges and so on),
this seems a more complete model of the application. I just don't think splitting the information
in so many different, and possibly conflicting, parts (forms) is so great... You need to do
a lot more analysis and bookkeeping that way.
>  
>
Yes, maybe we are talking about the same thing. We want to have the 
information stored only in one place. The database model shoudl be 
generated from the forms and not the opposite. I am repeating this 
again, because initially we wanted to start from the DB and build forms 
from that. It takes us long time to realize this could never happen or 
is really,really very complex or will need a lot of unnecesary attributes.

>...
>  
>
>>>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?
>>    
>>
>
>Sure. Imagine amazon, well amazon uk, they still have the older layout. You got tabs on
top, which each define a set of views on a certain subset of the data. Then, one of the sets
of views is one "perspective", if you talk in eclipse UI terms. Each perspective has a bunch
of views attached to it. If you click on "books" on amazon.co.uk, you see the "search" view,
which is already initialized to search for books. On the right, you have some "hot books"
view, and in the middle, you have the newest books. Now, if you think of a more interactive
application, an action for one view (i.e. add a new book to my cart) might update another
(i.e. a little view of my cart) but not change the perspective (you are still browsing books).
This is not possible in rails but it would be really cool!
>  
>
Thank you for the explanation. Sound good. Something like a portal where 
we can on the sides show some database views as: top ten list of "whatever".

Best Regards,

Antonio Gallardo.


Mime
View raw message