- 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: an extensible way of managing application scopes (19 messages)
- Posted by: Antonio Petrelli
- Posted on: June 28 2006 07:25 EDT
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:Threaded Messages (19)
- Encapsulated Context by Daniel Takai on June 28 2006 09:00 EDT
- Re: Encapsulated Context by Antonio Petrelli on June 28 2006 09:59 EDT
- Re: Scopes: an extensible way of managing application scopes by Kris Jenkins on June 28 2006 09:22 EDT
- Re: Scopes: an extensible way of managing application scopes by Antonio Petrelli on June 28 2006 09:39 EDT
- Re: Scopes: an extensible way of managing application scopes by William Louth on June 28 2006 09:51 EDT
- Re: Scopes: an extensible way of managing application scopes by analog boy on June 29 2006 04:44 EDT
- Re: Scopes: an extensible way of managing application scopes by Cédrik LIME on June 28 2006 10:48 EDT
- Re: Scopes: an extensible way of managing application scopes by Antonio Petrelli on June 28 2006 11:55 EDT
- Remins me something ;) by Vitaly Shevchuc on June 28 2006 12:49 EDT
- Re: Scopes: an extensible way of managing application scopes by Eelco Hillenius on June 28 2006 13:59 EDT
- Re: Scopes: an extensible way of managing application scopes by Antonio Petrelli on June 29 2006 03:25 EDT
- Re: Scopes: an extensible way of managing application scopes by Eelco Hillenius on June 29 2006 01:28 EDT
-
Re: Scopes: an extensible way of managing application scopes by Michael Jouravlev on June 29 2006 05:55 EDT
- Re: Scopes: an extensible way of managing application scopes by Antonio Petrelli on June 30 2006 07:05 EDT
- Has Model 2 failed? by Michael Jouravlev on June 29 2006 18:22 EDT
-
Re: Has Model 2 failed? by Eelco Hillenius on June 30 2006 02:58 EDT
- Re: Has Model 2 failed? by Michael Jouravlev on July 03 2006 11:57 EDT
-
Re: Has Model 2 failed? by Eelco Hillenius on June 30 2006 02:58 EDT
- Re: Scopes: an extensible way of managing application scopes by Antonio Petrelli on June 29 2006 03:25 EDT
- micro frameworks must DIE by B C on June 29 2006 08:33 EDT
- support state in business logic layer by query weki on July 01 2006 21:19 EDT
-
Encapsulated Context[ Go to top ]
- Posted by: Daniel Takai
- Posted on: June 28 2006 09:00 EDT
- in response to Antonio Petrelli
Looks like Encapsulated Context Pattern to me. Use Spring instead. -
Re: Encapsulated Context[ Go to top ]
- Posted by: Antonio Petrelli
- Posted on: June 28 2006 09:59 EDT
- in response to Daniel Takai
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 :-) -
Re: Scopes: an extensible way of managing application scopes[ Go to top ]
- Posted by: Kris Jenkins
- Posted on: June 28 2006 09:22 EDT
- in response to Antonio Petrelli
Isn't this pretty similar to the new bean scopes in Spring 2.0? -
Re: Scopes: an extensible way of managing application scopes[ Go to top ]
- Posted by: Antonio Petrelli
- Posted on: June 28 2006 09:39 EDT
- in response to Kris Jenkins
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. -
Re: Scopes: an extensible way of managing application scopes[ Go to top ]
- Posted by: William Louth
- Posted on: June 28 2006 09:51 EDT
- in response to Kris Jenkins
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.comIsn't this pretty similar to the new bean scopes in Spring 2.0? -
Re: Scopes: an extensible way of managing application scopes[ Go to top ]
- Posted by: analog boy
- Posted on: June 29 2006 04:44 EDT
- in response to William Louth
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 ;) -
Re: Scopes: an extensible way of managing application scopes[ Go to top ]
- Posted by: Cédrik LIME
- Posted on: June 28 2006 10:48 EDT
- in response to Antonio Petrelli
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! -
Re: Scopes: an extensible way of managing application scopes[ Go to top ]
- Posted by: Antonio Petrelli
- Posted on: June 28 2006 11:55 EDT
- in response to Cédrik LIME
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...) -
Remins me something ;)[ Go to top ]
- Posted by: Vitaly Shevchuc
- Posted on: June 28 2006 12:49 EDT
- in response to Antonio Petrelli
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 -
Re: Scopes: an extensible way of managing application scopes[ Go to top ]
- Posted by: Eelco Hillenius
- Posted on: June 28 2006 13:59 EDT
- in response to Antonio Petrelli
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 -
Re: Scopes: an extensible way of managing application scopes[ Go to top ]
- Posted by: Antonio Petrelli
- Posted on: June 29 2006 03:25 EDT
- in response to Eelco Hillenius
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. -
Re: Scopes: an extensible way of managing application scopes[ Go to top ]
- Posted by: Eelco Hillenius
- Posted on: June 29 2006 13:28 EDT
- in response to Antonio Petrelli
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.
Cool. I just took a short look at your code and obviously missed that. It's pretty similar in how Wicket manages multi windows.
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. -
Re: Scopes: an extensible way of managing application scopes[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: June 29 2006 17:55 EDT
- in response to Antonio Petrelli
What if Javascript is turned off?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. -
Re: Scopes: an extensible way of managing application scopes[ Go to top ]
- Posted by: Antonio Petrelli
- Posted on: June 30 2006 07:05 EDT
- in response to Michael Jouravlev
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 :-) -
Has Model 2 failed?[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: June 29 2006 18:22 EDT
- in response to Eelco Hillenius
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 -
Re: Has Model 2 failed?[ Go to top ]
- Posted by: Eelco Hillenius
- Posted on: June 30 2006 14:58 EDT
- in response to Michael Jouravlev
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 -
Re: Has Model 2 failed?[ Go to top ]
- Posted by: Michael Jouravlev
- Posted on: July 03 2006 11:57 EDT
- in response to Eelco Hillenius
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.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?)
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 -
micro frameworks must DIE[ Go to top ]
- Posted by: B C
- Posted on: June 29 2006 08:33 EDT
- in response to Antonio Petrelli
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 -
support state in business logic layer[ Go to top ]
- Posted by: query weki
- Posted on: July 01 2006 21:19 EDT
- in response to Antonio Petrelli
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