Re: [Stripes-users] [Stripes-User] Generic execute(), RedirectResolution, and other questions

Subject:   Re: [Stripes-users] [Stripes-User] Generic execute(), RedirectResolution, and other questions (find more)
Date:   Oct 06, 2005 15:24

Return-Path: <hidden>
Received: from ([])
 by with esmtpa (Exim 4.44)
 id 1ENbKZ-0002pY-QO
 for hidden; Thu, 06 Oct 2005 15:23:12 -0400
Message-Id: <hidden>
Date: Thu, 6 Oct 2005 15:24:31 -0400
From: Tim Fennell <hidden>
Reply-To: hidden
Sender: hidden
To: hidden
Subject: Re: [Stripes-users] [Stripes-User] Generic execute(), RedirectResolution, and other questions
In-Reply-To: <hidden>
Errors-To: hidden
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Original-To: hidden
Delivered-To: hidden
References: <hidden>
X-Mailer: Apple Mail (2.734)
Received-SPF: unknown (socket error)
X-AntiAbuse: Sender Address Domain -
X-Spam-Score: 0.1 (/)
X-Spam-Report: Spam Filtering performed by
 See for more details.
 Report problems to
 0.0 SF_CHICKENPOX_PERIOD   BODY: Text interparsed with .
 0.0 SF_CHICKENPOX_SLASH    BODY: Text interparsed with /
 0.0 SF_CHICKENPOX_MINUS    BODY: Text interparsed with -
 0.0 SF_CHICKENPOX_COLON    BODY: Text interparsed with :
 0.0 SF_CHICKENPOX_APOSTROPHE BODY: Text interparsed with '
 0.1 HTML_40_50             BODY: Message is 40% to 50% HTML
 0.0 HTML_MESSAGE           BODY: HTML included in message
X-BeenThere: hidden
Precedence: bulk
List-Unsubscribe: <;,
List-Id: A list for dicussing building applications with Stripes. <>
List-Post: <mailto:hidden>
List-Help: <mailto:hidden?subject=help>
List-Subscribe: <;,
List-Archive: <>

Hi Michael,

Thanks for taking the time to check out Stripes.  Comments/answers  


> (1) UrlBinding annotation contradicts with common practices
> What I mean, is that a web application should not care where it was
> called from. HTTP server should care for URL resolution, at least on
> the level of application context, and to feed request to a proper
> handler object. In your case, you have an inverted approach, where
> action defines an URL that it will respond to, like this from API
> docs:  @UrlBinding("/action/SampleAction"). So, what is "/action"
> here? If this is an application context, than this is just improper.
> If this is the path *within* app context, this might be acceptable for
> me.
/action is simply a path within the web application context (i.e.  
context relative).  I guess the annotation does somewhat invert the  
usual mapping process, but I like it that way and it does away with  
the mapping XML documents.  Perhaps I should name it "Inversion of  
Binding" and market it as a feature ;)

> (2) Is direct access to JSP page considered a bad practice in Stripes?
> It is bad practice in Struts, all request should be channeled through
> action, which preps the data for a view.
Absolutely not, it's positively encouraged.  My view on the matter is  
anything that is going to modify session or a database or do  
something businessy should probably go through an action.  Any page  
that is just digging up data to display should probably be navigated  
to directly.  To help with this there is a tag,  
<stripes:useActionBean../> which will allow you to instantiate and  
bind an ActionBean directly on a JSP.  Will this could obviously be  
mis-used, it's purpose is to allow ActionBeans to be used/re-used as  
view helpers.

> (3) What happens when I navigate to URL without submitting a form?
> Stripes does not have generic execute() method, where all request are
> channeled to. What method will Stripes call? The one that is marked as
> @Default? I would say, that default submitting of a form is different
> from navigating to an action URL. I would like to have an execute(),
> so I can decide what to do with request.
It invokes the Default handler method.  In my mind the  
differentiation between GET and POST, form submit and URL invocation  
is an artificial line that is only going to get blurrier as AJAX  
becomes more prevalent.  I like the default mode as it is, but  
there's nothing stopping you implementing a default handler method  
that implements the behaviour you describe by inspecting the request.

> (4) Can I have an ActionBean with session scope? In this case I would
> have only one instance of actionbean per session, instantiated only
> one.
You can.  I don't like doing this in general, so request scope is the  
default and strongly encouraged.  There is a @SessionScope annotation  
for an ActionBean that will cause it to be instantiated and put in  
session on the first request, and accessed from there after that.

> (5) Can I have more than one instance of an ActionBean per session?
> For example, Wicket can do that.
Session scoped but more than one instance?  Not currently.  Request  
scoped you can have as many as you like.

> (6) I read through your sample, the fields are strongly typed (not
> strings), but invalid string values are still retained in case of
> errors. What happens with buffered data on redirect?
The strings are just pulled back from the HttpServletRequest  - which  
gives you your answer.  On redirect they are lost.

> (7) Is there a certain lifecycle besides calling handler methods?
There is a simple lifecycle, and it's one that I clearly need to  
document.   Essentially:
     1. ActionBean is instantiated (or retrieved from Session)
     2. setContext() is called (which is a convenient hook for any  
pre-processing you want to do)
     3. Stripes' validation and binding is run
     4. If there are no errors, validate() and then the handler  
method are run
     5. The resolution gets executed

There's more to it than that, based on additional interfaces you can  
implement like Validatable and ValidationErrorHandler etc, but that's  
the basics.

> (8) Converting and validation: how I can change the sequence of these
> procedures or to turn them off completely?
Depends on what exactly you had in mind.  If you just wanted Strings  
and no validation you could just use Strings in your ActionBean.  If  
you want to change the sequence you'd probably subclass the default  
ActionBeanPropertyBinder and override some of the methods.  I'll be  
the first to admit that it's probably not optimally structured to  
allow this right now, but as soon as I have a couple of use cases/
examples of what folks would like to do, I'm more than happy to  
refactor to make them easy.

> (9) I would like to implement the following scenarion, how easy  
> would it be:
> * post from browser to ActionBean
> * check input, errors found
> * generate error messages
> * redirect to the same ActionBean using RedirectResolution
> * after browser navigates to the action, action would use
> ForwardResolution to redisplay HTML form along with error messages
I'm not sure I fully understand this.  Why would you want to redirect  
to the same ActionBean and then forward the user to the HTML page?   
In Stripes, unless you tell it otherwise, when validation errors  
occurs it will always forward you to the page that you came from.   
You can do the same thing from and handler method by adding  
validation errors to the context and returning  

Maybe if you could describe what you're trying to accomplish with  
your scenario I could give you a better answer.

> (10) Do you provide services to queue messages to session, and then to
> automatically remove them after they accessed (basically, after view
> is displayed)? Struts 1.2.7 has this feature, quite handy.
No, but that does sound like a nifty feature, and something that  
could be added without a lot of effort.