Matthias Wessendorf schrieb: > Well... > > 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 >frameworks... >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 persistencecontext control. 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 things basic. 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.
