Max Pfingsthorn wrote:
...
Druid looks great. But wouldn't it be better to let users
make an ER diagram and take it from there? i.e. create db,
java classes, ojb mapping, some default forms with the right
definition and binding. Then, the "only" thing left to do is
adjust the template and you are done! :)
Unfortunately, this does not solve the problem:
1. In a form we can have some fields that are calculated, hence there
does not exists a corresponding DB field for it.
2. In other situation, you don't want to use all the DB table
fields in
the form.
IMHO, there is no a correct way to go from the DB table to the form.
More often than we though a DB table cannot be mapped to a
form due the
defined interface.
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.
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. We
believe we just need to define few more attributes in the form
definition. 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.
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.
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 was also thinking about the views... It might be nice to have a state as to which view
to show. Some actions might change this state in a state-machine-like fashion. You might
also have a way to directly change the current view. This would make it much easier to
translate requests to the server as actual method calls on a controller or even model
object (something like /shoppingcart/addItem). After calling the method giving a hashmap
of parameters or something similar, the current view would be rendered. Now, it would be
especially cool to do this ajax-style and send back a document containing changes to the
current view. Without ajax, you get weird urls which are not bookmarkable at all but you
translate the "old" request/response model in a more appropiate action/reaction
sort of thing.
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?
Best Regards,
Antonio Gallardo.
