Re: MyFaces Fusion Naming

[Thomas Spiegl <th...@gmail.com>]

another one ...

Apache MyFaces Edge

On 2/28/07, Jeff Bischoff <jb...@klkurz.com> wrote:
> Glad you liked it. Yeah I figured it would be pretty common name, but at
> least not as bad as Spyder! (taken by both S&P ETF fund and major winter
> sports gear company)
>
> Anyway it's a cool name, but probably too common
>
> Mario Ivankovits wrote:
> > Hi Jeff!
> >> Apache Myfaces Spider
> > I like it, though the first hit in google with "software spider" results
> > in http://www.spider-software.de/
> >
> > Ciao,
> > Mario
> >
> >
> >
> >
>
>
>


-- 
http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: MyFaces Fusion Naming

[Mike Kienenberger <mk...@gmail.com>]

Might be significant that two people have asked this question so far  :-)

On 3/1/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi !
> > Just out of curiosity, why is this part of MyFaces as opposed to Shale. It
> > sounds more like something that belongs there...
> >
> We developed it under the MyFaces umbrella during the last months, we
> started with a tag base way until we reached the spring based solution
> we have now.
> So, thats why it's still here.
>
> We will see what the future brings.
>
> Ciao,
> Mario
>
>

Re: MyFaces Fusion Naming

[Werner Punz <we...@gmail.com>]

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.

Re: MyFaces Fusion Naming

[Matthias Wessendorf <ma...@apache.org>]

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.

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).

Thx,
Matthias


On 3/2/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Craig!
>
> > One thing I've wondered as I've watched the fusion stuff go by ... in
> > an architecture that is so heavily based on Spring 2 already, why
> > wasn't Spring Web Flow used?
> Don't know much about SWF, but we had a meeting with Jürgen Höller from
> interface21 where he helped designing the integration of the
> conversation scope with Spring including the persistence stuff.
> If SWF would have been possible to do this he would have said it.
>
> Also Fusion do depend on Spring 2, but not that hard ... for sure, it
> uses its possibility to create custom scopes and makes use of their
> persistence framework, though, its still modular enough that - if JSF
> will ever allow custom scopes - it can be plugged in there too.
>
> What might be possible is, that SWF make use of this new scope too -
> Fusion is also designed in a way that you can replace the web framework
> (in the important area).
> Maybe (I hope for the future) shale-dialog can make use of this scope
> too, and can provide a solution for the persistence that way.
>
> Ciao,
> Mario
>
>


-- 
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: MyFaces Fusion Naming

[Mario Ivankovits <ma...@ops.co.at>]

Hi Craig!
> That's where I don't understand Fusion enough to comment ... it
> originally appeared to me that the key value add was allocating the
> entity manager on the way in (when you created the conversation), and
> cleaning up afterwards when the conversation ended.
Yes, this is one of the things we do, the other thing is, that we have
to ensure for each call into the conversation scoped bean that this
entity manager has been set to the thread so that the following classes
will see this entity manager.
This is where the Spring aop stuff provides REALLY nice things.

That way, its possible to work with multiple conversations within one
request; not that you can exchange the beans load by each other.

You say, this should be solved at the servlet spec. And I think with our
solution we are really close to it.
The basic conversation scope works as if it is provided by the servlet
spec. You have an additional scope and finding the scope context (multi
window awareness) works through an url parameter which will be added by
an servlet response wrapper (just like the session id without cookies).
Thats why we are not bound to JSF in this area, there is simply no JSF
code to achieve this.

All I need is access to e.g the request map and session map, that has
been refactored into a framework adapter, and if I would like to spend a
servlet filter I can avoid even this.


Ciao,
Mario

Re: MyFaces Fusion Naming

[Craig McClanahan <cr...@apache.org>]

On 3/2/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Craig!
>
> > One thing I've wondered as I've watched the fusion stuff go by ... in
> > an architecture that is so heavily based on Spring 2 already, why
> > wasn't Spring Web Flow used?
> Don't know much about SWF, but we had a meeting with Jürgen Höller from
> interface21 where he helped designing the integration of the
> conversation scope with Spring including the persistence stuff.
> If SWF would have been possible to do this he would have said it.
>

You're right ... he would definitely know :-).

> Also Fusion do depend on Spring 2, but not that hard ... for sure, it
> uses its possibility to create custom scopes and makes use of their
> persistence framework, though, its still modular enough that - if JSF
> will ever allow custom scopes - it can be plugged in there too.
>

My personal feeling is this should really be solved at the servlet spec level.

> What might be possible is, that SWF make use of this new scope too -
> Fusion is also designed in a way that you can replace the web framework
> (in the important area).
> Maybe (I hope for the future) shale-dialog can make use of this scope
> too, and can provide a solution for the persistence that way.
>

That's where I don't understand Fusion enough to comment ... it
originally appeared to me that the key value add was allocating the
entity manager on the way in (when you created the conversation), and
cleaning up afterwards when the conversation ended.  That much is
really easy to do with pretty much any conversation scope API (for
example, with Shale you'd just define a listener that was notified
about the start and stop events; with Struts 2 you'd stick this logic
into an interceptor chain, and so on).  I guess that I don't
understand why supporting the persistence manager that way *required*
a new kind of conversation paradigm.

It's more of academic interest to me at the moment (I'm buried in work
stuff right now) ... but if your conversation scope stuff can be
adapted to Shale Dialog's dialog manager[1] APIs[2], it'd be pretty
easy to integrate -- there's already two implementations (basic and
SCXML based), so the more the merrier.

Craig

[1] http://shale.apache.org/shale-dialog/index.html
[2] http://shale.apache.org/shale-dialog/apidocs/index.html


> Ciao,
> Mario
>
>

Re: MyFaces Fusion Naming

[Mario Ivankovits <ma...@ops.co.at>]

Hi Craig!

> One thing I've wondered as I've watched the fusion stuff go by ... in
> an architecture that is so heavily based on Spring 2 already, why
> wasn't Spring Web Flow used?
Don't know much about SWF, but we had a meeting with Jürgen Höller from
interface21 where he helped designing the integration of the
conversation scope with Spring including the persistence stuff.
If SWF would have been possible to do this he would have said it.

Also Fusion do depend on Spring 2, but not that hard ... for sure, it
uses its possibility to create custom scopes and makes use of their
persistence framework, though, its still modular enough that - if JSF
will ever allow custom scopes - it can be plugged in there too.

What might be possible is, that SWF make use of this new scope too -
Fusion is also designed in a way that you can replace the web framework
(in the important area).
Maybe (I hope for the future) shale-dialog can make use of this scope
too, and can provide a solution for the persistence that way.

Ciao,
Mario

Re: MyFaces Fusion Naming

[Craig McClanahan <cr...@apache.org>]

On 3/2/07, Werner Punz <we...@gmail.com> wrote:
> Arash Rajaeeyan schrieb:
> > and may be thats because shale has chosen a different approach?
> >
> No...
> Actually I  think the fusion conversation system is one level lower than
> shale dialog.
> While shale dialog basically follows the approach -> configuration of
> dialog scopes, have something which can keep objects in ram during
> the dialog.
>
> the fusion conversation system is along the lines of:
> providing a programmatic accessible scope mechanism based on spring 2.0s
> basic scope control which also is able
> to handle orm entity manager control, no dialog configuration whatsoever
> (except for a spring bean entry).
>
> Nothing speaks against accessing this programmatic control from a
> configuration based dialog system, and only a few things currently
> prevent it from being accessible from other webframeworks outside of the
> jsf scope.
>
> But as Mario said, who knows what the future will bring.
>
>
>

One thing I've wondered as I've watched the fusion stuff go by ... in
an architecture that is so heavily based on Spring 2 already, why
wasn't Spring Web Flow used?  It looks like the core value add you
wanted (managing the persistence tier resources at a per-conversation
level instead of per-request) could have been done with SWF just as
easily as writing your own conversation scope stuff.

Craig

Re: MyFaces Fusion Naming

[Werner Punz <we...@gmail.com>]

Arash Rajaeeyan schrieb:
> and may be thats because shale has chosen a different approach?
> 
No...
Actually I  think the fusion conversation system is one level lower than
shale dialog.
While shale dialog basically follows the approach -> configuration of
dialog scopes, have something which can keep objects in ram during
the dialog.

the fusion conversation system is along the lines of:
providing a programmatic accessible scope mechanism based on spring 2.0s
basic scope control which also is able
to handle orm entity manager control, no dialog configuration whatsoever
(except for a spring bean entry).

Nothing speaks against accessing this programmatic control from a
configuration based dialog system, and only a few things currently
prevent it from being accessible from other webframeworks outside of the
jsf scope.

But as Mario said, who knows what the future will bring.

Re: MyFaces Fusion Naming

[Arash Rajaeeyan <ar...@gmail.com>]

and may be thats because shale has chosen a different approach?

On 3/2/07, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi !
> > Just out of curiosity, why is this part of MyFaces as opposed to Shale.
> It
> > sounds more like something that belongs there...
> >
> We developed it under the MyFaces umbrella during the last months, we
> started with a tag base way until we reached the spring based solution
> we have now.
> So, thats why it's still here.
>
> We will see what the future brings.
>
> Ciao,
> Mario
>
>


-- 
Arash Rajaeeyan

Re: MyFaces Fusion Naming

[Mario Ivankovits <ma...@ops.co.at>]

Hi !
> Just out of curiosity, why is this part of MyFaces as opposed to Shale. It
> sounds more like something that belongs there...
>   
We developed it under the MyFaces umbrella during the last months, we
started with a tag base way until we reached the spring based solution
we have now.
So, thats why it's still here.

We will see what the future brings.

Ciao,
Mario

RE: MyFaces Fusion Naming

["Kito D. Mann" <km...@virtua.com>]

Just out of curiosity, why is this part of MyFaces as opposed to Shale. It
sounds more like something that belongs there...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info

* Sign up for the JSF Central newsletter!
http://oi.vresp.com/?fid=ac048d0e17 *



 

> -----Original Message-----
> From: Thomas Spiegl [mailto:thomas.spiegl@gmail.com] 
> Sent: Wednesday, February 28, 2007 6:28 PM
> To: MyFaces Development
> Subject: Re: MyFaces Fusion Naming
> 
> another one ...
> 
> Apache MyFaces Edge
> 
> On 2/28/07, Jeff Bischoff <jb...@klkurz.com> wrote:
> > Glad you liked it. Yeah I figured it would be pretty common 
> name, but 
> > at least not as bad as Spyder! (taken by both S&P ETF fund 
> and major 
> > winter sports gear company)
> >
> > Anyway it's a cool name, but probably too common
> >
> > Mario Ivankovits wrote:
> > > Hi Jeff!
> > >> Apache Myfaces Spider
> > > I like it, though the first hit in google with "software spider" 
> > > results in http://www.spider-software.de/
> > >
> > > Ciao,
> > > Mario
> > >
> > >
> > >
> > >
> >
> >
> >
> 
> 
> --
> http://www.irian.at
> 
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
> 
> Professional Support for Apache MyFaces
>