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
