struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Takanori Hayashi <thaya...@na.rim.or.jp>
Subject Re: Form handling by direct URL in Struts 1.3.8
Date Fri, 15 Jun 2012 00:10:48 GMT
Hello Anjib,

Assumed that you made the distinction on validate method,
then if forwarded JSP page is using userInfo session like
<logic:empty name="userInfo" property="firstName">
             ${userInfo.userName}
</logic:empty>
the same error  is shown.
[Caused by: javax.servlet.jsp.JspException: Cannot find bean: "userInfo" 
in any scope ]
Because you are using "not existing userInfo" at the JSP.  The problem 
is JSP using userInfo being there.

Takanori

(2012/06/14 22:29), Dave Newton wrote:
> On Thu, Jun 14, 2012 at 9:18 AM, Anjib Mulepati<anjibcs@hotmail.com>  wrote:
>
>> I don't think problem is mapping correct page from Action class. If you
>> look into my initial code posting /changepassword need form validation so
>> it calls the validate() method and since there is no data it fails. I have
>> input="changePasswordPage" which takes to the tile where it look for the
>> session variable.
>> My problem I don't a mechanism where if some one POST the empty data
>> validation fail must lead to not login message or invalid access message.
>> How can I make such distinction from normal form submission?
>>
> You don't *need* to make that distinction, although you *may*.
>
> You still have the same options as before:
>
> 1. A userInfo object in session, or
> 2. Don't read userInfo properties if it's *not* in session.
>
> For (1), you *could* just keep a dummy/default "not-logged-in" userInfo in
> session, and replace it with a real on on login (and go back to the
> dummy/default one on logout). This is sort-of a NullObject pattern
> implementation, except that it represents a dummy/default user.
>
> For (2), you can use conditional logic around property access.
>
> Or just don't go to any pages that require a userInfo, likely by
> redirecting to a login page on "protected" pages. That could be handled by
> a filter, a custom request processor, etc.
>
> It seems like you're over-thinking this instead of just using any of the
> suggestions already provided or coming up with something better--this is a
> straight-forward problem, with relatively straight-forward solution.
>
> Dave
>




---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


Mime
View raw message