When to use PAGE scope?

[asookazian]

In the context of application transactions as described by GKing in the Seam ref doc, and using SMPC with Manual flush, when would/could I use the PAGE scope for my Seam components?

If I use PAGE scope, then will atomic conversations still be possible or not?

I guess I'm trying to understand use cases that could be modeled using PAGE scope...

[amitev]

I find the PAGE scope a little bit useless, because if i load the data in an action method and redirect to the page where i would like to use the data, the page scope is already gone and have to use conversation scope.

[damianharvey.damianharvey.gmail.com]

I find it useful for all-in-one style pages where the list and actions are all performed in the same page.

The only thing that this saves me is starting a conversation though, so not really much of a gain. But given that I normally do this in a xxx.pages.xml it means that I don't need that file for this page.

Maybe if you had a large amount of data that you didn't want to store longer than the page and the time it takes a conversation to expire?

Cheers,

Damian.

[brandonsimpson]

It seemed kind of useless to me when I tried it, unless I had just done something wrong. The problem I had with it is it didn't seem to be cleaned up! If I closed the tab/browser or clicked on a link, page objects seemed to hang around forever and onDestroy() was never called. As a result, to me, it seems that long-running conversations are the best thing to use even for a stand-alone interactive page.

[asookazian]

Brandon Simpson wrote on Aug 11, 2009 17:23:


As a result, to me, it seems that long-running conversations are the best thing to use even for a stand-alone interactive page.

This is what I'm thinking...  Also, I don't think you can use Hibernate manual flush without a conversation.

Typically, the usage is like this:

@Begin(join=true,flushMode=FlushModeType.MANUAL)
public void foo() {...}

But there is now a global setting in the components.xml to set the default flushMode as MANUAL.  Does that work with PAGE scoped components???

Can you achieve atomic conversations with a PAGE-scoped component?  Probably not, but then again, a LRC is typically used with multiple JSF pages, but not necessarily...

[israel.bgf]

Well, all my pages use a lot (really lot) of ajax calls, so page-scope is my choice 100% of time. I just need a place to get the sate stored per page, and well it does it. The only problem is the back-button with richfaces components, it doesnt work. Conversation, and the global transactions don't look very WEB2.0 friendly for me, the need to do a redirect to clean a conversation keep it away from me and that's sad indeed.

Seam for me is a JSF ultra-hiper-powerup. The conversational thing, and the global transactions i don't suit me very well, i'm using Seam for 1 year and i'm still thinking if the user don't use tons of ajax to do really nice effects and think like that (pushing richfaces to the limits). Just few people seems to be bothered with the things that I say, but maybe Seam 3 will be ajax friendly as the way i like.

[brandonsimpson]

Arbi, I haven't tried the global setting, so I'm not sure. It sounds like you would still need a LRC for it to be useful across several interactions.

The last time I tried using page-scoped components was when I was first starting out with Seam, so take this with a grain of salt!

I started off with page-scoped components, but when I interacted with my page, I was having problems with detached entities. This led me towards using a LRC and conversation-scoped entityManager with manual flush (to avoid Seam automatically flushing/closing the entityManager when each transaction ended).

Then I noticed that my onDestroy was never being called on my PAGE scoped components...whether when navigating to another page, closing a browser tab, or closing the browser completely. I figured then, that probably the page components would last until the session expired, and I didn't see anything extra that PAGE scope gave me that an LRC did not. At that point I decided that PAGE scope was essentially broken and not worth using.

As to the question of using PAGE-scoped components in an atomic conversation, I think you probably can...it's only the entityManager that matters. As far as I know the entityManager is always conversation-scoped (unless you override it somehow). So I think if you set up the entityManager to be in an LRC and use manual flushing, you could use page-scoped components for everything else, but those page-scoped components may not be cleaned up properly (per my above observations). So I think that the global setting you mentioned probably wouldn't be useful unless you used an LRC. Otherwise, I would assume your entityManager would be clened up with your temporary conversation.

I'm sure this is probably a confusing post, but I hope it helps.

[israel.bgf]

Just to explain the page scope. It's not broken, and the @Destroy is indeed not executed (not when you should think that it would at least). JSF store the last 15 viewRoot, and only after the 15th opened page that one would be destroyed, and that's not all, if you do another GET at your page somehow, it will start another view root with new values. You can imagine that the viewRoots are stored in a matrix of 15x15, and a new x position is set every time that you trigger a get request.

This looks bad at a first sight, but not so bad at all. Btw, it's in the spec and can be configured in the web.xml.

(sorry for my poor English, for such an complex explanation)

[brandonsimpson]

Thanks, Israel! That makes a lot more sense...good to know then that page-scoped components won't grow unbounded. And btw your English was perfect...I wouldn't have even guessed you were not a native English speaker. =)