... > Sorry for the delay in my reply. It is hard to follow 100 > mails daily on > the list. ;-)
No problem, I feel your pain ;) ... > 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. > > >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? True. ... > > >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? ... > > > >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). Of course, isn't that what general ER diagrams are used for anyway? > > >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. 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)? > > > > > > >>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. 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"? ... > >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. ... > 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? 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. 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. 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. 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?)... 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? Bye! max
