You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Mario Ivankovits <ma...@ops.co.at> on 2007/02/22 19:22:26 UTC
MyFaces Fusion
Hi!
MyFaces Fusion is just a collection of already existing myfaces sandbox
components.
The main goal of this project is to ease the development of JSF
applications especially if they have to deal with an ORM backend.
I tried to do so a while back by developing a ConversationTag, which
worked not that bad, but I was told that such a logic should not be put
into the view.
And well, the feeling was that it would be nice if it could be easier to
deal with conversation.
Spring allowed us to create a custom scope AND to reuse the well known
way how it deal with persistence.
So I've rewritten the ConversationTag to use Spring and first tests were
really nice. No need to learn any new programming style, just code as
before.
Some of us reviewed it (offlist) and we came to the conclusion that it
has enough power to live as separate project.
Thats why I created the initial structure - not really new code, just
taken from the sandbox.
I know, I didnt use the svn cp command, but, since ALL of this code has
been developed by me and there is not much value in the current history,
I did it the easier way. Sorry for this.
The current structure is divided into core and core15.
The core part contains the ConversationTag and the RequestParameterProvider.
In contrast to the tomahawk-sandbox ConversationTag the conversation tag
now works using Spring and a custom scope.
The RequestParameterProvider is used to allow multiple open windows
within the same session.
So e.g. I you have a order processing system you can open it twice and
work in two independed conversations (even if their names are the same)
The core15 part contains the DynaForm from tomahawk-sandbox15
It will create parts of the view automatically based on EJB3 annotated
beans.
Its migth become a great time-saver for simple tables.
The current check-in do not bulid usable jars, some maven/tld/xml stuff
has to be put in line, I hope to manage to do so in the next few hours.
In the next few days I'll commit a sample application (given that you do
not cancel my efforts), afterwards the documentation has to be done.
The status of this project is sandbox like.
Ciao,
Mario
Re: MyFaces Fusion
Posted by Matthias Wessendorf <ma...@apache.org>.
> What can I do now?
I don't think you should do a rollback.
discussion is ongoing ;)
-M
> Would it be of any help if I rollback the check-in and we start
> discussion about it?
>
>
> 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
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> There needs to be some kind of discussion before a commit of this
> type, even if it's a single message.
Ok, sorry for being too enthusiastic.
I didn't realize that it would be such a mistake.
What can I do now?
Would it be of any help if I rollback the check-in and we start
discussion about it?
Ciao,
Mario
Re: MyFaces Fusion
Posted by Mike Kienenberger <mk...@gmail.com>.
I went back and reread the "spring conversation scope and ejb".
There's nothing in here stating that Mario was planning on starting a
subproject or committing any code, so I don't think we're being too
harsh when someone starts a new subproject without any warning, and we
get concerned.
There needs to be some kind of discussion before a commit of this
type, even if it's a single message.
On 2/22/07, Werner Punz <we...@gmail.com> wrote:
> Martin Marinschek schrieb:
> > Don't hit to hard on Mario - he tried to start a discussion on this
> > list, but there was no response (it was not about the name fusion, but
> > about the technical details of the spring-conversation stuff).
> > Sometimes there needs to be a commit in open source, so that the
> > discussion can start.
> >
> > And I believe this discussion can definitely start now...
> >
> > regards,
> >
> > Martin
> >
> I agree here, I can remember the post,
> anyway, fusion will be a great addition,
> mario has pushed some stuff in it which is pure genious
> and makes life of all of us easier in the long run.
>
> (Since I am at the starting points of a project
> I am eager to test the spring conversation context
> in combination with jpa)
>
>
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Martin Marinschek schrieb:
> Don't hit to hard on Mario - he tried to start a discussion on this
> list, but there was no response (it was not about the name fusion, but
> about the technical details of the spring-conversation stuff).
> Sometimes there needs to be a commit in open source, so that the
> discussion can start.
>
> And I believe this discussion can definitely start now...
>
> regards,
>
> Martin
>
I agree here, I can remember the post,
anyway, fusion will be a great addition,
mario has pushed some stuff in it which is pure genious
and makes life of all of us easier in the long run.
(Since I am at the starting points of a project
I am eager to test the spring conversation context
in combination with jpa)
Re: MyFaces Fusion
Posted by Martin Marinschek <ma...@gmail.com>.
Don't hit to hard on Mario - he tried to start a discussion on this
list, but there was no response (it was not about the name fusion, but
about the technical details of the spring-conversation stuff).
Sometimes there needs to be a commit in open source, so that the
discussion can start.
And I believe this discussion can definitely start now...
regards,
Martin
On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Mike!
> > In the future, please remember that such reviews and conclusions
> > *must* be made on the mailing list.
> Ok, sorry for this.
>
> > As to the actual merits of the subproject, I don't understand what
> > value it adds to have this in both the sandbox and in "fusion". How
> > do the two subprojects differ? Is it just a matter of different
> > dependencies?
> The parts in the sandbox will deleted once the setup of the new project
> has settled down.
> Afterwards a release of MyFaces Fusion (or whatever name it will have in
> the end) should follow soon.
>
> For the user it is easier to recognize than that there is just another
> competitor in this area (JSF, ORM, etc)
>
>
> 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
Posted by Matthias Wessendorf <ma...@apache.org>.
> Afterwards a release of MyFaces Fusion (or whatever name it will have in
> the end) should follow soon.
+1 for not another txxx name.
fusion isn't possible, I think... however, we all will figure out
-M
> For the user it is easier to recognize than that there is just another
> competitor in this area (JSF, ORM, etc)
>
>
> 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
Posted by Matthias Wessendorf <ma...@apache.org>.
things like these are some topics that should have been discussed before.
well, again we start to care when it already happend
+1 on the "no spring in tomahawk"
-M
On 2/22/07, Martin Marinschek <ma...@gmail.com> wrote:
> It's not an arbitrary and unnecessary split - as:
>
> - it's not a component library, it is about glue-code
> - it works with any component library, not only tomahawk
> - it has dependencies to Spring, and I personally don't think tomahawk
> should have some
>
> regards,
>
> Martin
>
> On 2/22/07, Mike Kienenberger <mk...@gmail.com> wrote:
> > You've answered some of the management issues, but you still haven't
> > addressed what the difference between "tomahawk and/or sandbox" and
> > "fusion" will be.
> >
> > From my understanding so far, this is still just a collection of
> > components, and I don't see why it needs to be separate from the
> > sandbox or tomahawk. Our stated goal in the past has been to unify
> > the various subprojects (ie, merge tomahawk and trinidad; merge
> > tomahawk and tobago). This seems contrary to that goal since fusion
> > (an ironic name in this context) is making an arbitrary and
> > unnecessary split of the tomahawk project.
> >
> >
> >
> > On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> > > Hi Mike!
> > > > In the future, please remember that such reviews and conclusions
> > > > *must* be made on the mailing list.
> > > Ok, sorry for this.
> > >
> > > > As to the actual merits of the subproject, I don't understand what
> > > > value it adds to have this in both the sandbox and in "fusion". How
> > > > do the two subprojects differ? Is it just a matter of different
> > > > dependencies?
> > > The parts in the sandbox will deleted once the setup of the new project
> > > has settled down.
> > > Afterwards a release of MyFaces Fusion (or whatever name it will have in
> > > the end) should follow soon.
> > >
> > > For the user it is easier to recognize than that there is just another
> > > competitor in this area (JSF, ORM, etc)
> > >
> > >
> > > Ciao,
> > > Mario
> > >
> > >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Martin Marinschek schrieb:
> @troubles: just like you should never put component-bindings in
> session-scope.
>
@Solved in fusion...
Re: MyFaces Fusion
Posted by Martin Marinschek <ma...@gmail.com>.
@troubles: just like you should never put component-bindings in session-scope.
regards,
Martin
On 2/23/07, Werner Punz <we...@gmail.com> wrote:
> Werner Punz schrieb:
> >
> > Hold on matthias a little bit, I just gave mario the code for the jpa
> > conversation glue.
> > So I have jpa already running here.
> >
> Btw. the conversation stuff is excellent,
> once configured you work within the conversation context within
> one entity manager,
> @Transactional and @PersistenceContext works like a charm within
> the spring 2.0 jpa realm, so no Template Base classes are needed
> and you keep the entity manager until the conversation
> is closed or timed out...
>
>
> One thing however, as it seems the conversational stuff has to be
> set on the domain of the business layer, never ever push conversations
> into the realm of view controllers for now, that screams for trouble.
> (for now currently, but component bindings are an inherent problem
> anyway), this is not really a problem, but you have to have it in mind.
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Werner Punz schrieb:
>
> Hold on matthias a little bit, I just gave mario the code for the jpa
> conversation glue.
> So I have jpa already running here.
>
Btw. the conversation stuff is excellent,
once configured you work within the conversation context within
one entity manager,
@Transactional and @PersistenceContext works like a charm within
the spring 2.0 jpa realm, so no Template Base classes are needed
and you keep the entity manager until the conversation
is closed or timed out...
One thing however, as it seems the conversational stuff has to be
set on the domain of the business layer, never ever push conversations
into the realm of view controllers for now, that screams for trouble.
(for now currently, but component bindings are an inherent problem
anyway), this is not really a problem, but you have to have it in mind.
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Matthias Wessendorf schrieb:
> On 2/22/07, Mike Kienenberger <mk...@gmail.com> wrote:
>> My initial impression (now that the administrata is out of the way) is
>> that the subproject sounds useful, now that I see that we aren't
>> making yet another component library. I think it's an excellent idea
>> to get better examples of JSF and JPA working together since these are
>> now considered standards.
>
> right. I'll check that stuff out and I am thinking about adding it to
> my trinidad_spring_shale_jpa demo
>
Hold on matthias a little bit, I just gave mario the code for the jpa
conversation glue.
So I have jpa already running here.
Re: MyFaces Fusion
Posted by Matthias Wessendorf <ma...@apache.org>.
On 2/22/07, Mike Kienenberger <mk...@gmail.com> wrote:
> My initial impression (now that the administrata is out of the way) is
> that the subproject sounds useful, now that I see that we aren't
> making yet another component library. I think it's an excellent idea
> to get better examples of JSF and JPA working together since these are
> now considered standards.
right. I'll check that stuff out and I am thinking about adding it to
my trinidad_spring_shale_jpa demo
> I am slightly concerned that we're spreading our focus a bit with this
> subproject. Up to this point, we've provided a JSF implementation
> and component libraries. Providing an application framework on top
> of that seems like something that would fit better with what Shale is
> doing. However, I don't think that's a showstopper, just something
> to keep in mind.
perhaps this is an area, where we can work with shale together on JSR
299 (web beans)
I need to ping Geir on how we can create a apache wide mailing list
for that JSR, for those committers, signed the NDA
-M
> On 2/22/07, Martin Marinschek <ma...@gmail.com> wrote:
> > It's not an arbitrary and unnecessary split - as:
> >
> > - it's not a component library, it is about glue-code
> > - it works with any component library, not only tomahawk
> > - it has dependencies to Spring, and I personally don't think tomahawk
> > should have some
> >
> > regards,
> >
> > Martin
> >
> > On 2/22/07, Mike Kienenberger <mk...@gmail.com> wrote:
> > > You've answered some of the management issues, but you still haven't
> > > addressed what the difference between "tomahawk and/or sandbox" and
> > > "fusion" will be.
> > >
> > > From my understanding so far, this is still just a collection of
> > > components, and I don't see why it needs to be separate from the
> > > sandbox or tomahawk. Our stated goal in the past has been to unify
> > > the various subprojects (ie, merge tomahawk and trinidad; merge
> > > tomahawk and tobago). This seems contrary to that goal since fusion
> > > (an ironic name in this context) is making an arbitrary and
> > > unnecessary split of the tomahawk project.
> > >
> > >
> > >
> > > On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> > > > Hi Mike!
> > > > > In the future, please remember that such reviews and conclusions
> > > > > *must* be made on the mailing list.
> > > > Ok, sorry for this.
> > > >
> > > > > As to the actual merits of the subproject, I don't understand what
> > > > > value it adds to have this in both the sandbox and in "fusion". How
> > > > > do the two subprojects differ? Is it just a matter of different
> > > > > dependencies?
> > > > The parts in the sandbox will deleted once the setup of the new project
> > > > has settled down.
> > > > Afterwards a release of MyFaces Fusion (or whatever name it will have in
> > > > the end) should follow soon.
> > > >
> > > > For the user it is easier to recognize than that there is just another
> > > > competitor in this area (JSF, ORM, etc)
> > > >
> > > >
> > > > Ciao,
> > > > Mario
> > > >
> > > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion
Posted by Mike Kienenberger <mk...@gmail.com>.
My initial impression (now that the administrata is out of the way) is
that the subproject sounds useful, now that I see that we aren't
making yet another component library. I think it's an excellent idea
to get better examples of JSF and JPA working together since these are
now considered standards.
I am slightly concerned that we're spreading our focus a bit with this
subproject. Up to this point, we've provided a JSF implementation
and component libraries. Providing an application framework on top
of that seems like something that would fit better with what Shale is
doing. However, I don't think that's a showstopper, just something
to keep in mind.
On 2/22/07, Martin Marinschek <ma...@gmail.com> wrote:
> It's not an arbitrary and unnecessary split - as:
>
> - it's not a component library, it is about glue-code
> - it works with any component library, not only tomahawk
> - it has dependencies to Spring, and I personally don't think tomahawk
> should have some
>
> regards,
>
> Martin
>
> On 2/22/07, Mike Kienenberger <mk...@gmail.com> wrote:
> > You've answered some of the management issues, but you still haven't
> > addressed what the difference between "tomahawk and/or sandbox" and
> > "fusion" will be.
> >
> > From my understanding so far, this is still just a collection of
> > components, and I don't see why it needs to be separate from the
> > sandbox or tomahawk. Our stated goal in the past has been to unify
> > the various subprojects (ie, merge tomahawk and trinidad; merge
> > tomahawk and tobago). This seems contrary to that goal since fusion
> > (an ironic name in this context) is making an arbitrary and
> > unnecessary split of the tomahawk project.
> >
> >
> >
> > On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> > > Hi Mike!
> > > > In the future, please remember that such reviews and conclusions
> > > > *must* be made on the mailing list.
> > > Ok, sorry for this.
> > >
> > > > As to the actual merits of the subproject, I don't understand what
> > > > value it adds to have this in both the sandbox and in "fusion". How
> > > > do the two subprojects differ? Is it just a matter of different
> > > > dependencies?
> > > The parts in the sandbox will deleted once the setup of the new project
> > > has settled down.
> > > Afterwards a release of MyFaces Fusion (or whatever name it will have in
> > > the end) should follow soon.
> > >
> > > For the user it is easier to recognize than that there is just another
> > > competitor in this area (JSF, ORM, etc)
> > >
> > >
> > > 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
Posted by Martin Marinschek <ma...@gmail.com>.
It's not an arbitrary and unnecessary split - as:
- it's not a component library, it is about glue-code
- it works with any component library, not only tomahawk
- it has dependencies to Spring, and I personally don't think tomahawk
should have some
regards,
Martin
On 2/22/07, Mike Kienenberger <mk...@gmail.com> wrote:
> You've answered some of the management issues, but you still haven't
> addressed what the difference between "tomahawk and/or sandbox" and
> "fusion" will be.
>
> From my understanding so far, this is still just a collection of
> components, and I don't see why it needs to be separate from the
> sandbox or tomahawk. Our stated goal in the past has been to unify
> the various subprojects (ie, merge tomahawk and trinidad; merge
> tomahawk and tobago). This seems contrary to that goal since fusion
> (an ironic name in this context) is making an arbitrary and
> unnecessary split of the tomahawk project.
>
>
>
> On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi Mike!
> > > In the future, please remember that such reviews and conclusions
> > > *must* be made on the mailing list.
> > Ok, sorry for this.
> >
> > > As to the actual merits of the subproject, I don't understand what
> > > value it adds to have this in both the sandbox and in "fusion". How
> > > do the two subprojects differ? Is it just a matter of different
> > > dependencies?
> > The parts in the sandbox will deleted once the setup of the new project
> > has settled down.
> > Afterwards a release of MyFaces Fusion (or whatever name it will have in
> > the end) should follow soon.
> >
> > For the user it is easier to recognize than that there is just another
> > competitor in this area (JSF, ORM, etc)
> >
> >
> > 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
Posted by Mario Ivankovits <ma...@ops.co.at>.
Mike Kienenberger schrieb:
> Well, the thread started with this statement, so you'll have to
> forgive me if I thought it was true :-)
>
>> MyFaces Fusion is just a collection of already existing myfaces
>> sandbox components.
Instead of components I should have written code.
There are two or three components left in fusion directly related to the
code, the rest is system code.
Ciao,
Mario
Re: MyFaces Fusion
Posted by Mike Kienenberger <mk...@gmail.com>.
Well, the thread started with this statement, so you'll have to
forgive me if I thought it was true :-)
> MyFaces Fusion is just a collection of already existing myfaces sandbox components.
On 2/22/07, Werner Punz <we...@gmail.com> wrote:
> Mike Kienenberger schrieb:
> > You've answered some of the management issues, but you still haven't
> > addressed what the difference between "tomahawk and/or sandbox" and
> > "fusion" will be.
> >
> Since I am probably the first one who will use it
> (call me guinea pig)
> fusion is an application stack/framework, I have
> yet to check it out (I have not seen the code)
> It is sort of in similar domains as shale
> but different areas and targets (the conversation
> is moved from the tag into spring etc...)
>
>
> > From my understanding so far, this is still just a collection of
> > components, and I don't see why it needs to be separate from the
> No not really, I am not sure how much is in (not got the code yet), because
> I am currently only interested in the spring conversation context,
> which I can hook into jpa for conversation/transaction handling.
> But it definitely is not just a set of components ;-)
>
>
>
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Mike Kienenberger schrieb:
> You've answered some of the management issues, but you still haven't
> addressed what the difference between "tomahawk and/or sandbox" and
> "fusion" will be.
>
Since I am probably the first one who will use it
(call me guinea pig)
fusion is an application stack/framework, I have
yet to check it out (I have not seen the code)
It is sort of in similar domains as shale
but different areas and targets (the conversation
is moved from the tag into spring etc...)
> From my understanding so far, this is still just a collection of
> components, and I don't see why it needs to be separate from the
No not really, I am not sure how much is in (not got the code yet), because
I am currently only interested in the spring conversation context,
which I can hook into jpa for conversation/transaction handling.
But it definitely is not just a set of components ;-)
Re: MyFaces Fusion
Posted by Mike Kienenberger <mk...@gmail.com>.
You've answered some of the management issues, but you still haven't
addressed what the difference between "tomahawk and/or sandbox" and
"fusion" will be.
>From my understanding so far, this is still just a collection of
components, and I don't see why it needs to be separate from the
sandbox or tomahawk. Our stated goal in the past has been to unify
the various subprojects (ie, merge tomahawk and trinidad; merge
tomahawk and tobago). This seems contrary to that goal since fusion
(an ironic name in this context) is making an arbitrary and
unnecessary split of the tomahawk project.
On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Mike!
> > In the future, please remember that such reviews and conclusions
> > *must* be made on the mailing list.
> Ok, sorry for this.
>
> > As to the actual merits of the subproject, I don't understand what
> > value it adds to have this in both the sandbox and in "fusion". How
> > do the two subprojects differ? Is it just a matter of different
> > dependencies?
> The parts in the sandbox will deleted once the setup of the new project
> has settled down.
> Afterwards a release of MyFaces Fusion (or whatever name it will have in
> the end) should follow soon.
>
> For the user it is easier to recognize than that there is just another
> competitor in this area (JSF, ORM, etc)
>
>
> Ciao,
> Mario
>
>
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Mhh seems like the dynaform jdk5 stuff also will be moved over.
Werner
Mike Kienenberger schrieb:
> On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
>> The parts in the sandbox will deleted once the setup of the new project
>> has settled down.
>
> Mario,
>
> Other than the conversation tag, what else will be removed from the
> sandbox?
>
> Also, how is this going to affect the users who are currently using
> these sandbox parts? At minimum, we should have a separate thread on
> myface-users identifying the parts and giving the end-users some
> warning. I know the sandbox is subject to change, but I think most
> of us expect those components to remain around in some form once they
> show merit. I honestly don't know what the user base for these
> migrating components is, though.
>
Re: MyFaces Fusion
Posted by Arash Rajaeeyan <ar...@gmail.com>.
I can send a working copy to your private email. if you want.
zubin is going to use it in his book.
I am changing it each day to make it easier for developers learning MyFaces.
On 2/23/07, Matthias Wessendorf <ma...@apache.org> wrote:
>
> Arash-
>
> is your app somewhere accessable ?
>
> -M
>
> On 2/23/07, Arash Rajaeeyan <ar...@gmail.com> wrote:
> > I have also developed a simple application which I want to use teaching
> > MyFaces.
> > I have used Seam components for integration with JPA as data access
> layer.
> > It looks like this fusion lead a more pure MyFaces application.
> > and I am ready to use it, if you provide some minimum guidelines for
> rest of
> > us.
> >
> >
> > On 2/23/07, Gerald Müllan < bierbrauen@gmail.com> wrote:
> > > Regarding the demo-app, i could help out with a nice open-source
> > > design which i had improved and used in a sourceforge app and our
> > > jsf@work website:
> > >
> > > http://jsfatwork.irian.at
> > >
> > > Let me know if it seems to be useful for MyFaces Fusion. I am willing
> > > to re-design the demo-app so that it is human-readable :)
> > >
> > > cheers,
> > >
> > > Gerald
> > >
> > > On 2/23/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> > > > Hi Cagatay!
> > > >
> > > > > I'd really really like to help if you need:)
> > > > There is plenty of room to help :-)
> > > > Thanks!
> > > >
> > > > Short term todos are:
> > > >
> > > > * Demo App
> > > > * Documentation
> > > >
> > > > Regarding the DemoApp, maybe Werner is able to donate one, if not we
> > > > have to build one.
> > > > Would be great if you could help there if we have to cross that
> bridge.
> > > >
> > > > At least the initial Documentation has to be done by myself
> > > > (unfortunately ;-) )
> > > >
> > > > Ciao,
> > > > Mario
> > > >
> > > >
> > >
> > >
> > > --
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
> >
> >
> > --
> > Arash Rajaeeyan
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
--
Arash Rajaeeyan
Re: MyFaces Fusion
Posted by Matthias Wessendorf <ma...@apache.org>.
Arash-
is your app somewhere accessable ?
-M
On 2/23/07, Arash Rajaeeyan <ar...@gmail.com> wrote:
> I have also developed a simple application which I want to use teaching
> MyFaces.
> I have used Seam components for integration with JPA as data access layer.
> It looks like this fusion lead a more pure MyFaces application.
> and I am ready to use it, if you provide some minimum guidelines for rest of
> us.
>
>
> On 2/23/07, Gerald Müllan < bierbrauen@gmail.com> wrote:
> > Regarding the demo-app, i could help out with a nice open-source
> > design which i had improved and used in a sourceforge app and our
> > jsf@work website:
> >
> > http://jsfatwork.irian.at
> >
> > Let me know if it seems to be useful for MyFaces Fusion. I am willing
> > to re-design the demo-app so that it is human-readable :)
> >
> > cheers,
> >
> > Gerald
> >
> > On 2/23/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> > > Hi Cagatay!
> > >
> > > > I'd really really like to help if you need:)
> > > There is plenty of room to help :-)
> > > Thanks!
> > >
> > > Short term todos are:
> > >
> > > * Demo App
> > > * Documentation
> > >
> > > Regarding the DemoApp, maybe Werner is able to donate one, if not we
> > > have to build one.
> > > Would be great if you could help there if we have to cross that bridge.
> > >
> > > At least the initial Documentation has to be done by myself
> > > (unfortunately ;-) )
> > >
> > > Ciao,
> > > Mario
> > >
> > >
> >
> >
> > --
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
>
> --
> Arash Rajaeeyan
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: MyFaces Fusion
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Arash!
> It looks like this fusion lead a more pure MyFaces application.
> and I am ready to use it, if you provide some minimum guidelines for
> rest of us.
Yep, I am working on it ... should be available soonish.
Ciao,
Mario
Re: MyFaces Fusion
Posted by Arash Rajaeeyan <ar...@gmail.com>.
I have also developed a simple application which I want to use teaching
MyFaces.
I have used Seam components for integration with JPA as data access layer.
It looks like this fusion lead a more pure MyFaces application.
and I am ready to use it, if you provide some minimum guidelines for rest of
us.
On 2/23/07, Gerald Müllan <bi...@gmail.com> wrote:
>
> Regarding the demo-app, i could help out with a nice open-source
> design which i had improved and used in a sourceforge app and our
> jsf@work website:
>
> http://jsfatwork.irian.at
>
> Let me know if it seems to be useful for MyFaces Fusion. I am willing
> to re-design the demo-app so that it is human-readable :)
>
> cheers,
>
> Gerald
>
> On 2/23/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi Cagatay!
> >
> > > I'd really really like to help if you need:)
> > There is plenty of room to help :-)
> > Thanks!
> >
> > Short term todos are:
> >
> > * Demo App
> > * Documentation
> >
> > Regarding the DemoApp, maybe Werner is able to donate one, if not we
> > have to build one.
> > Would be great if you could help there if we have to cross that bridge.
> >
> > At least the initial Documentation has to be done by myself
> > (unfortunately ;-) )
> >
> > Ciao,
> > Mario
> >
> >
>
>
> --
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
Arash Rajaeeyan
Re: MyFaces Fusion
Posted by Gerald Müllan <bi...@gmail.com>.
Regarding the demo-app, i could help out with a nice open-source
design which i had improved and used in a sourceforge app and our
jsf@work website:
http://jsfatwork.irian.at
Let me know if it seems to be useful for MyFaces Fusion. I am willing
to re-design the demo-app so that it is human-readable :)
cheers,
Gerald
On 2/23/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Cagatay!
>
> > I'd really really like to help if you need:)
> There is plenty of room to help :-)
> Thanks!
>
> Short term todos are:
>
> * Demo App
> * Documentation
>
> Regarding the DemoApp, maybe Werner is able to donate one, if not we
> have to build one.
> Would be great if you could help there if we have to cross that bridge.
>
> At least the initial Documentation has to be done by myself
> (unfortunately ;-) )
>
> 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
Posted by Cagatay Civici <ca...@gmail.com>.
Hi Mario,
In the meantime I'll start digging the codebase and hopefully reach a level
where I can start to contribute soon:)
Cheers,
Cagatay
On 2/23/07, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi Cagatay!
>
> > I'd really really like to help if you need:)
> There is plenty of room to help :-)
> Thanks!
>
> Short term todos are:
>
> * Demo App
> * Documentation
>
> Regarding the DemoApp, maybe Werner is able to donate one, if not we
> have to build one.
> Would be great if you could help there if we have to cross that bridge.
>
> At least the initial Documentation has to be done by myself
> (unfortunately ;-) )
>
> Ciao,
> Mario
>
>
Re: MyFaces Fusion
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Cagatay!
> I'd really really like to help if you need:)
There is plenty of room to help :-)
Thanks!
Short term todos are:
* Demo App
* Documentation
Regarding the DemoApp, maybe Werner is able to donate one, if not we
have to build one.
Would be great if you could help there if we have to cross that bridge.
At least the initial Documentation has to be done by myself
(unfortunately ;-) )
Ciao,
Mario
Re: MyFaces Fusion
Posted by Cagatay Civici <ca...@gmail.com>.
Hi,
Great job Mario, I'm also interested in conversation stuff with spring and
jsf, personally I was sick of getting lazyinitexception when doing wizards
with jsf-spring-hibernate before.
I'd really really like to help if you need:)
Regards,
Cagatay
On 2/22/07, Mike Kienenberger <mk...@gmail.com> wrote:
>
> Hey Mario,
>
> Sounds good. I think a simple announcement to the user list
> regarding moving the components is appropriate. Sounds like there is
> no one who will be affected, except those who will be moving to
> "fusion" anyway (we should come up with a new name right away if a new
> name is necessary).
>
> On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi!
> > > Other than the conversation tag, what else will be removed from the
> > > sandbox?
> > tomahawk-sandbox
> > There is a "behind the scenes" code called "RequestParameterProvider"
> > which allows you to add a class which will then be called when a URL
> > will be encoded.
> > This is the central mechanism to ensure that a url parameter called
> > conversationContext is existent on each url, though, you can configure
> > it to add any other parameter you would like to.
> > IMHO its very unlikely that an application will make any use of this
> > mechanism, its more something for libraries.
> > I don't remember someone else ever asked a single question about it, so
> > I think its not in use by someone else.
> >
> > tomahawk-sandbox15
> > There is the dynaForm stuff which creates a input/output formular based
> > on EJB3 annotations (including validators/converters) with some
> > additional features e.g. to create select listboxes in case of 1:n
> > annotations.
> > Since this is a somehow complex piece of code and there is no
> > documentation (though, there is a demo) and I've never announced it on
> > the user list I am pretty sure there is no user now.
> >
> >
> > Regarding the ConversationTag itself I know at least a single person who
> > helped me debugging it. I think its a month back or so where I asked him
> > if he still uses it, and he do. He told me he'll have a look at the
> > spring like solution too.
> >
> >
> > Anyway. As you said, Before we remove anything from the sandbox we
> > definitely should ask on the user list and I'll be of any help if it
> > comes to migration issues.
> > Maybe we can move some of the deprecated sandbox code to a code.google
> > or sourceforge project, though, in dormant mode for sure.
> >
> > Ciao,
> > Mario
> >
> >
>
Re: MyFaces Fusion
Posted by Mike Kienenberger <mk...@gmail.com>.
Hey Mario,
Sounds good. I think a simple announcement to the user list
regarding moving the components is appropriate. Sounds like there is
no one who will be affected, except those who will be moving to
"fusion" anyway (we should come up with a new name right away if a new
name is necessary).
On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
> > Other than the conversation tag, what else will be removed from the
> > sandbox?
> tomahawk-sandbox
> There is a "behind the scenes" code called "RequestParameterProvider"
> which allows you to add a class which will then be called when a URL
> will be encoded.
> This is the central mechanism to ensure that a url parameter called
> conversationContext is existent on each url, though, you can configure
> it to add any other parameter you would like to.
> IMHO its very unlikely that an application will make any use of this
> mechanism, its more something for libraries.
> I don't remember someone else ever asked a single question about it, so
> I think its not in use by someone else.
>
> tomahawk-sandbox15
> There is the dynaForm stuff which creates a input/output formular based
> on EJB3 annotations (including validators/converters) with some
> additional features e.g. to create select listboxes in case of 1:n
> annotations.
> Since this is a somehow complex piece of code and there is no
> documentation (though, there is a demo) and I've never announced it on
> the user list I am pretty sure there is no user now.
>
>
> Regarding the ConversationTag itself I know at least a single person who
> helped me debugging it. I think its a month back or so where I asked him
> if he still uses it, and he do. He told me he'll have a look at the
> spring like solution too.
>
>
> Anyway. As you said, Before we remove anything from the sandbox we
> definitely should ask on the user list and I'll be of any help if it
> comes to migration issues.
> Maybe we can move some of the deprecated sandbox code to a code.google
> or sourceforge project, though, in dormant mode for sure.
>
> Ciao,
> Mario
>
>
Re: MyFaces Fusion
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Other than the conversation tag, what else will be removed from the
> sandbox?
tomahawk-sandbox
There is a "behind the scenes" code called "RequestParameterProvider"
which allows you to add a class which will then be called when a URL
will be encoded.
This is the central mechanism to ensure that a url parameter called
conversationContext is existent on each url, though, you can configure
it to add any other parameter you would like to.
IMHO its very unlikely that an application will make any use of this
mechanism, its more something for libraries.
I don't remember someone else ever asked a single question about it, so
I think its not in use by someone else.
tomahawk-sandbox15
There is the dynaForm stuff which creates a input/output formular based
on EJB3 annotations (including validators/converters) with some
additional features e.g. to create select listboxes in case of 1:n
annotations.
Since this is a somehow complex piece of code and there is no
documentation (though, there is a demo) and I've never announced it on
the user list I am pretty sure there is no user now.
Regarding the ConversationTag itself I know at least a single person who
helped me debugging it. I think its a month back or so where I asked him
if he still uses it, and he do. He told me he'll have a look at the
spring like solution too.
Anyway. As you said, Before we remove anything from the sandbox we
definitely should ask on the user list and I'll be of any help if it
comes to migration issues.
Maybe we can move some of the deprecated sandbox code to a code.google
or sourceforge project, though, in dormant mode for sure.
Ciao,
Mario
Re: MyFaces Fusion
Posted by Mike Kienenberger <mk...@gmail.com>.
On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> The parts in the sandbox will deleted once the setup of the new project
> has settled down.
Mario,
Other than the conversation tag, what else will be removed from the sandbox?
Also, how is this going to affect the users who are currently using
these sandbox parts? At minimum, we should have a separate thread on
myface-users identifying the parts and giving the end-users some
warning. I know the sandbox is subject to change, but I think most
of us expect those components to remain around in some form once they
show merit. I honestly don't know what the user base for these
migrating components is, though.
Re: MyFaces Fusion
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Mike!
> In the future, please remember that such reviews and conclusions
> *must* be made on the mailing list.
Ok, sorry for this.
> As to the actual merits of the subproject, I don't understand what
> value it adds to have this in both the sandbox and in "fusion". How
> do the two subprojects differ? Is it just a matter of different
> dependencies?
The parts in the sandbox will deleted once the setup of the new project
has settled down.
Afterwards a release of MyFaces Fusion (or whatever name it will have in
the end) should follow soon.
For the user it is easier to recognize than that there is just another
competitor in this area (JSF, ORM, etc)
Ciao,
Mario
Re: MyFaces Fusion
Posted by Mike Kienenberger <mk...@gmail.com>.
On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Some of us reviewed it (offlist) and we came to the conclusion that it
> has enough power to live as separate project.
In the future, please remember that such reviews and conclusions
*must* be made on the mailing list.
....
As to the actual merits of the subproject, I don't understand what
value it adds to have this in both the sandbox and in "fusion". How
do the two subprojects differ? Is it just a matter of different
dependencies?
Re: MyFaces Fusion
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Matthias!
> I like the idea, but perhaps in future, please send out an email. I
> bet that won't hurt.
No, wouldn't have hurt, you are right.
However, now everyone is able to review real facts. If we do not agree
about having it that way in MyFaces land I'll "svn rm/svn mv/whatever" it.
Nothing is put in stone just by committing it.
Ciao,
Mario
Re: MyFaces Fusion
Posted by Dennis Byrne <de...@dbyrne.net>.
<snip>
> Some of us reviewed it (offlist) and we came to the conclusion that it
> has enough power to live as separate project.
> </snip>
>
> my understanding is that we all should at least have been involved in
> this discussion. hard to be a healthy community, when three or four do
> offline development.
> To me to that is against a key of apache-style projects.
>
I agree.
> I like the idea, but perhaps in future, please send out an email. I
> bet that won't hurt.
>
> We discussed that already back 2006, when sb. did an "alien commit"
> for the stuff of Ernst
>
> Thanks,
> Matthias
>
> On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi!
> >
> > MyFaces Fusion is just a collection of already existing myfaces sandbox
> > components.
> >
> > The main goal of this project is to ease the development of JSF
> > applications especially if they have to deal with an ORM backend.
> >
> > I tried to do so a while back by developing a ConversationTag, which
> > worked not that bad, but I was told that such a logic should not be put
> > into the view.
> > And well, the feeling was that it would be nice if it could be easier to
> > deal with conversation.
> >
> > Spring allowed us to create a custom scope AND to reuse the well known
> > way how it deal with persistence.
> >
> > So I've rewritten the ConversationTag to use Spring and first tests were
> > really nice. No need to learn any new programming style, just code as
> > before.
> >
> > Some of us reviewed it (offlist) and we came to the conclusion that it
> > has enough power to live as separate project.
> > Thats why I created the initial structure - not really new code, just
> > taken from the sandbox.
> > I know, I didnt use the svn cp command, but, since ALL of this code has
> > been developed by me and there is not much value in the current history,
> > I did it the easier way. Sorry for this.
> >
> >
> > The current structure is divided into core and core15.
> >
> >
> > The core part contains the ConversationTag and the
> RequestParameterProvider.
> > In contrast to the tomahawk-sandbox ConversationTag the conversation tag
> > now works using Spring and a custom scope.
> > The RequestParameterProvider is used to allow multiple open windows
> > within the same session.
> > So e.g. I you have a order processing system you can open it twice and
> > work in two independed conversations (even if their names are the same)
> >
> > The core15 part contains the DynaForm from tomahawk-sandbox15
> > It will create parts of the view automatically based on EJB3 annotated
> > beans.
> > Its migth become a great time-saver for simple tables.
> >
> >
> > The current check-in do not bulid usable jars, some maven/tld/xml stuff
> > has to be put in line, I hope to manage to do so in the next few hours.
> > In the next few days I'll commit a sample application (given that you do
> > not cancel my efforts), afterwards the documentation has to be done.
> >
> > The status of this project is sandbox like.
> >
> > Ciao,
> > Mario
> >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
--
Dennis Byrne
Re: MyFaces Fusion
Posted by Matthias Wessendorf <ma...@apache.org>.
Mario,
that all sounds nice and very interesting. I agree on the sandbox
status and that it might be good to be a "separate" project.
What I don't understand is this:
<snip>
Some of us reviewed it (offlist) and we came to the conclusion that it
has enough power to live as separate project.
</snip>
my understanding is that we all should at least have been involved in
this discussion. hard to be a healthy community, when three or four do
offline development.
To me to that is against a key of apache-style projects.
I like the idea, but perhaps in future, please send out an email. I
bet that won't hurt.
We discussed that already back 2006, when sb. did an "alien commit"
for the stuff of Ernst
Thanks,
Matthias
On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>
> MyFaces Fusion is just a collection of already existing myfaces sandbox
> components.
>
> The main goal of this project is to ease the development of JSF
> applications especially if they have to deal with an ORM backend.
>
> I tried to do so a while back by developing a ConversationTag, which
> worked not that bad, but I was told that such a logic should not be put
> into the view.
> And well, the feeling was that it would be nice if it could be easier to
> deal with conversation.
>
> Spring allowed us to create a custom scope AND to reuse the well known
> way how it deal with persistence.
>
> So I've rewritten the ConversationTag to use Spring and first tests were
> really nice. No need to learn any new programming style, just code as
> before.
>
> Some of us reviewed it (offlist) and we came to the conclusion that it
> has enough power to live as separate project.
> Thats why I created the initial structure - not really new code, just
> taken from the sandbox.
> I know, I didnt use the svn cp command, but, since ALL of this code has
> been developed by me and there is not much value in the current history,
> I did it the easier way. Sorry for this.
>
>
> The current structure is divided into core and core15.
>
>
> The core part contains the ConversationTag and the RequestParameterProvider.
> In contrast to the tomahawk-sandbox ConversationTag the conversation tag
> now works using Spring and a custom scope.
> The RequestParameterProvider is used to allow multiple open windows
> within the same session.
> So e.g. I you have a order processing system you can open it twice and
> work in two independed conversations (even if their names are the same)
>
> The core15 part contains the DynaForm from tomahawk-sandbox15
> It will create parts of the view automatically based on EJB3 annotated
> beans.
> Its migth become a great time-saver for simple tables.
>
>
> The current check-in do not bulid usable jars, some maven/tld/xml stuff
> has to be put in line, I hope to manage to do so in the next few hours.
> In the next few days I'll commit a sample application (given that you do
> not cancel my efforts), afterwards the documentation has to be done.
>
> The status of this project is sandbox like.
>
> 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
Posted by Werner Punz <we...@gmail.com>.
Additon,
so that you can see that there is nothing hidden in the dao and bo
layers which hides complexity:
dao:
public User createUpdateUser(User user) {
if(!getEm().contains(user) && user.getId() == null)
getEm().persist(user);
//we flush here because the user already exists
//since we apply conversations here no merge is needed anymore
getEm().flush();
return user;
return null;
}
bo:
@Transactional
public User createUpdateUser(User user) {
return userdao.createUpdateUser(user);
}
the bo weaves a transaction and calls the dao
the dao flushes in edit cases
and persists in create
in case of a lost entity we bomb out with an exception and a roollback
but i have yet to see that case.
of course all this can be combined into one conversation like seam does
it in its examples, but I opted for the dao bo pattern.
Werner Punz schrieb:
> Ok here is a first small bite:
>
> What we have here is a simple detail conversation
> the master gets injected so that we can have work done
> after update
> but lives in its own conversation
>
> what happens the user id is injected so is the master
> (design decision i chose, you probably could get
> the affected dataset also from the master if you set it there,
> but I wanted to have clear boundaries so i pushed in the uid of the user
> and have it reloaded insted of merging it in.
>
> The entire time the form is open the conversation keeps the user and the
> db connection
>
> now if you want to save it...
> public String dosubmit() {
> flushCurrentUser();
>
> usermasterview.findUsers();//we refill our view dont access the
> db objects there, different em
> return StdOutcome.SUCCESS;
> }
>
>
> flushcurrentUser basically just goes into an entity manager flush
> (the Entity Manager is injected by @PersistenceContext somewhere in the
> bo layer automatically, fusion + spring takes care of that,
> hence theoretically you could go for a seam like approach of injecting
> the PersistenceContext directly into the conversation.
>
> anyway, em.flush that is it or em.persist in case of a create
> all the time you work on the same user object coming from the entity
> manager and having it referenced there.
>
> usermasterview.findUsers();//
>
> refills the master view with new data so that at a back
> or go_master situation you have the updated data there
>
> once you are done
> Conversation.getCurrentInstance().invalidate();
> return "go_master";
>
> For simple navigational use cases you can invalidate all open
> conversations at once, so that you do not have pending conversations.
> If you still run into those, the conversations time out after while.
>
>
>
>
>
> public class UserDetailView {
> UserBO userbo;
> User user = new User();
> UserMasterView usermasterview;
>
> int userid;
> boolean postinitialized = false;
> String viewmode = "create";
>
>
> public int getUserid() {
> return userid;
> }
>
>
> public void setUserid(int userid) {
> this.userid = userid;
> if(!postinitialized) {
> postInitialize(userid);
> }
> }
>
>
>
> public void setPreinitUserid(int userid) {
> postInitialize(userid);
> }
> public int getPreinitUserid() {
> return -1;
> }
>
>
> public void postInitialize(int userid) {
> postinitialized = true;
> user = userbo.loadUserById(userid);
> viewmode = "edit";
> }
>
> public String dosubmit() {
> flushCurrentUser();
>
> usermasterview.findUsers();//we refill our view dont access the
> db objects there, different em
> return StdOutcome.SUCCESS;
> }
>
> public String dogomaster() {
> Conversation.getCurrentInstance().invalidate();
> return "go_master";
> }
>
>
> public void flushCurrentUser() {
> userbo.createUpdateUser((User)user);
> }
>
>
>
> public UserBO getUserbo() {
> return userbo;
> }
>
> public void setUserbo(UserBO userbo) {
> this.userbo = userbo;
> }
>
>
> public User getUser() {
> return user;
> }
>
> public void setUser(User user) {
> this.user = user;
> }
>
> public String getViewmode() {
> return viewmode;
> }
>
> public void setViewmode(String viewmode) {
> this.viewmode = viewmode;
> }
>
> public UserMasterView getUsermasterview() {
> return usermasterview;
> }
>
> public void setUsermasterview(UserMasterView usermasterview) {
> this.usermasterview = usermasterview;
> }
>
> }
>
>
>
> Arash Rajaeeyan schrieb:
>> how can I see the result of this work?
>>
>> On 2/27/07, *Werner Punz* <werner.punz@gmail.com
>> <ma...@gmail.com>> wrote:
>>
>> Sorry to jump in here again,
>> I have been playing guinea pig the last
>> week for marios work.
>> All I can say is this thing now is highly usable
>> by now.
>> You can put a view controller under conversation scope
>> (not a shale one yet, you will lose the callbacks)
>> and simply work on the stuff now like you would do in a rich client
>> environment with an EntityManage, Hibernate Session open for the entire
>> conversation.
>>
>> once you hit a point when you want to terminate, you can have the view
>> controller/conversation invalidate itself or restart itself.
>>
>> Also binding component bindings onto such a conversation is taken care
>> of, you can push them into a separate bean which you weave in by
>> a scope of request and aop:scoped-proxy, then you basically get a fresh
>> view onto your backend component bindings at every request.
>>
>> To sum it up, I just almost finished a first full master detail crud
>> ( I have done several details forms before)
>> The master form has about 30 lines of core code, excluding the setters
>> and getters already dealting with dao calling, handling the query part
>> etc... and adding a detail was a matter of one hour of figuring out
>> which patterns work best and a few minutes of implementation
>> handling new update and delete.
>> The objects you work with always are the same the orm layer accesses,
>> so a simple update ends up normally with
>>
>> entitymanager.flush ();
>>
>> And btw. bindings for hibernate and jpa already are in place...
>>
>> All I can say is a lot of thanks to mario for this, this is a killer...
>> I think he has found the right mix of exposing the api and
>> trying to automate. Seam while being excellent and Gavin was entirely
>> correct with his approach of keeping the entitymanager open for a
>> conversation, automates and hides way too much for my taste.
>> One example is that it takes away the control how you connect
>> the master and the detail, and in the end breaks the Tomahawk table
>> that way.
>>
>>
>> Gerald Müllan schrieb:
>> > Mario,
>> >
>> > i am feeling very confident that this will be a great addition to
>> > MyFaces in the near future.
>> >
>> > Through many lessons learned, I can admit that using Spring + JSF
>> > together makes up a powerful combination. Tying the new
>> > Spring/MyFaces-Conversation scope to JSF brings us beneath a
>> > "seam-approach", but with less burden. I am quite curious about using
>> > the sample-app!
>> >
>> > As i believe, the sandbox stuff will be removed, after fusion will be
>> > quite stable.
>> >
>> > I also agree that it should have been discussed on the list, but ok it
>> > is done now. Next time
>> > devs should be informed before such a big commit takes place.
>> >
>> > cheers,
>> >
>> > Gerald
>> >
>>
>>
>>
>>
>> --
>> Arash Rajaeeyan
>
>
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Ok here is a first small bite:
What we have here is a simple detail conversation
the master gets injected so that we can have work done
after update
but lives in its own conversation
what happens the user id is injected so is the master
(design decision i chose, you probably could get
the affected dataset also from the master if you set it there,
but I wanted to have clear boundaries so i pushed in the uid of the user
and have it reloaded insted of merging it in.
The entire time the form is open the conversation keeps the user and the
db connection
now if you want to save it...
public String dosubmit() {
flushCurrentUser();
usermasterview.findUsers();//we refill our view dont access the
db objects there, different em
return StdOutcome.SUCCESS;
}
flushcurrentUser basically just goes into an entity manager flush
(the Entity Manager is injected by @PersistenceContext somewhere in the
bo layer automatically, fusion + spring takes care of that,
hence theoretically you could go for a seam like approach of injecting
the PersistenceContext directly into the conversation.
anyway, em.flush that is it or em.persist in case of a create
all the time you work on the same user object coming from the entity
manager and having it referenced there.
usermasterview.findUsers();//
refills the master view with new data so that at a back
or go_master situation you have the updated data there
once you are done
Conversation.getCurrentInstance().invalidate();
return "go_master";
For simple navigational use cases you can invalidate all open
conversations at once, so that you do not have pending conversations.
If you still run into those, the conversations time out after while.
public class UserDetailView {
UserBO userbo;
User user = new User();
UserMasterView usermasterview;
int userid;
boolean postinitialized = false;
String viewmode = "create";
public int getUserid() {
return userid;
}
public void setUserid(int userid) {
this.userid = userid;
if(!postinitialized) {
postInitialize(userid);
}
}
public void setPreinitUserid(int userid) {
postInitialize(userid);
}
public int getPreinitUserid() {
return -1;
}
public void postInitialize(int userid) {
postinitialized = true;
user = userbo.loadUserById(userid);
viewmode = "edit";
}
public String dosubmit() {
flushCurrentUser();
usermasterview.findUsers();//we refill our view dont access the
db objects there, different em
return StdOutcome.SUCCESS;
}
public String dogomaster() {
Conversation.getCurrentInstance().invalidate();
return "go_master";
}
public void flushCurrentUser() {
userbo.createUpdateUser((User)user);
}
public UserBO getUserbo() {
return userbo;
}
public void setUserbo(UserBO userbo) {
this.userbo = userbo;
}
public User getUser() {
return user;
}
public void setUser(User user) {
this.user = user;
}
public String getViewmode() {
return viewmode;
}
public void setViewmode(String viewmode) {
this.viewmode = viewmode;
}
public UserMasterView getUsermasterview() {
return usermasterview;
}
public void setUsermasterview(UserMasterView usermasterview) {
this.usermasterview = usermasterview;
}
}
Arash Rajaeeyan schrieb:
> how can I see the result of this work?
>
> On 2/27/07, *Werner Punz* <werner.punz@gmail.com
> <ma...@gmail.com>> wrote:
>
> Sorry to jump in here again,
> I have been playing guinea pig the last
> week for marios work.
> All I can say is this thing now is highly usable
> by now.
> You can put a view controller under conversation scope
> (not a shale one yet, you will lose the callbacks)
> and simply work on the stuff now like you would do in a rich client
> environment with an EntityManage, Hibernate Session open for the entire
> conversation.
>
> once you hit a point when you want to terminate, you can have the view
> controller/conversation invalidate itself or restart itself.
>
> Also binding component bindings onto such a conversation is taken care
> of, you can push them into a separate bean which you weave in by
> a scope of request and aop:scoped-proxy, then you basically get a fresh
> view onto your backend component bindings at every request.
>
> To sum it up, I just almost finished a first full master detail crud
> ( I have done several details forms before)
> The master form has about 30 lines of core code, excluding the setters
> and getters already dealting with dao calling, handling the query part
> etc... and adding a detail was a matter of one hour of figuring out
> which patterns work best and a few minutes of implementation
> handling new update and delete.
> The objects you work with always are the same the orm layer accesses,
> so a simple update ends up normally with
>
> entitymanager.flush ();
>
> And btw. bindings for hibernate and jpa already are in place...
>
> All I can say is a lot of thanks to mario for this, this is a killer...
> I think he has found the right mix of exposing the api and
> trying to automate. Seam while being excellent and Gavin was entirely
> correct with his approach of keeping the entitymanager open for a
> conversation, automates and hides way too much for my taste.
> One example is that it takes away the control how you connect
> the master and the detail, and in the end breaks the Tomahawk table
> that way.
>
>
> Gerald Müllan schrieb:
> > Mario,
> >
> > i am feeling very confident that this will be a great addition to
> > MyFaces in the near future.
> >
> > Through many lessons learned, I can admit that using Spring + JSF
> > together makes up a powerful combination. Tying the new
> > Spring/MyFaces-Conversation scope to JSF brings us beneath a
> > "seam-approach", but with less burden. I am quite curious about using
> > the sample-app!
> >
> > As i believe, the sandbox stuff will be removed, after fusion will be
> > quite stable.
> >
> > I also agree that it should have been discussed on the list, but ok it
> > is done now. Next time
> > devs should be informed before such a big commit takes place.
> >
> > cheers,
> >
> > Gerald
> >
>
>
>
>
> --
> Arash Rajaeeyan
Re: MyFaces Fusion
Posted by Arash Rajaeeyan <ar...@gmail.com>.
thank a lot mario, I have started to give it a try.
hope I can learn it fast and write about it soon.
On 2/27/07, Mario Ivankovits <ma...@gmail.com> wrote:
>
> Hi Arash!
>
> > how can I see the result of this work?
> I don't know if Werner is able to put his work into public, though, I am
> working on an example showing the same patterns.
>
> It took some time to setup the examples framework, though, yesterday I
> managed to bring it up and can start now to implement a nice example.
> You can keep track by checkout fusion from:
>
> https://svn.apache.org/repos/asf/myfaces/fusion/trunk
>
> You'll have to have a myfaces checkout too which requires a "mvn
> install" first.
> Then change into fusion and execute "mvn install" there too.
> Change into fusion/examples and start "mvn jetty:run" (Thanks to
> Matthias Wessendorf who provided the configuration for it), though,
> don't expect too much for now :-)
>
> I'll try to finish and polish this simple example and will create the
> documentation based on it then.
>
> Also thanks to Werner Punz who put enormous time into debugging all the
> stuff.
>
> I plan to have an official announcement next week. Today evening I'll
> kick off a naming discussion on the ml.
>
> Ciao,
> Mario
>
>
--
Arash Rajaeeyan
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Aaresh feel free to contact me via gtalk if you need help.
I am pretty far along in my app already, I have covered most usecases
you run into a typical app.
Werner
Arash Rajaeeyan schrieb:
> Thanks mario, (and Werner)
> thats this is more than enough!
>
> On 2/28/07, *Mario Ivankovits* <mario@ops.co.at
> <ma...@ops.co.at>> wrote:
>
> Hi Arash!
> > just give me some hints if possible
> > I have two more days to finish this part of the book I am writing and
> > I am interested to replace the seam framework I used in my example
> > with fusion (or what ever it will be called in future)
> > I have used only seam for integration with JPA, and it looks like I
> > can replace it.
> O-K I'll try:
>
> For the installation you have to configure the conversation scope in
> spring, for this you could have a look at
> fusion/examples/src/main/webapp/WEB-INF/applicationContext.xml
>
> As might see, the conversation scope is configured using an advice, the
> persistentContextConversationInterceptor.
> This interceptor holds the entity manager for a conversation and is
> responsible to configure the thread.
>
> Every bean configured in "conversation" scope (using
> scope="conversation") will get a new entity manager.
> If you used spring before, your knowledge about daos wont change.
>
> Each conversation bean has to have the <aop:scoped-proxy/> marker. This
> creates a proxy so that - even if you end a conversation - you can work
> with this bean - but on an new instance then.
>
> You can use the conversation scoped bean directly as your backing bean
> for the view, this is the common case if you have to deal with a single
> page only.
> If you have a wizzard like pageflow you'll typically create a
> conversation scope bean which you inject into your request scope backing
> bean then.
>
> The method in your conversation bean which will issue an update has to
> be annotated with @Transactional - you can change your entites in not
> annotated methods too, but then they are not flushed - the flush is
> delayed unit a @Transactional method has been invoked.
> That way the entity manager will issue a commit() at the end of the
> method.
> Tha can also be the point where you end a conversation, from within the
> conversation bean you can access the current conversation using
> Conversation.getCurrentInstance()
>
> The conversation can also be invalidated(), which means the next access
> to the bean instance will see an new empty one. There are strategies to
> "restart" a conversation too.
>
> The point is that you use the (well known) strategies of spring to get
> access to the entity manager, and in JPA they are the standardized.
> Fusion "just" configures spring so that it will see the associated
> entityManager for the to-be-invoked conversation.
>
> I am not sure if I manged to make things clearer now - all in all its
> the spring configuration which you have to make correct, afterwards
> there are just a handful of patterns which you should follow to make the
> most use out of fusion.
>
>
> Ciao,
> Mario
>
>
>
>
> --
> Arash Rajaeeyan
Re: MyFaces Fusion
Posted by Arash Rajaeeyan <ar...@gmail.com>.
Thanks mario, (and Werner)
thats this is more than enough!
On 2/28/07, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi Arash!
> > just give me some hints if possible
> > I have two more days to finish this part of the book I am writing and
> > I am interested to replace the seam framework I used in my example
> > with fusion (or what ever it will be called in future)
> > I have used only seam for integration with JPA, and it looks like I
> > can replace it.
> O-K I'll try:
>
> For the installation you have to configure the conversation scope in
> spring, for this you could have a look at
> fusion/examples/src/main/webapp/WEB-INF/applicationContext.xml
>
> As might see, the conversation scope is configured using an advice, the
> persistentContextConversationInterceptor.
> This interceptor holds the entity manager for a conversation and is
> responsible to configure the thread.
>
> Every bean configured in "conversation" scope (using
> scope="conversation") will get a new entity manager.
> If you used spring before, your knowledge about daos wont change.
>
> Each conversation bean has to have the <aop:scoped-proxy/> marker. This
> creates a proxy so that - even if you end a conversation - you can work
> with this bean - but on an new instance then.
>
> You can use the conversation scoped bean directly as your backing bean
> for the view, this is the common case if you have to deal with a single
> page only.
> If you have a wizzard like pageflow you'll typically create a
> conversation scope bean which you inject into your request scope backing
> bean then.
>
> The method in your conversation bean which will issue an update has to
> be annotated with @Transactional - you can change your entites in not
> annotated methods too, but then they are not flushed - the flush is
> delayed unit a @Transactional method has been invoked.
> That way the entity manager will issue a commit() at the end of the
> method.
> Tha can also be the point where you end a conversation, from within the
> conversation bean you can access the current conversation using
> Conversation.getCurrentInstance()
>
> The conversation can also be invalidated(), which means the next access
> to the bean instance will see an new empty one. There are strategies to
> "restart" a conversation too.
>
> The point is that you use the (well known) strategies of spring to get
> access to the entity manager, and in JPA they are the standardized.
> Fusion "just" configures spring so that it will see the associated
> entityManager for the to-be-invoked conversation.
>
> I am not sure if I manged to make things clearer now - all in all its
> the spring configuration which you have to make correct, afterwards
> there are just a handful of patterns which you should follow to make the
> most use out of fusion.
>
>
> Ciao,
> Mario
>
>
--
Arash Rajaeeyan
Re: MyFaces Fusion
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Arash!
> just give me some hints if possible
> I have two more days to finish this part of the book I am writing and
> I am interested to replace the seam framework I used in my example
> with fusion (or what ever it will be called in future)
> I have used only seam for integration with JPA, and it looks like I
> can replace it.
O-K I'll try:
For the installation you have to configure the conversation scope in
spring, for this you could have a look at
fusion/examples/src/main/webapp/WEB-INF/applicationContext.xml
As might see, the conversation scope is configured using an advice, the
persistentContextConversationInterceptor.
This interceptor holds the entity manager for a conversation and is
responsible to configure the thread.
Every bean configured in "conversation" scope (using
scope="conversation") will get a new entity manager.
If you used spring before, your knowledge about daos wont change.
Each conversation bean has to have the <aop:scoped-proxy/> marker. This
creates a proxy so that - even if you end a conversation - you can work
with this bean - but on an new instance then.
You can use the conversation scoped bean directly as your backing bean
for the view, this is the common case if you have to deal with a single
page only.
If you have a wizzard like pageflow you'll typically create a
conversation scope bean which you inject into your request scope backing
bean then.
The method in your conversation bean which will issue an update has to
be annotated with @Transactional - you can change your entites in not
annotated methods too, but then they are not flushed - the flush is
delayed unit a @Transactional method has been invoked.
That way the entity manager will issue a commit() at the end of the method.
Tha can also be the point where you end a conversation, from within the
conversation bean you can access the current conversation using
Conversation.getCurrentInstance()
The conversation can also be invalidated(), which means the next access
to the bean instance will see an new empty one. There are strategies to
"restart" a conversation too.
The point is that you use the (well known) strategies of spring to get
access to the entity manager, and in JPA they are the standardized.
Fusion "just" configures spring so that it will see the associated
entityManager for the to-be-invoked conversation.
I am not sure if I manged to make things clearer now - all in all its
the spring configuration which you have to make correct, afterwards
there are just a handful of patterns which you should follow to make the
most use out of fusion.
Ciao,
Mario
Re: MyFaces Fusion
Posted by Craig McClanahan <cr...@apache.org>.
On 2/27/07, Arash Rajaeeyan <ar...@gmail.com> wrote:
> oh yes, also conversation scope of Trinidad
> does you (or any one one else) have access to JSR 299 info?
> do you which approach are they going to standardize for
> conversation/dialog/(or what ever they name it)?
EG discussions on JSR-299 have started (although it's been quiet for a
while), but there's no definitive conclusion on this or pretty much
any other technical issue yet.
Craig
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Arash Rajaeeyan schrieb:
> I am more interested in ORM control part.
> I prefer to stay neutral between seam and shale in the book :)
>
Ok what info do you need exactly?
Re: MyFaces Fusion
Posted by Arash Rajaeeyan <ar...@gmail.com>.
I think the best way is to extend the bean scopes and add some other
scope(s) for conversation or dialogs.
I think in first proposal they said they want to take best practices of
Seam, Shale, ADF, and other JSF based frameworks and find best practices for
web development, and put them in web beans (JSR 299)
it can be addressed in low level Servlet API but it can also be addressed in
higher levels like JSF frameworks.
On 2/28/07, Werner Punz <we...@gmail.com> wrote:
>
> Arash Rajaeeyan schrieb:
> > oh yes, also conversation scope of Trinidad
> > does you (or any one one else) have access to JSR 299 info?
> > do you which approach are they going to standardize for
> > conversation/dialog/(or what ever they name it)?
> >
> Btw. speaking of JSR 299, and conversations, isnt jsr299 just
> a glue specification of marrying ejb3 and jsf so that you can use ejb3
> beans as managed beans?
>
> Regarding conversations and dialogs:
>
> This stuff really belongs into the servlet space just like session
> and request,
> which technologies then are built on top of such scoping is an entire
> issue.
>
> Lets face it 90% of all problems most people have in webapps stem from
> the fact that you cannot keep objects for a longer time without going
> through the problems a session scope causes for garbage collection
> and due to the fact that if you do not work on a pure jdbc base but on
> an orm base you either have to keep an erm open for your entire session
> with all related problems or you have to open it on request or even
> works on business case and then run into the usual merge problems
> most orm layers have (which is not solvable in a satisfying way anyway)
>
> The current already big number of various dialog systems which also keep
> something conversational open for object storage stem from the fact that
> this is a huge problem or has become a bigger one now that webapps seem
> to have moved towards orm layers where this problem becomes more
> problematic.
>
> Tackeling it on JEE level has been long overdue in my opinion especially
> because most of the usage and core patterns basically are tested by now.
>
> Craig since you are reading this, any idea if the servlet specs will be
> opened to scopes/conversations in the next specifications?
>
>
> Werner
>
>
--
Arash Rajaeeyan
Re: MyFaces Fusion
Posted by Craig McClanahan <cr...@apache.org>.
On 2/28/07, Werner Punz <we...@gmail.com> wrote:
> Arash Rajaeeyan schrieb:
> > oh yes, also conversation scope of Trinidad
> > does you (or any one one else) have access to JSR 299 info?
> > do you which approach are they going to standardize for
> > conversation/dialog/(or what ever they name it)?
> >
> Btw. speaking of JSR 299, and conversations, isnt jsr299 just
> a glue specification of marrying ejb3 and jsf so that you can use ejb3
> beans as managed beans?
>
JSR299 means whatever the expert group decides to propose to the JCP
executive committee for approval. The kinds of things you describe
above are definitely within the initial proposal document[1], but I
would not place any bets that JSR-299 will limit itself to just what
you mentioned.
> Regarding conversations and dialogs:
>
> This stuff really belongs into the servlet space just like session
> and request,
> which technologies then are built on top of such scoping is an entire
> issue.
Agreed in general ... the devil is in the details. Consider the
RESTafarian attitude that scopes of any kind (other than request
scope) are evil. And, consider the fact that, although javax.servlet
was one of the earliest "extension" proposals for the Java language,
there have not been any mainstream-adopted solutions on different APIs
to adapt HTTP requests to Java business logic (unless, I suppose, you
count SOAP mappings via things like JAX-RPC and JAX-WS ... but those
still count IMHO as built on *top* of the servlet APi instead of
replacing it).
Maybe there is some virtue in a simple baseline standard that everyone
can adopt?
>
> Lets face it 90% of all problems most people have in webapps stem from
> the fact that you cannot keep objects for a longer time without going
> through the problems a session scope causes for garbage collection
> and due to the fact that if you do not work on a pure jdbc base but on
> an orm base you either have to keep an erm open for your entire session
> with all related problems or you have to open it on request or even
> works on business case and then run into the usual merge problems
> most orm layers have (which is not solvable in a satisfying way anyway)
>
> The current already big number of various dialog systems which also keep
> something conversational open for object storage stem from the fact that
> this is a huge problem or has become a bigger one now that webapps seem
> to have moved towards orm layers where this problem becomes more
> problematic.
>
> Tackeling it on JEE level has been long overdue in my opinion especially
> because most of the usage and core patterns basically are tested by now.
>
> Craig since you are reading this, any idea if the servlet specs will be
> opened to scopes/conversations in the next specifications?
>
It turns out that I've been an internal proponent of dealing with
these kinds of issues at the servlet spec level, as my colleagues in
the platform group are aware of :-). One of the critical challenges,
unfortunately, is econimics -- funding any spec all the way through
the JCP process is likely to be a six-figure ($) investment, and the
challenge is to optimize our (Sun's) investments.
My personal interest in this problem space is actually at a level
*below* the servlet API ... hopefully, the recently filed RESTful API
JSR can deal with those sorts of things. Things like conversation
scope (and even session scope) should be extensions on top of such a
basic API, not fundamental features of it. Serv;ets have served us
honorably for almost 10 years (only a little less than the lifetime of
Java itself) ... but it's time to move forwards.
>
> Werner
>
>
Craig
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Arash Rajaeeyan schrieb:
> oh yes, also conversation scope of Trinidad
> does you (or any one one else) have access to JSR 299 info?
> do you which approach are they going to standardize for
> conversation/dialog/(or what ever they name it)?
>
Btw. speaking of JSR 299, and conversations, isnt jsr299 just
a glue specification of marrying ejb3 and jsf so that you can use ejb3
beans as managed beans?
Regarding conversations and dialogs:
This stuff really belongs into the servlet space just like session
and request,
which technologies then are built on top of such scoping is an entire
issue.
Lets face it 90% of all problems most people have in webapps stem from
the fact that you cannot keep objects for a longer time without going
through the problems a session scope causes for garbage collection
and due to the fact that if you do not work on a pure jdbc base but on
an orm base you either have to keep an erm open for your entire session
with all related problems or you have to open it on request or even
works on business case and then run into the usual merge problems
most orm layers have (which is not solvable in a satisfying way anyway)
The current already big number of various dialog systems which also keep
something conversational open for object storage stem from the fact that
this is a huge problem or has become a bigger one now that webapps seem
to have moved towards orm layers where this problem becomes more
problematic.
Tackeling it on JEE level has been long overdue in my opinion especially
because most of the usage and core patterns basically are tested by now.
Craig since you are reading this, any idea if the servlet specs will be
opened to scopes/conversations in the next specifications?
Werner
Re: MyFaces Fusion
Posted by Arash Rajaeeyan <ar...@gmail.com>.
oh yes, also conversation scope of Trinidad
does you (or any one one else) have access to JSR 299 info?
do you which approach are they going to standardize for
conversation/dialog/(or what ever they name it)?
On 2/28/07, Craig McClanahan <cr...@apache.org> wrote:
>
> On 2/27/07, Arash Rajaeeyan <ar...@gmail.com> wrote:
> > I am more interested in ORM control part.
> > I prefer to stay neutral between seam and shale in the book :)
> >
>
> Don't forget about the conversation scope implementation in Trinidad, too
> :-).
>
> Craig
>
--
Arash Rajaeeyan
Re: MyFaces Fusion
Posted by Craig McClanahan <cr...@apache.org>.
On 2/27/07, Arash Rajaeeyan <ar...@gmail.com> wrote:
> I am more interested in ORM control part.
> I prefer to stay neutral between seam and shale in the book :)
>
Don't forget about the conversation scope implementation in Trinidad, too :-).
Craig
Re: MyFaces Fusion
Posted by Arash Rajaeeyan <ar...@gmail.com>.
I am more interested in ORM control part.
I prefer to stay neutral between seam and shale in the book :)
On 2/28/07, Werner Punz <we...@gmail.com> wrote:
>
> Arash Rajaeeyan schrieb:
> > just give me some hints if possible
> > I have two more days to finish this part of the book I am writing and I
> > am interested to replace the seam framework I used in my example with
> > fusion (or what ever it will be called in future)
> > I have used only seam for integration with JPA, and it looks like I can
> > replace it.
> >
> >
> If you use seam only for conversational control, yes then you can
> replace it, but seam has a lot of other added value which sometimes is a
> good supporting layer sometimes you do not need it,
> fusion has a dedicated scope, which is not quite the same as seam or
> currently existing dialog systems (but current dialog systems
> can use fusion as provider for their scope control, with the added value
> of getting full orm control as well)
>
>
>
--
Arash Rajaeeyan
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Arash Rajaeeyan schrieb:
> just give me some hints if possible
> I have two more days to finish this part of the book I am writing and I
> am interested to replace the seam framework I used in my example with
> fusion (or what ever it will be called in future)
> I have used only seam for integration with JPA, and it looks like I can
> replace it.
>
>
If you use seam only for conversational control, yes then you can
replace it, but seam has a lot of other added value which sometimes is a
good supporting layer sometimes you do not need it,
fusion has a dedicated scope, which is not quite the same as seam or
currently existing dialog systems (but current dialog systems
can use fusion as provider for their scope control, with the added value
of getting full orm control as well)
Re: MyFaces Fusion
Posted by Arash Rajaeeyan <ar...@gmail.com>.
just give me some hints if possible
I have two more days to finish this part of the book I am writing and I am
interested to replace the seam framework I used in my example with fusion
(or what ever it will be called in future)
I have used only seam for integration with JPA, and it looks like I can
replace it.
On 2/28/07, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi Arash!
> > nice demo,
> hehe, dont lie ;-)
>
> > dose any documentation exist any where to start? (other than this
> example)
> Unfortunately no, not yet. But I'll start one soon.
>
> Ciao,
> Mario
>
>
--
Arash Rajaeeyan
Re: MyFaces Fusion
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Arash!
> nice demo,
hehe, dont lie ;-)
> dose any documentation exist any where to start? (other than this example)
Unfortunately no, not yet. But I'll start one soon.
Ciao,
Mario
Re: MyFaces Fusion
Posted by Arash Rajaeeyan <ar...@gmail.com>.
nice demo, dose any documentation exist any where to start? (other than this
example)
On 2/27/07, Mario Ivankovits <ma...@gmail.com> wrote:
>
> Hi Arash!
>
> > how can I see the result of this work?
> I don't know if Werner is able to put his work into public, though, I am
> working on an example showing the same patterns.
>
> It took some time to setup the examples framework, though, yesterday I
> managed to bring it up and can start now to implement a nice example.
> You can keep track by checkout fusion from:
>
> https://svn.apache.org/repos/asf/myfaces/fusion/trunk
>
> You'll have to have a myfaces checkout too which requires a "mvn
> install" first.
> Then change into fusion and execute "mvn install" there too.
> Change into fusion/examples and start "mvn jetty:run" (Thanks to
> Matthias Wessendorf who provided the configuration for it), though,
> don't expect too much for now :-)
>
> I'll try to finish and polish this simple example and will create the
> documentation based on it then.
>
> Also thanks to Werner Punz who put enormous time into debugging all the
> stuff.
>
> I plan to have an official announcement next week. Today evening I'll
> kick off a naming discussion on the ml.
>
> Ciao,
> Mario
>
>
--
Arash Rajaeeyan
Re: MyFaces Fusion
Posted by Mario Ivankovits <ma...@gmail.com>.
Hi Arash!
> how can I see the result of this work?
I don't know if Werner is able to put his work into public, though, I am
working on an example showing the same patterns.
It took some time to setup the examples framework, though, yesterday I
managed to bring it up and can start now to implement a nice example.
You can keep track by checkout fusion from:
https://svn.apache.org/repos/asf/myfaces/fusion/trunk
You'll have to have a myfaces checkout too which requires a "mvn
install" first.
Then change into fusion and execute "mvn install" there too.
Change into fusion/examples and start "mvn jetty:run" (Thanks to
Matthias Wessendorf who provided the configuration for it), though,
don't expect too much for now :-)
I'll try to finish and polish this simple example and will create the
documentation based on it then.
Also thanks to Werner Punz who put enormous time into debugging all the
stuff.
I plan to have an official announcement next week. Today evening I'll
kick off a naming discussion on the ml.
Ciao,
Mario
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Craig McClanahan schrieb:
>
> Except that you might have been able to save some work by leveraging
> one of the existing dialog manager solutions (including possibly
> negotiating feature additions if you needed something that wasn't
> already supported). Instead, you guys just created another one.
>
It is not quite the same...
first of all the conversational stuff is more along the lines
of what early seam builds were doing.
Having a conversation which also is able to control the orm layer,
secondly, it is not a real breakage of existing dialog systems and
adding yet another one. This stuff originated in the tag space and now
has been moved into spring 2.0 as a showcase of what spring scopes can do.
It currently has no configuration whatsoever regarding dialog scopes.
It currently is along the lines of an extende flash scope with
an added orm controller.
In the long run a layer like Shale Dialog can provide is heavily needed
to add another layer of possible control (Expecially for clearer
Begin and Endconversation control)
So I do not see neither fusion as a direct competitor to shale dialog
nor to spring webflow, it is more along the lines of a scope provider
which in the end can benefit of a more extended configuration based
dialog system.
Re: MyFaces Fusion
Posted by Craig McClanahan <cr...@apache.org>.
On 2/27/07, Werner Punz <we...@gmail.com> wrote:
> Mario Ivankovits schrieb:
> >> I thought you were simply playing around with the fusion framework,
> >> not trying to use it for real work :-)
> > He is really enthusiastic .... and an adventurer ;-)
> >
> It has less to do with adventure more along the lines of having been on
> a dreadful schedule for the app and having a conversation framework
> as being the only solution to get things done without killing my nerves
> and banging my head constantly against the orm layer (I have had enough
> of that in my life=
>
> In the end we get a good testcase for the patterns (and lots of stuff
> has been readjusted) so in the end it is a win win situation for everyone.
>
>
Except that you might have been able to save some work by leveraging
one of the existing dialog manager solutions (including possibly
negotiating feature additions if you needed something that wasn't
already supported). Instead, you guys just created another one.
Craig
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Mario Ivankovits schrieb:
>> I thought you were simply playing around with the fusion framework,
>> not trying to use it for real work :-)
> He is really enthusiastic .... and an adventurer ;-)
>
It has less to do with adventure more along the lines of having been on
a dreadful schedule for the app and having a conversation framework
as being the only solution to get things done without killing my nerves
and banging my head constantly against the orm layer (I have had enough
of that in my life=
In the end we get a good testcase for the patterns (and lots of stuff
has been readjusted) so in the end it is a win win situation for everyone.
Re: MyFaces Fusion
Posted by Mario Ivankovits <ma...@gmail.com>.
> I thought you were simply playing around with the fusion framework,
> not trying to use it for real work :-)
He is really enthusiastic .... and an adventurer ;-)
Kudos to Werner!
Ciao,
Mario
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Mike Kienenberger schrieb:
> Ah, Ok.
>
> I thought you were simply playing around with the fusion framework,
> not trying to use it for real work :-)
>
Actually no it is a production project, it was kindof risky, the
schedule for the project
is very tight, I opted for fusion because it saves me a lot of time.
But it was a high risk, if I would run into something severe I probably
would have had to start from scratch, but so far things have worked out
excellently, Mario gave me a lot of support on this, and we both could
share ideas on how things have to work, but Mario did the implementation
I just did the jpa connector.
I personally think, that now the point has been reached that nothing
severe should occur anymore and things will go smoothly.
All use cases and patterns which can occur are in place and work so far.
(How to handle central navigations, how to deal with a master view, with
a detail view, what do you need if you want to reconnect everything etc...)
This stuff really saves a lot of time, because all the merge problems
orm mappers usually have in a request centric context are gone (aka lost
entity objects having to be merged again, with failurs 90% of the time),
you do not have to map form values and objects into orm objects etc..
It is just load object(s) save objects, done, no matter which nesting
depth, with almost no compromises introduced by a web centric context.
It is really amazing how smooth things can be once you have a stateful
object context to work with.
Do something in the detail mask, reload the master mask with one single
call. And once you go back or hit the back button all changes are there.
At a first look combining master and detail within a single page also
should be a non issue, simply amazing, it takes away most of the pain ;-).
Re: MyFaces Fusion
Posted by Mike Kienenberger <mk...@gmail.com>.
Ah, Ok.
I thought you were simply playing around with the fusion framework,
not trying to use it for real work :-)
On 2/27/07, Werner Punz <we...@gmail.com> wrote:
> Mike Kienenberger schrieb:
> > Werner,
> >
> > Why not add this an example app to the fusion project?
> >
> >
> Problem is i do not know the code rights of the current code I do.
> I have to clear that up first.
> But what I am currently doing is following.
>
> I code my app which is a bigger than the usual example
> and use it as a usecase and testing ground für the fusion conversation
> stuff.
>
> I later give back parts of the code
> and the patterns which worked best to mario so that he can look things
> up and work the results into his examples.
>
> That way the example will have well working patterns.
>
> I am thinking of having my app as bigger example (it is small enough)
> but I have to clear the rights first.
>
>
> In the end either way, the examples should give well working blueprints
> and good patterns on how to apply everything.
>
>
> Werner
>
>
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Mike Kienenberger schrieb:
> Werner,
>
> Why not add this an example app to the fusion project?
>
>
Problem is i do not know the code rights of the current code I do.
I have to clear that up first.
But what I am currently doing is following.
I code my app which is a bigger than the usual example
and use it as a usecase and testing ground für the fusion conversation
stuff.
I later give back parts of the code
and the patterns which worked best to mario so that he can look things
up and work the results into his examples.
That way the example will have well working patterns.
I am thinking of having my app as bigger example (it is small enough)
but I have to clear the rights first.
In the end either way, the examples should give well working blueprints
and good patterns on how to apply everything.
Werner
Re: MyFaces Fusion
Posted by Mike Kienenberger <mk...@gmail.com>.
Werner,
Why not add this an example app to the fusion project?
On 2/27/07, Werner Punz <we...@gmail.com> wrote:
> Arash Rajaeeyan schrieb:
> > how can I see the result of this work?
> >
> The demos are not quite there yet (mario is working on them)
> but you can contact me this evening so that I can drop
> some example code.
>
> ;-)
>
>
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Arash Rajaeeyan schrieb:
> how can I see the result of this work?
>
The demos are not quite there yet (mario is working on them)
but you can contact me this evening so that I can drop
some example code.
;-)
Re: MyFaces Fusion
Posted by Arash Rajaeeyan <ar...@gmail.com>.
how can I see the result of this work?
On 2/27/07, Werner Punz <we...@gmail.com> wrote:
>
> Sorry to jump in here again,
> I have been playing guinea pig the last
> week for marios work.
> All I can say is this thing now is highly usable
> by now.
> You can put a view controller under conversation scope
> (not a shale one yet, you will lose the callbacks)
> and simply work on the stuff now like you would do in a rich client
> environment with an EntityManage, Hibernate Session open for the entire
> conversation.
>
> once you hit a point when you want to terminate, you can have the view
> controller/conversation invalidate itself or restart itself.
>
> Also binding component bindings onto such a conversation is taken care
> of, you can push them into a separate bean which you weave in by
> a scope of request and aop:scoped-proxy, then you basically get a fresh
> view onto your backend component bindings at every request.
>
> To sum it up, I just almost finished a first full master detail crud
> ( I have done several details forms before)
> The master form has about 30 lines of core code, excluding the setters
> and getters already dealting with dao calling, handling the query part
> etc... and adding a detail was a matter of one hour of figuring out
> which patterns work best and a few minutes of implementation
> handling new update and delete.
> The objects you work with always are the same the orm layer accesses,
> so a simple update ends up normally with
>
> entitymanager.flush();
>
> And btw. bindings for hibernate and jpa already are in place...
>
> All I can say is a lot of thanks to mario for this, this is a killer...
> I think he has found the right mix of exposing the api and
> trying to automate. Seam while being excellent and Gavin was entirely
> correct with his approach of keeping the entitymanager open for a
> conversation, automates and hides way too much for my taste.
> One example is that it takes away the control how you connect
> the master and the detail, and in the end breaks the Tomahawk table
> that way.
>
>
> Gerald Müllan schrieb:
> > Mario,
> >
> > i am feeling very confident that this will be a great addition to
> > MyFaces in the near future.
> >
> > Through many lessons learned, I can admit that using Spring + JSF
> > together makes up a powerful combination. Tying the new
> > Spring/MyFaces-Conversation scope to JSF brings us beneath a
> > "seam-approach", but with less burden. I am quite curious about using
> > the sample-app!
> >
> > As i believe, the sandbox stuff will be removed, after fusion will be
> > quite stable.
> >
> > I also agree that it should have been discussed on the list, but ok it
> > is done now. Next time
> > devs should be informed before such a big commit takes place.
> >
> > cheers,
> >
> > Gerald
> >
>
>
--
Arash Rajaeeyan
Re: MyFaces Fusion
Posted by Werner Punz <we...@gmail.com>.
Sorry to jump in here again,
I have been playing guinea pig the last
week for marios work.
All I can say is this thing now is highly usable
by now.
You can put a view controller under conversation scope
(not a shale one yet, you will lose the callbacks)
and simply work on the stuff now like you would do in a rich client
environment with an EntityManage, Hibernate Session open for the entire
conversation.
once you hit a point when you want to terminate, you can have the view
controller/conversation invalidate itself or restart itself.
Also binding component bindings onto such a conversation is taken care
of, you can push them into a separate bean which you weave in by
a scope of request and aop:scoped-proxy, then you basically get a fresh
view onto your backend component bindings at every request.
To sum it up, I just almost finished a first full master detail crud
( I have done several details forms before)
The master form has about 30 lines of core code, excluding the setters
and getters already dealting with dao calling, handling the query part
etc... and adding a detail was a matter of one hour of figuring out
which patterns work best and a few minutes of implementation
handling new update and delete.
The objects you work with always are the same the orm layer accesses,
so a simple update ends up normally with
entitymanager.flush();
And btw. bindings for hibernate and jpa already are in place...
All I can say is a lot of thanks to mario for this, this is a killer...
I think he has found the right mix of exposing the api and
trying to automate. Seam while being excellent and Gavin was entirely
correct with his approach of keeping the entitymanager open for a
conversation, automates and hides way too much for my taste.
One example is that it takes away the control how you connect
the master and the detail, and in the end breaks the Tomahawk table
that way.
Gerald Müllan schrieb:
> Mario,
>
> i am feeling very confident that this will be a great addition to
> MyFaces in the near future.
>
> Through many lessons learned, I can admit that using Spring + JSF
> together makes up a powerful combination. Tying the new
> Spring/MyFaces-Conversation scope to JSF brings us beneath a
> "seam-approach", but with less burden. I am quite curious about using
> the sample-app!
>
> As i believe, the sandbox stuff will be removed, after fusion will be
> quite stable.
>
> I also agree that it should have been discussed on the list, but ok it
> is done now. Next time
> devs should be informed before such a big commit takes place.
>
> cheers,
>
> Gerald
>
Re: MyFaces Fusion
Posted by Gerald Müllan <bi...@gmail.com>.
Mario,
i am feeling very confident that this will be a great addition to
MyFaces in the near future.
Through many lessons learned, I can admit that using Spring + JSF
together makes up a powerful combination. Tying the new
Spring/MyFaces-Conversation scope to JSF brings us beneath a
"seam-approach", but with less burden. I am quite curious about using
the sample-app!
As i believe, the sandbox stuff will be removed, after fusion will be
quite stable.
I also agree that it should have been discussed on the list, but ok it
is done now. Next time
devs should be informed before such a big commit takes place.
cheers,
Gerald
On 2/22/07, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>
> MyFaces Fusion is just a collection of already existing myfaces sandbox
> components.
>
> The main goal of this project is to ease the development of JSF
> applications especially if they have to deal with an ORM backend.
>
> I tried to do so a while back by developing a ConversationTag, which
> worked not that bad, but I was told that such a logic should not be put
> into the view.
> And well, the feeling was that it would be nice if it could be easier to
> deal with conversation.
>
> Spring allowed us to create a custom scope AND to reuse the well known
> way how it deal with persistence.
>
> So I've rewritten the ConversationTag to use Spring and first tests were
> really nice. No need to learn any new programming style, just code as
> before.
>
> Some of us reviewed it (offlist) and we came to the conclusion that it
> has enough power to live as separate project.
> Thats why I created the initial structure - not really new code, just
> taken from the sandbox.
> I know, I didnt use the svn cp command, but, since ALL of this code has
> been developed by me and there is not much value in the current history,
> I did it the easier way. Sorry for this.
>
>
> The current structure is divided into core and core15.
>
>
> The core part contains the ConversationTag and the RequestParameterProvider.
> In contrast to the tomahawk-sandbox ConversationTag the conversation tag
> now works using Spring and a custom scope.
> The RequestParameterProvider is used to allow multiple open windows
> within the same session.
> So e.g. I you have a order processing system you can open it twice and
> work in two independed conversations (even if their names are the same)
>
> The core15 part contains the DynaForm from tomahawk-sandbox15
> It will create parts of the view automatically based on EJB3 annotated
> beans.
> Its migth become a great time-saver for simple tables.
>
>
> The current check-in do not bulid usable jars, some maven/tld/xml stuff
> has to be put in line, I hope to manage to do so in the next few hours.
> In the next few days I'll commit a sample application (given that you do
> not cancel my efforts), afterwards the documentation has to be done.
>
> The status of this project is sandbox like.
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces