[vk101]

Wouldn't those objects still be in memory with the SFSB still being alive? If you persist many objects and the persistence context closes, doesn't that mean the objects become detached only...aren't those objects still in memory though?

On an unrelated note, does <s:decorate> only work for per-field validation as defined in the annotations? Let's say a backing session bean figures out in its action method that multiple fields are invalid (based on business logic, not Hibernate Validator), how from the action method would you get <s:decorate> for certain fields to alert the user of invalid input?

The reason the validation can't be done directly on a per-field basis is because whether a form field is invalid depends on the value of another form field... Is what I'm suggesting even possible?

[vk101]

An example of the <s:decorate> thing I'm talking about is anytime you do a facesMessage.add(anErrorMessage), how would you indicate to <s:decorate> that the fields that you indicate as relevant to the facesMessage need to be displayed to the user using the rules defined in "afterInvalidField", for example?

[gavin.king]

If your sfsb still references them, sure.


Use the overloaded add() method which takes a component id.

[vk101]

That's right, I did notice a "cid" request parameter in the address bar. However, what confuses me is if I hit CONTROL+N (for a new window) or open a new tab, how does Seam know that you are now in a new conversation and not the same one? After all, isn't it the same "cid" in the request parameter?

Similarly, with the back button, how does Seam know when it builds the component tree that these components belong to a NEW conversation and not an existing one? After all, if you click back and resubmit (with the same cid in the browser bar), wouldn't it "overwrite" the current conversation?

There are many things about conversations that I'm not able to understand, from the above questions. Could you provide some insight about those issues?

Another question I have is whether persist() is necessary in all cases? I have a conversation with a @Begin and @End. A view uses an entity as a backing bean; the action method on an SFSB and EXTENDED persistence context manipulates that entity's properties; then the method returns a String outcome.

No persist() method, but to my amazement it has persisted in the database after @End completes? Do my eyes deceive me!?

[gavin.king]

Seam doesn't do anything in those cases. new window does not hit the server, nor does the back button. This is just the behavior of your web browser. We just leverage what your browser does.

You only need persist() when you want to take a new object, and make it persistent. You never need persist for updating existing managed objects. This is basic Hibernate/JPA, and one of the reasons why extended persistence contexts are good. The fact that this does *not* happen in stateless architectures like SLSB facade or Spring, is one of the reasons why those architectures are, IMO, broken.

[vk101]

1) I'm probably not asking that question correctly...lemme try again. How does Seam know that there's a new conversation, such that it has to increment or change the conversation ID to a new number?

What confuses me is that at any time there's a cid request parameter value...what indicates to Seam that it's time to start a new conversation (apart from hitting another @Begin method)?

I keep hearing that Seam solves the "back button issue", whatever that is...does Seam do this through conversations?

2) Regarding the persist(), it actually is for a brand new entity, which is why I seemed so amazed. Does this happen because of the fact that the entity has been "created" through its use as a backing bean (but I don't see how it became managed by the persistence context).

By the way, can I output everything that's being managed in a given persistence context? (I don't mean EntityManager's contains())

3) Is there any simple way to get writes going to one DB and reads going to its replicated DB (or balance between that and the original DB in addition)?

[norman.richards]

Any request that isn't already part of an active long-running conversation starts a new conversation. These conversations are abandoned at the end of the request unless something (like @Begin) marks them as long-running conversations.

[gavin.king]

I keep hearing that Seam solves the "back button issue", whatever that is...does Seam do this through conversations?

Yes.

Regarding the persist(), it actually is for a brand new entity, which is why I seemed so amazed.

Ahem, this would "amaze" me too :)

By the way, can I output everything that's being managed in a given persistence context?

No, but you can see it in your debugger.

3) Is there any simple way to get writes going to one DB and reads going to its replicated DB (or balance between that and the original DB in addition)?

No but we have talked about implementing something like this in Hibernate.

[vk101]

Sorry, I'm having a tough time understanding conversations, but I'd like to know a bit about them... How do they solve the back button issue?

I'm really confused on this whole back-button issue...in some cases, it's the thing that gets solved by not caching pages...in other cases, it's the thing that gets solved by using redirects...and now it's conversations...?

I've heard so many variations of this back button issue (outdated info, double form submission, etc) that I have no idea how this all fits together...! So confused...!

Somebody please explain all of this if you know...

[gavin.king]

There are several related problems:

(1) you want the user to be able to freely navigate backward during a conversation
(2) but you don't want them to be able to navigate backward once the conversation ends - or rather, its ok to navigate back, but if they try to submit a form, you want to stop them let them know that the conversation is over
(3) you also want them to be able to refresh pages, and see the conversational state, but you don't want the browser to resubmit the form
(4) you also want to be able to display transient messages

obviously (1) and (2) conflict - if you have no conversations, its very difficult to tell when they are allowed to go back and resubmit, and when they are not.

(3) and (4) also conflict - you have a choice between using redirect-after-post, which makes it difficult to display success/error messages, or not using it, which makes the browser try to resubmit the form when the user hits refresh

Conversations solve the first conflict, because the server now knows when the conversation is over. Try this in the booking demo: you can back button as much as you like - but if you confirm a booking, and then try to go back and re-confirm it, Seam detects that and gives a nice message.

They also solve the second conflict: you can user redirects as much as you like, and messages and other state remain on the server across the redirect.

When I do my Seam presentation I demo all these things, and it makes a lot more sense to *see it* than have it explained to you.

[vk101]

I have been looking into the whole issue of Exceptions and have several questions about how to choose and design Exceptions for a Seam application. There's quite a few questions below, but hopefully somebody could address them. (I imagine all these dumb beginner questions must be getting irritating by now, but I've really appreciated all your help!)


1) Should exceptions be checked or unchecked in Seam? I'm gonna guess that all should be unchecked because isn't that the whole reason that exceptions.xml and exception annotations exist...they handle cases where the exception propagates far enough up that the rules take effect. If you declared any exception as checked, you'd have to catch it and it would never propagate and exceptions.xml wouldn't be used, right?


2) Would exceptions.xml rules also not be used for any exception that was unchecked but that you caught in every case where it possibly could be thrown?


3) Would you expect to see more checked or unchecked user-defined exceptions in a Seam application? (Or does it totally depend upon the nature of the application, meaning there aren't universal best practices on this issue?)


4) I can't tell whether my exceptions should cause a rollback or not. What criteria might help me understand this decision more clearly? For example, should an exception in a method that makes NO updates/additions/removals to the database never cause a rollback?

What about for ones that do make changes - is it ALWAYS yes for rollbacks in this case?


5) In exceptions.xml, is there a way to return a logical outcome name for a given exception (that would be defined in the navigation rules) rather than an actual view ID for a physical page? I didn't see an attribute for render and redirect that implies this case in the DTD.


6) If there were an exception and I needed to return a page indicating an error to the user, I could do one of two things: annotate the exception with an error code, then in web.xml (or wherever it is) define a custom view to be associated with that error code; OR I could simply do a @Render or @Redirect to the same view.

So then what's the difference between returning an error code and a regular view ID? In either case, what the user would see on his screen would be the same in either case, so what criteria go into choosing one over the other?


7) An example that's got me stumped is a login() action method on a session bean. It searches for the entered login name in the database. If the login name doesn't exist, it throws a user-defined exception. I realize the questions below are application-specific, but I don't even know how to go about making these choices. Perhaps you could explain what you might do in this case and why?

A) Should this be a system or application exception?
B) If application, should it be checked or unchecked with @ApplicationException annotation?
C) If application, should it be cause a rollback or not?
D) In either case, should I let it propagate or catch it?
-Wow, so confused on this!