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)
From:  
Date:   Oct 06, 2005 15:53


Return-Path: <hidden>
Received: by 10.70.71.8 with HTTP; Thu, 6 Oct 2005 12:53:33 -0700 (PDT)
Message-ID: <hidden>
Date: Thu, 6 Oct 2005 12:53:33 -0700
From: Michael Jouravlev <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
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Ex/ZmMF5LkdtHdEtKyZQHEwc9u8wGqomP4xSsT3TOYQD7QwenB/31i7wsqJNC/kxg485ncay5/eD5U3+VY4RkjCQEvIW6gfoTI4jwNlLhvgOUjpy4MO9IaoMQlBWsfaQfktwiwU7Ji+Iybqzz+GuhT7iB3wHco2e0aOaDqPRALY=
Content-Disposition: inline
References: <hidden>
  <hidden>
X-Spam-Score: 0.1 (/)
X-Spam-Report: Spam Filtering performed by sourceforge.net.
 See http://spamassassin.org/tag/ 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-BeenThere: hidden
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
X-Reply-To: Michael Jouravlev <hidden>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/stripes-users&gt;,
 <mailto:hidden?subject=unsubscribe>
List-Id: A list for dicussing building applications with Stripes. <stripes-users.lists.sourceforge.net>
List-Post: <mailto:hidden>
List-Help: <mailto:hidden?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/stripes-users&gt;,
 <mailto:hidden?subject=subscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=stripes-users>
Status:

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
current state)
* Manually reloade a resource using the browser's refresh button
(should display in the current state, maybe should not redisplay the
errors)
* 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
>> 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.

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
simultaneously.

>> (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
> context.getSourceResolution()
>
> 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:
http://struts.sourceforge.net/strutsdialogs/dialogaction.html#ioseparation

If I could do the same in Stripes, that would be really really great :-)

Michael.


-------------------------------------------------------
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
hidden
https://lists.sourceforge.net/lists/listinfo/stripes-users