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? Meaning, do you have a good algorithm to extract an ER-diagram from a bunch of forms? 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). 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. > >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? Plus the calculated/processing fields? > 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... 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. I believe, Dreamweaver does something like this already. Then the last 20% of making new forms or adjusting generated ones goes quickly. > > >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. > > >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. ... > >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! Bye, max
