Matthias Wessendorf schrieb:
don't lets discuss that much about why another thing...
Perhaps all these existing techniques can get their profit from the
other one and can also give valuable feedback to web beans / jsr 299.
I am happy that *Fusion* (or Kleber) has no dependency to WebFlow. I
would prefer a closer connection to the Shale (Basic) Dialog.
Actually I personally think this is one area which is very important,
Shale as excellent configuration patterns which are currently missing
in fusion and a closer tie could benefit both frameworks I guess.
Fusion started out from the idea of being able to have something
conversational without having to have an entire configuration system,
but there are many usecases where a conversation system can solve a lot
of issues. So I personally now think, that having both and also having
persistence control in it is probably the best way to go.
No configuration for the easy usecases (which are the usual 50-70% and
having something with more control on the configuration side for the
more complicated ones.
Funny that Seam started off as well configuration less, and now has
moved into a we support both approach.
However... it's good to have the choice... Take a look at ORM or web
there are more than one, doing 99% same like the other... also the
advent of JSF didn't stop that (like GWT for instance).
Actually there are not too many choices of such systems currently
You only have seam and fusion/kleber which can do full
I personally think, Seam is a work of pure genious, it is seldom that a
first approach does most of the things right.
But Seam itself, has too string tie ins into ejb3 and into jsf (I love
ejb3 and I am not an enemy of JSF obviously, but I still see it as a
problem) probably and makes some automatic assumptions which are
perfectly ok for a framework which tries to ease things, but often you
do not want to lose this control entirely.
For instance one area of this we make the assumptions for you in Seam is
the passing from the master to the detail which happens automatically.
I once did a testprogram in Seam and thought afterwards to myself, what
has happened here, I want to know...
While it was good for the end user who does not want to think about it,
something in there broke to my knowledge simply the way the tomahawk
handles the tables, so tomahawk was incompatible to seams handling of
master detail relationships. I am not going into detail here, because I
neither remember the exact automatisms nor the exact details why the
tomahawk table does not work.
One of the problems I have faced the last week, was to find a way to
handle the master detail relationships the way I wanted to have them, in
a transparent way, which does not take away control.
I had two ways I either could preinitialize the detail conversation in
the master and load the detail or I could use the updateActionListener
like I would anyway,
I opted for a simple updateActionListener. Fusion was low level enough
to leave me the control and did not take assumptions on how to handle
things from me.
I personally would love to see JSR299 go that way, not too make to many
assumptions but keep it basic so that others can build upon it. This is
too important to push a lot into it, that is probably one of the reasons
why the servlets have served us so well for a long time, they kept
And Craig, I agree, scoping should belong at the lowest level possible,
but for now I am happy that there are solutions which ease the burden of
taking away the endless request, merge, lazy loading, object keeping
problems which have plagued us 10 years too long. Orm mappers are a joy
to use, if you do not have to fight against them due to endless lazy
loading, merge problems.