Received: by 10.70.71.8 with HTTP; Thu, 6 Oct 2005 12:53:33 -0700 (PDT)
Date: Thu, 6 Oct 2005 12:53:33 -0700
From: Michael Jouravlev <hidden>
Subject: Re: [Stripes-users] [Stripes-User] Generic execute(), RedirectResolution, and other questions
Content-Type: text/plain; charset=UTF-8; format=flowed
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
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 RCVD_BY_IP Received by mail server with no name
0.0 SF_CHICKENPOX_HASH BODY: Text interparsed with
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_AT BODY: Text interparsed with @
0.0 SF_CHICKENPOX_APOSTROPHE BODY: Text interparsed with '
X-Reply-To: Michael Jouravlev <hidden>
List-Id: A list for dicussing building applications with Stripes. <stripes-users.lists.sourceforge.net>
On 10/6/05, Tim Fennell <hidden> wrote:
>> (1) UrlBinding annotation contradicts with common practices
>> you have an inverted approach, where
>> action defines an URL that it will respond to, like this from API
>> docs: @UrlBinding("/action/SampleAction").
> /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 ;)
Yep, that sounds like a nice buzzword :)
>> (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.
Um, I cannot agree with that... I prefer to think of JSP page as of
data-aware HTML. Also, I prefer to think in terms of ASP.NET, and to
consider an action as a code-behind class, and JSP as just a markup.
Together they define a resource, so JSP page is inseparable from
action and should not be called outside.
But this is just a matter of preference, if I can use JSP as a view
from action (seems that I can), I would be happy enough.
>> (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.
Please allow me not to agree with that. I can name you at least for
variations of a request:
* Initialize and render resource (should clean up and use with a fresh
set of data)
* Navigate to resource using a link (usually displays resource it its
* Manually reloade a resource using the browser's refresh button
(should display in the current state, maybe should not redisplay the
* Reload a resource as the second phase of request processing (see link further)
> 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.
Ok, that will work I guess. I have not played with annotations yet, so
this will be my first time.
>> (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.
That is good. I prefer stateful actions.
>> (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.
Yeah, I know. Several session-scoped instances would be nice, if I
worked with several objects of one type in different windows
>> (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.
This will not work for me. Is it possible to store them in session as an option?
>> (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.
I don't want to forward, I want to redirect. Also, I don't want to
forward to a JSP page, I want to redirect to action, that might do
some additional stuff before displaying the page.
> 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.
Here is the link to my library for Struts, which implements this pattern:
If I could do the same in Stripes, that would be really really great :-)
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
Stripes-users mailing list