You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by "ir. ing. Jan Dockx" <ja...@mac.com> on 2005/08/07 01:25:17 UTC
great article
I just found a GREAT article:
<http://bugs.sakaiproject.org/confluence/pages/viewpage.action?
pageId=4981&showComments=true>
Thanks, UCB!
Met vriendelijke groeten,
Jan Dockx
PeopleWare NV - Head Office
Cdt.Weynsstraat 85
B-2660 Hoboken
Tel: +32 3 448.33.38
Fax: +32 3 448.32.66
PeopleWare NV - Branch Office Geel
Kleinhoefstraat 5
B-2440 Geel
Tel: +32 14 57.00.90
Fax: +32 14 58.13.25
http://www.peopleware.be/
http://www.mobileware.be/
Re: great article
Posted by Werner Punz <we...@gmx.at>.
Mike Kienenberger wrote:
> On 8/7/05, Werner Punz <we...@gmx.at> wrote:
>
>>In my opinion x:saveState is superior to every dialog approach on the
>>web, because it keeps things small and simple. You do not need
>>another set of page flow syntax files, you just add an x:saveState and
>>use the existing page flow syntax of JSF to do your stuff.
>>The only culprit I have with x:saveState is, that you definitely have
>>your components serializable and thus you have to do extra work for
>>complex objects.
>
>
> I agree. I considered implementing a "page"-scoped Managed Bean
> extension, but when I finished defining what I wanted it to do, it was
> performing the same operations as x:saveState, yet wasn't as flexible.
>
The funny thing is I implemented a serializable less approach,by
bending the core x:saveState code into the session and getting
it from the session, but after implementing it, I was not sure
anymore if the approach was worthwile.
I discussed the whole issue with Martin and he basically told me
that backend beans probably have to be serializable anyway per defintion
(still unclear, because neither me nor Martin currently seem to have the
time to follow the issue anymore, due to projects which seem to bind
both our time).
On a second thought after the discussion, I think having serializable
beans is basically
a non issue, if you preplan the whole thing from the beginning.
If you have to introduce that stuff halfway, you are probably better
off with a sessioned saveState approach.
> However, it was frustrating and time-consuming to learn how to
> serialize my page's backing bean (2 hours), but it'll be easier and
> faster in the future now that I understand the issues better.
>
Yepp
> One issue I still haven't adequately solved is how to recreate the
> linkages between my backing bean and the other beans.
>
> Currently, I'm doing things like this.
>
> ValueBinding binding =
> facesContext.getApplication().createValueBinding("#{authenticationBean}");
> authenticationBean = (AuthenticationBean)binding.getValue(facesContext);
> binding = facesContext.getApplication().createValueBinding("#{adminDbDataStore}");
> adminDbDataStore = (AdminDbDataStore)binding.getValue(facesContext);
>
well that is standard value binding code, I see no binding between the
beans ;-)
I personally thing that it depends on the binding and whether the
objects are fully serializable as whole if you can savestate an entire
object tree (that is my guess on what you want)
if you have it that way, you probably can omit the entre second value
binding fetch, however, I am not sure how the whole system behaves
if both beans are declared under the IOC control of JSF.
(good question, probably there are issues, because the child objects
of the tree probably are not bound back correctly)
The safest bet probably is, make anything serializable and keep the
root object under JSF IOC definition but not the childs. You still can
access the childs by #{rootbean.child.attr}
> Maybe it's an indication that I need refactor my page-scope backing
> bean into multiple beans so that dependencies on other beans no longer
> exist.
>
That is the easiest
Re: great article
Posted by Mike Kienenberger <mk...@gmail.com>.
On 8/7/05, Werner Punz <we...@gmx.at> wrote:
> In my opinion x:saveState is superior to every dialog approach on the
> web, because it keeps things small and simple. You do not need
> another set of page flow syntax files, you just add an x:saveState and
> use the existing page flow syntax of JSF to do your stuff.
> The only culprit I have with x:saveState is, that you definitely have
> your components serializable and thus you have to do extra work for
> complex objects.
I agree. I considered implementing a "page"-scoped Managed Bean
extension, but when I finished defining what I wanted it to do, it was
performing the same operations as x:saveState, yet wasn't as flexible.
However, it was frustrating and time-consuming to learn how to
serialize my page's backing bean (2 hours), but it'll be easier and
faster in the future now that I understand the issues better.
One issue I still haven't adequately solved is how to recreate the
linkages between my backing bean and the other beans.
Currently, I'm doing things like this.
ValueBinding binding =
facesContext.getApplication().createValueBinding("#{authenticationBean}");
authenticationBean = (AuthenticationBean)binding.getValue(facesContext);
binding = facesContext.getApplication().createValueBinding("#{adminDbDataStore}");
adminDbDataStore = (AdminDbDataStore)binding.getValue(facesContext);
Maybe it's an indication that I need refactor my page-scope backing
bean into multiple beans so that dependencies on other beans no longer
exist.
-Mike
Re: great article
Posted by Werner Punz <we...@gmx.at>.
I have read that article a while ago,
one of the two main problems he noticed with JSF are sort
of addressed in MyFaces (and also mentioned in the article).
one being the low number of components, that definitely is addressed
in MyFaces, the other one being the lack of scopes between request and
session, a problem inherited from Struts (and that one inherited it from
the servlet/jsp specification)
MyFaces has addressed it by the introduction if x:saveState which can
extend the scopes to multiple pages by recycling saved objects
as long as it runs into x:saveState tags on the same object again and
again. The article has that one in there.
In my opinion x:saveState is superior to every dialog approach on the
web, because it keeps things small and simple. You do not need
another set of page flow syntax files, you just add an x:saveState and
use the existing page flow syntax of JSF to do your stuff.
The only culprit I have with x:saveState is, that you definitely have
your components serializable and thus you have to do extra work for
complex objects.
But I have discussed the problem with Martin, and he said to me that he
was not sure, but he thinks that the official standards say that the
beans must be serializable anyway.
Rails has a similar approach where you can extend the scope of an object
another request and once it is not extended anymore it drops out
(similarily interesting, because it opens another set of possibilities
of one time data handling upon a given state)
ir. ing. Jan Dockx wrote:
> I just found a GREAT article:
>
> <http://bugs.sakaiproject.org/confluence/pages/viewpage.action?pageId=4981&showComments=true>
>
>
> Thanks, UCB!
>
> Met vriendelijke groeten,
>
> Jan Dockx
>
> PeopleWare NV - Head Office
> Cdt.Weynsstraat 85
> B-2660 Hoboken
> Tel: +32 3 448.33.38
> Fax: +32 3 448.32.66
>
> PeopleWare NV - Branch Office Geel
> Kleinhoefstraat 5
> B-2440 Geel
> Tel: +32 14 57.00.90
> Fax: +32 14 58.13.25
> _
> http://www.peopleware.be/
> http://www.mobileware.be/_
Re: great article
Posted by Werner Punz <we...@gmx.at>.
Btw... I have added links in the wiki to this
absolutely great article.
Werner
ir. ing. Jan Dockx wrote:
> I just found a GREAT article:
>
> <http://bugs.sakaiproject.org/confluence/pages/viewpage.action?pageId=4981&showComments=true>
>
>
> Thanks, UCB!
>
> Met vriendelijke groeten,
>
> Jan Dockx
>
> PeopleWare NV - Head Office
> Cdt.Weynsstraat 85
> B-2660 Hoboken
> Tel: +32 3 448.33.38
> Fax: +32 3 448.32.66
>
> PeopleWare NV - Branch Office Geel
> Kleinhoefstraat 5
> B-2440 Geel
> Tel: +32 14 57.00.90
> Fax: +32 14 58.13.25
> _
> http://www.peopleware.be/
> http://www.mobileware.be/_