from outside of the project there seems to be nothing more than the documentation.
I'm quite often pretty lost as well. Until the documentation on that part is better illustrated with examples, try to think of contexts as containers that hold data.
E.g. the booking example is able to handle several booking processes in different windows. This means, that there are several data containers in the users httpsession which hold the state of the current window.
Those containers are managed by seam. When they are stale for too long, the are removed from memory. You can configure how long that takes.
Which container you get per window is handled by Seam. Whenever a request from a web page goes to a method that is annoted with @Begin, a new data container is created for you. All following calls have access to that container and put their data in it. When you reach a method that is annoted with @End, the container is destroyed and memory is freed.
You also have the ability to use trees/nested containers when you use @Begin(nested=true).
The whole development is more like trying to develop a swing gui. There you would probably also define different containers where to store your business data in. One for global/application wide data, one for every window/MDI window that you can only access per window/process/...
Whenever you try to access data from a jsf page, have a look at the server log file where the seam framework tries to get the data from. You see that it looks for it in different contexts. That can be pretty useful on your way when you try to figure out why you can't find your data in the rendered page.
Hope that helps a bit, might be a bit confuse, but at least I tried :-)
The idea is that instead of putting functionality on some stateless Action object (or SLSB), and manually pushing stateful JavaBeans in and out of constructs like HttpSession, HttpRequest, ServletContext, that are an explicit API representing a context, you instead bundle the state and logic together into a component that is implicitly associated to a scope. This is more transparent and more object oriented.
Does that make sense?
Maybe you can give me an example of how I should be designing my webapps using Seam.
Lets take a simple CRUD application, The home page should be accessed by a GET request and accept a parameter that identified the current user. It should display a list of products in a table, selecting a product should display a page of the product details. There should also be a shopping basket that you can add products to and remove products from.
1) How many Seam components should I need to do this?
2) In what scope(s) should they exist?
3) Do I have to tag my Entity beans as Seam components?
I've checked the examples, and I know there are similarities, but what I'd like is a more in depth explanation of when and where to use things.
Thanks for your help!
PS: Gavin, I hear you're giving a talk in London on March 29th, as part of the JBoss ON the Road seminar. Can I ask whether the focus of the workshop is EJB3/Seam or JBoss ON?
Ignore question 3, I see you've already answered that one is another thread! :)
BTW, hope you had a nice holiday!
(1) Depends upon what is the scope of the product list, and what is the scope of the shopping cart. Session? Conversation? Application?
Very loosely, a good first cut is to use one Seam component per conversation, and another Seam component each time you have some set of data that is not conversation-scoped. Have you looked at the DVD Store and booking demos, which implement workflows much like you describe?
(2) This is for you to define! A shopping cart is often session scoped, but might be conversation scoped. A product list is often session scoped, but may be conversation scoped or even application scoped. It completely depends upon how you want your application to work when the user opens up multiple windows.
My talk in London is 1.5 hours about Seam. The rest of the day focuses mainly on JBoss ON.
I had a great holiday, thanks ;)