Received: from cmcc5-dfe.broad.mit.edu ([22.214.171.124])
by esc49.midphase.com with esmtpa (Exim 4.44)
for hidden; Thu, 06 Oct 2005 15:23:12 -0400
Date: Thu, 6 Oct 2005 15:24:31 -0400
From: Tim Fennell <hidden>
Subject: Re: [Stripes-users] [Stripes-User] Generic execute(), RedirectResolution, and other questions
Content-Type: text/plain; charset=UTF-8; format=flowed
X-Mailer: Apple Mail (2.734)
Received-SPF: unknown (socket error)
X-AntiAbuse: Sender Address Domain - tfenne.com
X-Spam-Score: 0.1 (/)
X-Spam-Report: Spam Filtering performed by sourceforge.net.
for more details.
Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001
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
List-Id: A list for dicussing building applications with Stripes. <stripes-users.lists.sourceforge.net>
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
/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
> (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
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
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
> (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.