Scope/Context feedback

[texan]

Just a followup from my adventures with http://www.jboss.com/index.html?module=bb&op=viewtopic&t=90169. My root problem turned out to be the Seam practice of redirecting to the displayed page when you return the page itself from your action (see below). My reading of the reference manual led me to believe that Seam passed ALL of the contextual information to the view, even when there was a redirect. While it didn't really make sense to me that request (EVENT scope) data would survive a redirect, I had concluded that Seam was doing some sort of magic to accomplish this. I have now concluded that I was wrong.

I was returning the actual view path from my action methods, like "/Document.xhtml". As mentioned in the manual, this does a redirect to the page. Because of that, the only data that gets preserved is the stuff stored in the session or application context (including long running conversations).

I imagine most of you are saying "well, duh" about now, but I really did believe that Seam was magically taking care of all this! And the Seam examples reinforced my beliefs simply because they tend to promote the Conversation feature of Seam, which stores stuff in the Session, or provide stateless actions with SESSION scoped beans.

Anyway, the solution for me was to define "navigation-case" entries for my pages WITHOUT the "redirect" tag included, like this:

 <navigation-rule>
 <navigation-case>
 <from-outcome>document</from-outcome>
 <to-view-id>/Document.xhtml</to-view-id>
 </navigation-case>
 </navigation-rule>

I love the conversation idea for things like editing data, where there's a well defined entry and one or more exit points to a workflow. However, most of the rest of my app is made up of "open ended" conversations. Many requests are a typical example of an old CMP style request, where there is no need to store state between requests, and it's impractical to do so because of memory usage on the server. Maybe this is a reflection of imposing the old architecture, but for the most part the workflow is driven by business requirements.

Now that I understand more of the details of how scope works (and have stumbled over the obvious fact that redirects wipe out a lot of state), I can easily mix SESSION, EVENT, and CONVERSATION scoped objects and actions into my app.

In terms of the reference manual, I would like to request the following:

1. Add a new example (or revamp an existing one) to highlight the "mostly stateless" situation, where an incoming request (maybe with a request variable) triggers a database query and the results are passed to the view, without any SESSION or CONVERSATION scoped objects. There may already be an example of this in the existing code, but I couldn't find it. There was always either a conversation involved or the bean that was returned had SESSION scope.

2. Add more description around the scope types.
a. Make it clear that EVENT scope doesn't survive a redirect (even though that should have been obvious to me).
b. Explain the difference between CONVERSATION scope while you're IN a conversation, vs. when you're not [when you're not, it also doesn't seem to survive the redirect, since the implicit conversation wasn't long running].
c. Explain what PAGE scope is and what it does, maybe with examples. The description itself doesn't tell me how to USE this scope, or how it differs from other scopes.

3. Describe the relationship between an action's scope and the use an extended persistence context.
a. What are the requirements on action scope (I assume you need a long running conversation or possibly session scope)
b. What are the advantages of the extended persistence context? Maybe it's just a performance optimization, but it seems like it's no different that executing "em.merge" with the entity bean.
c. What are the consequences of using an extended persistence context? Does it keep a JDBC connection open? (I assume not.) What happens if the action's context expires?

[cptnkirk]

Take a look at the RESTful section in the documentation and the blog example for tips on your "mostly stateless" apps.

[texan]

While I have to agree with you that the blog example does use this, it's not exactly the best way to show it. That is, that example is showing an already-complicated flow of control and it hard to compare that with more straightforward code.

Although I do use the pull approach for one of my pages that doesn't need any inputs, I wouldn't dream of using the RESTful approach as shown in the tutorial (bookmarkable search results). What I mean is, I want to be able to take vacations and count on the fact that my peers can decipher the flow of the application without calling me.

I think it's great that this kind of stuff exists, but it's hard enough to read other people's code without having to figure out the magic of @Factory and @Unwrap code. Maybe as we use Seam a little more, we'll start taking advantage of more sophisticated features and will laugh at how closed-minded we were "back then", but for now, we have to keep it simple so we can keep our heads above the rising flood of new technology.

We're all from a Struts/JSP background and are struggling to absorb JSF/MyFaces, Facelets, Seam, and EJB3 all at once. The chain of events went like this:

1. Struts is just plain old news: I hear that JSF 1.2 was released and is much improved.
2. Supposedly, 1.2 solves "all the hassles" that caused us to ignore JSF for years
3. Oops, 1.2 fixed some problems, but JSF is still really messy due to the XML configuration complexity and other hassles.
4. Hey, I hear that JBoss released this Seam thing that is supposed to make JSF development more intuitive.
5. Wow, it's amazing how much configuration and glue Seam eliminates, and it provides some new features as well that aren't really provided elsewhere.
6. What the $#^@! ??? Did you see what they said about EJB3 in the Seam manual? We just ignored the EJB articles because it was always too clumsy, but now it's awesome!
7. Unbelievable, look what they did with Entity Beans! About damn time.
8. Okay, we'll use JSF, Seam, and EJB3
9. Man, JSPs still kind of suck, but the Seam tutorial and some examples use this Facelets thing that eliminates JSP and adds some templating featues. Okay, we'll use that too.
10. Well, the JSF data table is okay, but I hear that MyFaces has a nicer version with sorting and paging. Okay, we'll use that too, and we'll get some of the other MyFaces features we've heard about.
11. And here we are, learning it all at once.

[cptnkirk]

The given Seam examples and documentation isn't PhD work, or even that complex. It does try and provide a complete example (non-trivial) and it does assume a certain foundation.

In the case of your team, can I suggest some training. At least on JSF and Hibernate/JPA and then sprinkle in some EJB3 and Seam if available. I believe that JBoss offers training on all of these technologes. I have also had great experience with training from ArcMind. You should be able to get up to speed in about a week. The development team at my organization made a previous technology leap to the one you're making, and let me say that a week of on-site training (available for around $10-15k depending on size) was money very well spent.

From there I'd start learning how Seam improves upon what's currently available in the JSF/EJB3/JPA technology stack.

You'll see that @Factory and @Unwrap are not magic. And you'll see how Seam can allow for a tremendious line of code reduction vs alternative best practice uses of JSF/EJB3/JPA. In the end this should allow for much easier code readability and smaller modules. Which all equals fewer calls on vacation.

I and others are always willing to help here on the forums, but to get the most of out what we're saying about Seam I think training in other areas would go a long way. At the very least you'd no longer be trying to learn 5 things at once, and could focus on doing Seam well.

[texan]

I agree about the training, and we'll probably get going on that before too long. Please don't mistake my post for a complaint about Seam itself - the more I learn the better I like it. I was just thinking that the reference manual could use a little clarification in certain areas based on my fumbling around with the technology.

Once I learned certain things (mentioned at the start of this thread), I found that if I re-read the manual a few times, I could sort of infer the conclusion that I reached the hard way. However, the requests I made in this post are to help clarify areas that I think could use clarity.

[cptnkirk]

Agreed, docs can always be better. Although as far as OS projects go, these are pretty good. I did a quick search for PAGE scope and found that the issues example uses it. In particular the ProjectFinderBean.

The usage and design pattern seem to fit my guess from a previous post. PAGE scope allows stateless controllers to outject and manipulate data relavant to a specific page (in this case a project search screen or something) across multiple requests.

If this use case or Seam doemo doesn't work for you, start a new problem specific thread.

[gavin.king]

Note that temporary conversation contexts DO survive redirects (as long as you have SeamRedirectFilter). Event contexts do not, of course.