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, 16 Oct 2005 03:34:00 GMT
Max Pfingsthorn wrote:

>... 
>  
>
>>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.
>>    
>>
>
>Okay, but don't you run into ambiguity issues then? Maybe we can qualify the field id
by a table name? Something like "cars.brand" to differentiate it from "motocycles.brand".
Would make it clearer, I think. Would also help when generating the final ER diagram.
>  
>
Yes. But at the end is only a name. As you suggested "cars.brand" can be 
also recommended but not required to the user. Recommended, because that 
way the user can easily follow what he wrote. But the system is going to 
register this as only a name. BTW, I am not sure if a "dot" inbetween 
"table.column" name can be supported. For most SQL languages the "dot" 
is a valid operator. Maybe we can replace it with underscore, hence: 
"cars_brand".... wait ... I don't know if this is a good idea.... Well, 
we need to think a solution here too. ;-)

>
>...
>  
>
>>>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.
>>    
>>
>
>Errr.. What do you mean now? I thought you want to go the other way? If you really want
to generate the DB schema from forms then you need to analyse libraries as well to get the
complete picture, not provide them... Or did I get something wrong?
>  
>
No we only pick from the libraries the fields that are declared in the 
forms. Not the whole library. The forms libraries are like macro sets. 
But we will need to define it inside a form in order to use the defined 
macro. It is something like a datatype definition file and we pick only 
the definitions declared inside the forms.

>
>Okay, I can see that. So you are suggesting to extend the form definitions by an extra
attribute per field in case we want to store it or not (default is to store it)?
>  
>
IMHO, for normal fields, yes. Calculated fields are more often 
transient. So, the default for them should be to not store them in the 
database.

>  
>
>>> 
>>>
>>>      
>>>
>>>>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. ;-)
>>    
>>
>
>I agree. That would be nice. However, reason 2 is not really valid as there wouldn't be
any SQL writing even if we had people make an ER diagram.
>
Reason 2 is valid for both. From DB model --> forms and from forms --> 
Db model. ;-)

>You can do that just fine in XML and generate stuff from that (as Druid does, even visually,
like you say).
>What we basically need, according to you, is to provide a bridge from a bunch of form
definitions to a Druid ER diagram, right? "that is all"?
>  
>
Yes.

>...
>  
>
>>>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.
>>    
>>
>
>Of course, I agree, just wanted to point out that it is possible to do it quickly.
>
>...
>  
>
>>>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. ;-)
>>    
>>
>
>Yes, that is true. I actually believe the same. However, there should be some cost/benefit
ratio which makes sense.
>  
>
We believe there is and it is big! After writings tens of forms, you 
start noting the work is always the same and start to be boring and you 
start thinking in a way to automatize and speed up the whole process. ;-)

>...
>  
>
>>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.
>>    
>>
>
>How and why are unnecessary attributes needed?
>
Because in a DB model we don't need things like: field label, field 
help, field hint, enabling/disabling fields, enable ajax!, etc. For this 
reason, I labeled them as "unnecesary attributes" in a Db model. Also, I 
am not able to see a clean way once you met an entity relationship with 
a little bit more complexity in a E-R diagram.

>I see that we are talking about two extremes here: Rails, which does it from the DB to
forms, and your approach which would take forms and turn them into DB schemas.
>
I see something in common with Rails: defined conventions. Someone else 
told in the thread this is one of the big Rails secrets. I really wonder 
if Rails is going to manage complex E-R diagrams. How do you write an 
invoice in Rails. Is this easy? I really don't know.

Yes. The start point are the forms. From the forms we build the DB model 
(or E-R diagram). BTW, this idea had been around for cca. 2 years. [1] :-)

>What I thought of was more or less a middle way: Start from an ER diagram draw and generate
the DB schema from it (easy, Druid does it) as well as the Java Model (also done), the persistence
configs (not done, I guess), and the forms from it.
>  
>
the persistence configs is done too. Druid already generate OJB/hibernate code + DDL code.
We are working this way for almost 2 years now[2]. As I told in a previous mail, I though
we were discussing in the next step. Sorry.


>This way, the task is much easier for us, we explicitly do not try to model every possible
use case of forms (which by the way is a dynamic language and which changes every day, almost,
and keeping track of everything in a separate forms analyzer would be a nightmare, I think),
but rather try to cover the boring, repetitive 80% of normal typing workload so people can
focus on what makes their application special instead of having to work around some black
magic box...
>
>Actually, if you think about it, your approach does not really keep configurations in
one place, you explicitly said before you want to allow users to write multiple forms for
the same entity.
>
Note, the forms is the main part from the user POV. When the users 
scratch up the requirements, they often don't think in a DB model, they 
think in the forms. How the forms should look. IN short they want to see 
the forms. Often, they really don't care nor understand an E-R diagram. 
Lets concentrate in forms and give the boring task to the machine. If we 
go this way, then we have a truly RAD system done. And IMHO, this is a 
big reason that will have a big payoff! ;-)

>This would mean you have to go through each of your forms and make changes to each place
you reference a certain entity and change its definition. The only real central place is the
general data model, which is described by an ER diagram here, so that is where you would want
to keep it, I think. Letting people duplicate information leads to unstable behaviour, and
you might end up with a typo which then results in extra fields which you actually didn't
mean to have.
>
>So, my proposal would be to embrace what druid does so far, and give it a little bit more
of cocoonish special features, like building forms libraries for each entity with the right
binding to the generated java objects, or building a descriptor for OJB (does it do that already,
maybe?)...
>  
>
Yes. It already does this. Druid currently is not generating the cforms. 
We wanted to do that last year [3] and we found the solution is going no 
where. Yes we can build the simple catalogs, but this is not the big 
problem. Also there is missing information from the Druid POV: Field 
label, field hint, field help, dynamic enabling/disabling fields, etc. 
We also found this is also missing concerns: transient fields in the 
form. All this is part of the forms and are not part of the DB. This is 
why there is no way.

>That is really all that is needed to get up and running quickly and speed up general development
without imposing anything on users, which is key, I think.
>
>WDOT?
>  
>
I think it is done. ;-)

                                                                - 0 -

I know this is not the normal pattern we see in a bunch of application 
that try to autogenerate code. And they often fail, because they are not 
able to build a little bit more complex forms as a simple invoce. Since 
day 1, my cocoon involvement is more related to web-enable DB 
applications. I know cocoon is often also percieved as a publishing 
framework. A lot of people use cocoon mostly to build CMS or websites. 
Michael Wechner told me last year he think in cocoon are main two groups 
(publishers [CMS-ers] and DB webapp-ers) and that this two groups 
inevitable push in different ways. My cocoon experience involves already 
an account system, a payroll system between others. They normally 
involve more than 50 tables..... Maybe this is the case Michael pointed 
out and we have different needs of what a better Db support should be. 
While you some people is happy with few simple tables to finish the 
application, for others it is just the beginning.

Best Regards,

Antonio Gallardo.

[1] http://marc.theaimsgroup.com/?t=106761394400006
[2] http://marc.theaimsgroup.com/?m=107569798213119
[3] http://marc.theaimsgroup.com/?m=108244754217133


Mime
View raw message