Form data vs request attributes
I've been fiddling around with Struts for a while now and am still a little puzzled as to whether JSPs should be getting their data from my DynaActionForm or from the session/request context. For example, if my JSP contains: html:select property=selectedCustomer size=5 html:options collection=customers property=id/ /html:select html:text property=suburb size=16 maxlength=18/ The way I have this working currently is by adding customers to the request context and by having suburb declared in my DynaActionForm. I don't appear to have to declare customers in the form, but if I don't declare suburb, I get an error... what is the difference? P.S. If it helps clarify things, the JSP I have displays a list of customers and some input fields. The user can update the input fields, press submit and they see the same page (with the new details displayed in the list). Many thanks. -- Craig Edwards Sydney, Australia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Form data vs request attributes
In article [EMAIL PROTECTED], [EMAIL PROTECTED] says... The options of a SELECT control are only used to help the user choose a value; its only purpose is to give the SELECT control a value and isn't itself a value of the form. Think of it this way: the form doesn't lose any data by changing your SELECT into an INPUT type=text. Confused? Think of it another way: The OPTION values don't get submitted, only the value of the SELECT. Ahh, that make sense. Thanks. A followup question if I can... The ActionMapping that my XXXAction returns forwards to the same XXX.jsp that was used as the original input for XXXAction. I have noticed that, in XXXAction, if I change the value of one of the ActionForm variables, the JSP will plug the new value into the INPUT when it serves it back to the user. That's sort of neat, but it makes me wonder what will happen if an ActionMapping from another unrelated Action forwards to XXX.jsp. The other action may well have setup the customers variable in the context, but it is unlikely that it will have the same form as XXXAction. What happens in this case? Thanks again. -- Craig Edwards Sydney, Australia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirecting after logon...
In article [EMAIL PROTECTED], [EMAIL PROTECTED] says... As long as you have users that have passwords, and that might be in zero or more roles, it should be relatively easy to write a realm implementation that would access your custom user information repository. That would allow you to make use of the J2EE container managed security system, which solves your problem about keeping POSTed request parameters across a login event. If there is any way this would work, it seems likely to be the best (least work, most rubust, has some positive side effects) way to go. It does sound like the right way to go... however, I have two reservations: 1. As I understand it, have to have hard coded role names in the web.xml file. For example: auth-constraint role-name/role-name /auth-constraint This means that anytime I create new roles, I have to update two places. Given that I probably won't be doing that too often, that may not be a problem. 2. I am only just learning Struts and the notion of writing a Realm implementation would be yet another thing I have to come to grips with before being able to build application functionality. I'm wary of overengineering at this tender stage... Having said all that, in trying to describe my problem I think I can clarify it by saying: - If a user requests a private page, the framework should authenticate them and then redirect them to the private page. - If a user requests a page for which they are not authorized, they will be redirected to a static not authorized page. Perhaps I can create one J2EE role called LOGGEDON and use container managed security to handle the redirection. This way, I can use J2EE to deal with *authentication*, but I can still manage *authorisation* within my Action framework. Maybe... -- Craig Edwards Sydney, Australia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Redirecting after logon...
Some of my pages need the user to be logged on before they can be viewed, so I have cobbled together some simple behaviour in my Action superclass that forwards them to a logon page. Now, I need to send them back to where they were originally trying to go before I redirected them to logon. I have a couple of questions banging around in my head: 1. Should this redirection be performed by my RequestProcessor class or by my Action superclass? 2. After they have logged on (in LogonAction), I need to return an ActionForward object that takes them back to where they were trying to go originally before I forced them to logon. However, I don't know how to construct an ActionForward that contains everything it needs (for example, what if their original request was a POST containing FORM data, or was a URL like /action/blah?id=123a=bc=d... I want to preserve and forward this info.) 3. I would have thought that nearly every web app would need this behaviour, but both my struts textbooks give mickey-mouse examples, and I can't find anything on the web that looks remotely like a real-world example. Does anyone know of any real examples or advice that they would care to share? Many thanks... -- Craig Edwards Sydney, Australia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirecting after logon...
In article [EMAIL PROTECTED], [EMAIL PROTECTED] says... You could do that... or you could do it the J2EE way, decleratively without any coding, letting container do it that way: Thanks for the reply Vic. I can see how that would be the way to go if I were starting from scratch. Unfortunately, I am using a framework that has its own repository for users/roles and I don't think I will be able to coerce it into operating within the J2EE Realm/LoginConfig model. Assuming that I have to build my own infrastructure to handle this, do you have any more thoughts? I already have code that recognizes the user isn't logged on and redirects them to logon... I am just missing the step that sends back to where they were originally going. Thanks again for the feedback. -- Craig Edwards Sydney, Australia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
