Flow + XForms + Beans + Databases

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Hi Christopher:

I think that the point they tried to show us is that the database
functions  can be an optional part of all the Flow block. I agree because
some applications will not need to use databases at all.

>>From my point of view (I hope the same as you) the added database
functionality now is just experimental. Teh Database API try to interact
directly with the Database if someone does not like (or want) to use
Beans.

This is the main reason why it is currently mixed with the main behavior,
it is just an experiment. In the future there will be a library or an
object that you can include if you need DB API functions with Flow.

Attached is a PNG file that show my point of view of the big picture of
how Flow work with XForms and Databases. I hope I am not wrong. :) This is
the Framework I see to build web based Database Aplication:

The Flow Controller controls every XForm set.

There can be 1 XForm set for each object. ie: Customers, Providers,
Invoices. Every XForm set can have more than 1 XForm page. For example, we
can have 1 XForm  to add a new customer, 1 XForm to edit a customer,
another XForm to delete customer, etc. (I think that we can build a XForm
set that can interact with a concretly every Application Object). The glue
between this XForms is the Flow Controller.

In the graph I also showed that every XForm can be attached to a Bean.
There are also cases when 2 or more XForms can be attached to the same
Bean.

The Beans describe the fields that the XForm show to the user. The Bean
has the same fields as the XForm. In this point I feel like we can use
another approach. Because I looks like the same fields need to be writen 2
times: In the XForm itself and into the Bean. :-(

Then there is a O/R map (can be Hibernate, Apache Jakarta OJB. Modular
Database Actions offer something similar too.).

On the other hand the Database API can be usefull to get some stuff
directly form the Database.

Best Regards,

Antonio Gallardo.

Re: Flow + XForms + Beans + Databases

[Stefano Mazzocchi <st...@apache.org>]

Antonio Gallardo wrote:

> But what about the "model" I graphed? is it OK? 

I can't tell. It sure looks like a better way to factor concerns out, 
but I'm not familiar enough with O/R tools to know this.

> I graphed it, because just
> wrotten things sometimes miss me. I need a graph to try to understand. I
> think this is easy. :-D

I hear you, I normally do the same.

Darwinistically, I think we should release Cocoon 2.1 without a clear 
vision on how to have the flow connected to the business logic and see 
what solutions/problems emerge from the community.

At *that* point, we'll have enough information to know where the walls 
are and how to avoid them by writing an architecture that routes around 
them naturally.

To me, adding direct SQL capabilities to the flow to solve the database 
connection issue, is just like adding actions to the sitemap because 
there is no way to programmatically solve some pipeline-orthogonal needs.

Both turn out to be half-baked solutions once you get to know more 
architecturally advanced ways to solve the same issues.

While we do have that knowledge on actions now, we don't on data 
mapping. So, let people experiment for a while, but without lock-ins 
into the cocoon core.

-- 
Stefano Mazzocchi                               <st...@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------

Re: Flow + XForms + Beans + Databases

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Thanks Stefano to show us the light here! To be honest I dont have too
clear a situation about this:

> Antonio Gallardo wrote:
>
>> On the other hand the Database API can be usefull to get some stuff
>> directly form the Database.
>
> It's a shortcut and it's simply too easy. "too easy" around Cocoon,
> normally means "too easy to abuse".
>
> What is abuse? is when you hit a wall right after you went in production
>  and all the time you saved, you end up spending it later and your
> development capabilities don't scale.

But what about the "model" I graphed? is it OK? I graphed it, because just
wrotten things sometimes miss me. I need a graph to try to understand. I
think this is easy. :-D

Best Regards,

Antonio Gallardo.

Re: Flow + XForms + Beans + Databases

[Stefano Mazzocchi <st...@apache.org>]

Antonio Gallardo wrote:

> On the other hand the Database API can be usefull to get some stuff
> directly form the Database.

It's a shortcut and it's simply too easy. "too easy" around Cocoon, 
normally means "too easy to abuse".

What is abuse? is when you hit a wall right after you went in production 
and all the time you saved, you end up spending it later and your 
development capabilities don't scale.

Why? very simple: having SQL into the flow mixes concerns!!! and we have 
designed cocoon to reduce concern overlap to the bare minimum required 
by the complexity of the problem to solve.

In this case, it's the opposite: we are mixing concerns so that the same 
person can do an easier job at connecting to its database.

This is PHP-like, people. The PHP world has shown pretty evidently that 
this doesn't scale along with the complexity of the web application.

If we start introducing under-designed complexity shortcuts in such a 
critical piece of the framework, we undermine our capabilities to stand 
the pressure of massive web needs.

Database connectivity is simply too important to do it without a 
complete concern analysis and without a collaborative discussion.

The real value of Chris' contribution in this case is to have shown us 
how easy it is to abuse the flow framework and now 'elegant and clean' 
solutions that mix concerns can appear.

But this should help us collectively raise the sensibility of our FS 
alarms, not to lower them!

If managing the sitemaps semantics was hard, managing the Flow Object 
Model will be even worse.

So, be prepared.

-- 
Stefano Mazzocchi                               <st...@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------

Re: Flow + XForms + Beans + Databases

[Stefano Mazzocchi <st...@apache.org>]

Antonio Gallardo wrote:
> Hi Bernhard:
> 
> Thanks for briefing all the stuff. :-)
> 
> But I still have an open question. What will be the standard or recomended
>  O/R mapping tool for Cocoon? Hibernate, OJB or Torque? I will start to
> coding a new application anytime soon and I need to decide what O/R
> mapping to use. Of course I prefer to use the standard way.

There is no such thing as a 'standard O/R tool' for Cocoon. But in case 
you want to give it a try, I'd suggest using OJB.

Re: Flow + XForms + Beans + Databases

[Antonio Gallardo <ag...@agsoftware.dnsalias.com>]

Hi Bernhard:

Thanks for briefing all the stuff. :-)

But I still have an open question. What will be the standard or recomended
 O/R mapping tool for Cocoon? Hibernate, OJB or Torque? I will start to
coding a new application anytime soon and I need to decide what O/R
mapping to use. Of course I prefer to use the standard way.

Antonio

Re: Flow + XForms + Beans + Databases

[Bernhard Huber <be...@a1.net>]

hi, Antonio

><snip/>
>The Beans describe the fields that the XForm show to the user. The Bean
>has the same fields as the XForm. In this point I feel like we can use
>another approach. Because I looks like the same fields need to be writen 2
>times: In the XForm itself and into the Bean. :-(
>
I'd like to restrict my thought to the stage of the beans:

In case of XForm, and flowscript you come to the point when you can say, 
okay the bean
is finished, ready for getting persistant.
Or other way around, okay now I need the Bean form the persistant store
Hibernate says datastore, OJB says broker, in either case you have some 
container.

You tell the container here persist this bean.
your xml-mapping has some mapping from bean to the tables.
That's all.

More general:
You may have the relation XForm {n} ---> {m} Bean {r} --> {s} Table.
The mapping from the beans to the tables is described declarative by 
some mapping xml of the O/R mapping tool.
Hibernate say {bean}.hbm.xml, OJB says respository.xml.

The mapping from XForm to the Bean is asfasik described procedural in 
the XForm Action, or the
procedural java flow script. In both cases you set or get fields of the 
Bean, either unconditionally, or
depending on some more internal calculation.

That's just some thought from me about your questions, hope i caught 
your concerns,
and helped a bit in grasping the whole picture

bye bernhard