Scopes is another way of managing web application scopes. Instead of using the request to get the session context and the session to get the application context, you access directly a "State" object that contains a certain number of contexts, each one connected to a scope name. This "State" object is:

• independent from the platform: you can use it in a Servlet environment, or in a Swing package
• usable in every tier, even in your business logic: it could be useful to avoid anemic programming
• extensible: you can now add new scopes! In this package the "window" scope is ready to use!
• independent from the framework: in a Servlet environment it simply wraps an HttpServletRequest

Scopes provides an infrastructure for making new scopes: each part of the scope management (context building, managing the request, filtering the result) are supported through the use of interfaces and abstract implementations. And, finally, Scopes enables the Window scope! Imagine, different attributes for different client windows, without relying on session that can lead to conflicts and incorrect views. Message was edited by: [email protected]

Looks like Encapsulated Context Pattern to me. Use Spring instead.

Looks like Encapsulated Context Pattern to me. Use Spring instead.

I don't think that Scopes is conflicting with Spring. The scope of Scopes :-) is bringing scope managements altogether, maybe using those from popular frameworks like JBoss Seam, Tapestry and RIFE. By providing an extensible framework, you can build the entire process to map URLs, JavaScript code, redirection management, HTTP request into a context. This is the case of the "window" scope. And I don't think that Spring lets you use window scope anyway :-)

Isn't this pretty similar to the new bean scopes in Spring 2.0?

Isn't this pretty similar to the new bean scopes in Spring 2.0?

Probably, but I need to see the docs updated before writing any comment.

Which I believe has largely being inspired (or driven) by JBoss Seam which incidentally seems to be gaining traction especially with the Web Bean standardizaton proposal. regards, William Louth JXInsight Product Architect JInspired http://blog.jinspired.com

Which I believe has largely being inspired (or driven) by JBoss Seam

I think it is actually a feature adopted from ATG's Nucleus, an early, commercial IoC container. AFAIK Sony wanted use the same idea with Spring so Rod added it to the core. I don't think Spring's implementation is as application-specific as Seam's which is both a good and a bad thing depending on your point of view. Spring's implementation is *very* flexible, but great power brings great responsibility ;)

Instead of using the request to get the session context and the session to get the application context

Here's to another shortcoming in the Servlet spec: one can't get a hold on the ServletContext from a HttpServletRequest without going through an HttpSession (if it has been created)... This has bugged me more than once, and especially when working on MessAdmin. Would have been so nice to not code such workarounds... Oh, well, such is life! Scopes will fit well in projects not using Seam or Spring IMHO. ________ MessAdmin, J2EE administration made easy!

Here's to another shortcoming in the Servlet spec: one can't get a hold on the ServletContext from a HttpServletRequest without going through an HttpSession (if it has been created)

Well in fact I use this strategy to get to ServletContext. Thanks for the advise, I will take it into consideration (e.g. to take ServletContext somehow from the initialization of the filter...)

Funny, few years ago I have created (and then droppped) a similar project http://crosscontext.sf.net with similar motivation : "an independent abstraction of request, session, application and custom user contexts that removes compile-time and run-time dependency on any particular API, like Java Servlet API, thus increasing code portability and allowing code reuse between Web, EJB tiers, Swing rich client, or Web Services" Of course, Spring solves the same problem in much more elegant way. Of course, too much of ThreadLocal makes your code dirty. We all know that. However when you deal with existing projects with old frameworks and untouchable interfaces, creating an abstraction of your scopes is just the right pattern. Example: I what if you need to find out user’s Locale from inside org.apache.commons.beanutils.Converter.convert() implementation. So, such solutions are good for existing non-spring projects. Vitaliy

Looks like a nice, focussed project that could help users of model 2 frameworks use a neater way of doing things. Post processing output like that comes with a (performance) price, but shouldn't be too bad. The only thing that saddens me (sorry Antonio, I don't want to offend you) is that there are still projects popping up almost daily of which the main reason of existence is to facilitate work arounds for the model 2 (web mvc) paradigm (which I consider failed as you probably get from my intonation). Anyway, good for the people that are using model 2 for whatever reason; it's at least one step closer to OO than just passing request parameters all over the place. One remark about the window scope. Judging from your code, that will only work when a window is explicitly opened by a link, but not when the user opens up a new tab or e.g uses ctrl+n in IE. -- Eelco

The only thing that saddens me (sorry Antonio, I don't want to offend you) is that there are still projects popping up almost daily of which the main reason of existence is to facilitate work arounds for the model 2 (web mvc) paradigm (which I consider failed as you probably get from my intonation).

In fact I tried to workaround the Servlet spec, that is terribly ugly with scope management, do you agree with me?

One remark about the window scope. Judging from your code, that will only work when a window is explicitly opened by a link, but not when the user opens up a new tab or e.g uses ctrl+n in IE.

No, it will work even with "open new window", "open new tab" etc. I tried it with Firefox, but I think it will work even with IE. As it is written in the site: When a new page is open without the "window.open" JavaScript command, for example when you open the browser for the first time, of if you open a link in a new window/tab, the window itself has not a name. For this reason, some code is injected: this code checks if the window has a name, and if it has not any, it calls a server class (through the use of DWR) that generates a session-unique (i.e. it is unique within the same session) window name.

No, it will work even with "open new window", "open new tab" etc. I tried it with Firefox, but I think it will work even with IE.
As it is written in the site:

When a new page is open without the "window.open" JavaScript command, for example when you open the browser for the first time, of if you open a link in a new window/tab, the window itself has not a name. For this reason, some code is injected: this code checks if the window has a name, and if it has not any, it calls a server class (through the use of DWR) that generates a session-unique (i.e. it is unique within the same session) window name.

Cool. I just took a short look at your code and obviously missed that. It's pretty similar in how Wicket manages multi windows.

One remark about the window scope. Judging from your code, that will only work when a window is explicitly opened by a link, but not when the user opens up a new tab or e.g uses ctrl+n in IE.

No, it will work even with "open new window", "open new tab" etc. I tried it with Firefox, but I think it will work even with IE.
As it is written in the site:

When a new page is open without the "window.open" JavaScript command, for example when you open the browser for the first time, of if you open a link in a new window/tab, the window itself has not a name. For this reason, some code is injected: this code checks if the window has a name, and if it has not any, it calls a server class (through the use of DWR) that generates a session-unique (i.e. it is unique within the same session) window name.

What if Javascript is turned off?

What if Javascript is turned off?

It gracefully degrades to simple session context. As we say in Italy, you cannot have a full barrel and a drunk wife :-)

The only thing that saddens me (sorry Antonio, I don't want to offend you) is that there are still projects popping up almost daily of which the main reason of existence is to facilitate work arounds for the model 2 (web mvc) paradigm (which I consider failed as you probably get from my intonation).

I don't think that Model 2 paradigm has failed, maybe just some implementations. But you are right in that using Model 2 to implement the most basic use case of a web application, a web form, is too complicated and error-prone and often does not deliver good user experience. Obviously, I am talking primarily about Struts here. The problem is not the lack of WISIWIG tooling for drawing pages, but the sheer number of Java classes, configuration options and JSP custom tags to represent a logical resource. Model 2 works great for stateless services, like "search", an action performs search and forwards to a result page, pretty straighforward. Model 2 does not work so well to display, say, a "Customer" object and to accept commands/events that modify state of this object. Model 2 is just too low-level. If servlets is machine codes and JSP is assembly language, then Model 2 is plain C. No one writes desktop application in plain C nowadays, everybody uses Visual Basic. Plain C and assebly language allow to better tweak the behavior or appearance, but development takes much longer. But most of the time using low-level tools for UI development is boring. Slapping together an UI by dropping a button and wiring it to an event handler is so much simpler. This is what ASP.NET have proven (as Visual Basic and Delphi before it), this is the path that JSF have chosen. Model 2 sees improvements now. Take a look at Stripes. Minimal XML configuration, View Helper pattern allows preparing output data right from JSP therefore JSP can be called directly, event handling is promoted as first-class practice (similar to Struts dispatch actions, but how many developers use them?), Flash Scope, built-in wizard support, etc. On the other hand, does an application that uses JSP page with a View Helper bean still conform to Model 2 pattern? --- Michael Jouravlev JSP Controls: Build independent page components with JSP

I don't think that Model 2 paradigm has failed, maybe just some implementations. But you are right in that using Model 2 to implement the most basic use case of a web application, a web form, is too complicated and error-prone and often does not deliver good user experience. Obviously, I am talking primarily about Struts here. The problem is not the lack of WISIWIG tooling for drawing pages, but the sheer number of Java classes, configuration options and JSP custom tags to represent a logical resource.

Failed was a very subjective qualification of course. It's - unfortunately - not failed if you look at the number of people that still buy into it. But I don't think model 2 is a good idea - ever. Even if you can do your stuff done without too much of a hassle, the programming model still is too far off of just basic Java programming. The abstraction - the little there is - is ill chose. JSP model 1, using beans, is actually a much better idea. Maybe extended with your JSP controls framework, or tagonist, or with using something like DWR directly. It lets you stay focussed on your end result and by letting you use beans and custom tags, you typically have enough tools to get the job done. On the other side of the spectrum - equally or better a good idea imo - the frameworks that focus on just java programming: Wicket, Echo and now GWT. They rock for how they allow you to manage complexity, work in large teams, etc. And they are just so much more fun to use.

Model 2 works great for stateless services, like "search", an action performs search and forwards to a result page, pretty straighforward.

Straightforward for simple cases. Elegant never.

If servlets is machine codes and JSP is assembly language, then Model 2 is plain C.

I don't think model 2 is better or higher level than JSP with a few beans and custom tags.

But most of the time using low-level tools for UI development is boring. Slapping together an UI by dropping a button and wiring it to an event handler is so much simpler. This is what ASP.NET have proven (as Visual Basic and Delphi before it), this is the path that JSF have chosen.

Such tools obviously work for many people. But certainly not most. There are many reasons for people to prefer *not* to work with such drag and drop tools. But we've seen enough of that discussion by now.

Model 2 sees improvements now. Take a look at Stripes. Minimal XML configuration, View Helper pattern allows preparing output data right from JSP therefore JSP can be called directly, event handling is promoted as first-class practice (similar to Struts dispatch actions, but how many developers use them?), Flash Scope, built-in wizard support, etc.

Stripes certainly looks like an improvement. Maybe because it is hardly recognizable as model 2. That said, I prefer a stateful programming model with reusable components (did you check out Wicket's new wizard component for instance?) Btw a typical reason that people gave in the past for using model 2 instead of Wicket is that it uses server side memory for state management. Since a few months Wicket actually has the concept of stateless pages, giving it the same scalability characteristics of model 2 frameworks. -- Eelco

Model 2 sees improvements now. Take a look at Stripes. Minimal XML configuration, View Helper pattern allows preparing output data right from JSP therefore JSP can be called directly, event handling is promoted as first-class practice (similar to Struts dispatch actions, but how many developers use them?), Flash Scope, built-in wizard support, etc.

Stripes certainly looks like an improvement. Maybe because it is hardly recognizable as model 2.

It allows to mix Model 1 and Model 2 approaches, which is a good thing I guess. I would say that Stripes is the cleanest action-type framework.

That said, I prefer a stateful programming model with reusable components (did you check out Wicket's new wizard component for instance?)

I have not looked at the code, but the concept is similar to something that I have done eariler. And mind you, my wizard works with Struts, so Struts is not hopeless for stateful programming ;-) Components can be created with Struts as well. Basically, I took my JSP controls library and converted lifecycle tags into a Struts action. Do these features make Struts programming fun? Probably not. But they provide nice enhancements to the framework. --- Michael Jouravlev JSP Controls: Build independent page components with JSP

it sucks not to know how to integrate your stuff. But you think you solve some simple stupid little problema dn the world will beat a path to your door. Go to h-ll

Scopes is usable in every tier, even in your business logic, so at this point , it is like Spring 2.0 new bean scopes. When my Ioc/AOP framework :JdonFramework was born, it has support the state manager of POJO Service in business layer, http://jdon.dev.java.net