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.
