Is FormBean mandatory???
Hi Action class interacts with a model,where business logic resides.In my project i have designed the model in such a way that there is mapping of a table with a Value Object.So the Value Object will have a setter getter methods.(for eg. if there are 5 columns in a table,then Value object will have 5 setter getter methods ). In action class i call some business methods which returns Value Object .Then i put the Value Object in the session and retrieve the same in jsp page with the help of iterate tag. In this scenario if i donot use form bean,then also i will be able to proceed in my jsp page. Could anyone explain the pros cons of not using form beans in my project and are there any performance issues in this context?? Thanks Regards, Sachin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Default content for template:get tag
Have you check Tiles capabilities ? Tiles are considered as extended template
framework.
Tiles provide an extension mechanism allowing default values specification.
Cedric
Adam P. Jenkins wrote:
I added the ability to specifiy default content for the template:get tag.
This content is output by the get tag only if there is no corresponding
template:put tag in the inserting page. I did this by making it so
template:get accepts a content attribute and direct attribute, and can
also have a body. These have the same meaning as for the template:put tag,
except that they are only evaluated if there is no content with the given
name on the ContentMapStack. Here is an example of the usage:
!-- template.jsp --
%@ page language=java %
%@ taglib uri=/WEB-INF/struts-template.tld prefix=template %
template:get name=title content=Default Title direct=true/
template:get name=body
This is the default page body
/template:get
!-- page.jsp --
%@ page language=java %
%@ taglib uri=/WEB-INF/struts-template.tld prefix=template %
template:insert template=template.jsp
template:put name=title content=Page Title direct=true/
!-- I don't specify a body, so default will be used. --
/template:insert
In the above example, page.jsp inserts template.jsp, and only specifiies a
title. So in template.jsp, template:get name=title will output the title
given in page.jsp, but template:get name=body will use the default body
specified in template.jsp.
My motivation for adding this is that often when I write templates, I want to
make them very configurable. But often there are sensible defaults for most
of the parameters. It makes the templates much more useful if when I insert
them, I only need to specify values where I want to override the defaults.
I had to modify two files to add this:
src/share/org/apache/struts/taglib/template/GetTag.java
doc/userGuide/struts-template.xml
Here are the patches.
Index: struts-template.xml
===
RCS file: /home/cvspublic/jakarta-struts/doc/userGuide/struts-template.xml,v
retrieving revision 1.1
diff -u -r1.1 struts-template.xml
--- struts-template.xml 20 Feb 2002 00:41:14 - 1.1
+++ struts-template.xml 6 Apr 2002 16:51:01 -
@@ -117,7 +117,7 @@
put tag.
/summary
tagclassorg.apache.struts.taglib.template.GetTag/tagclass
-bodycontentempty/bodycontent
+bodycontentJSP/bodycontent
info
Retrieve content from request scope and include it.
/info
@@ -154,6 +154,26 @@
/info
/attribute
+attribute
+ namecontent/name
+ requiredfalse/required
+ rtexprvaluetrue/rtexprvalue
+ info
+ Content that's put into request scope if there is no
+ corresponding put element.
+ /info
+/attribute
+
+attribute
+ namedirect/name
+ requiredfalse/required
+ rtexprvaluetrue/rtexprvalue
+ info
+ Determines how content is handled: true means content is
+ printed idirect/ily; false, the default, means content
+ is included.
+ /info
+/attribute
/tag
Index: GetTag.java
===
RCS file:
/home/cvspublic/jakarta-struts/src/share/org/apache/struts/taglib/template/GetTag.java,v
retrieving revision 1.12
diff -u -r1.12 GetTag.java
--- GetTag.java 12 Mar 2002 05:55:08 - 1.12
+++ GetTag.java 6 Apr 2002 16:52:19 -
@@ -67,6 +67,7 @@
import javax.servlet.http.HttpServletRequest;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.PageContext;
+import javax.servlet.jsp.tagext.BodyTagSupport;
import javax.servlet.jsp.tagext.TagSupport;
import org.apache.struts.action.Action;
import org.apache.struts.taglib.template.util.*;
@@ -79,7 +80,7 @@
* @author David Geary
* @version $Revision: 1.12 $ $Date: 2002/03/12 05:55:08 $
*/
-public class GetTag extends TagSupport {
+public class GetTag extends BodyTagSupport {
// - Instance Variables
@@ -101,6 +102,18 @@
private String role;
/**
+ * The default content's URI (or text).
+ */
+ private String content = null;
+
+
+ /**
+ * Determines whether content is included (false) or printed (true).
+ * Content is included (false) by default.
+ */
+ private String direct = null;
+
+ /**
* Set the flush-before-include property
* @param flush The new flush property
*/
@@ -131,6 +144,27 @@
}
/**
+ * Set the content's URI (if it's to be included) or text (if it's to
+ * be printed).
+ */
+ public void setContent(String content) {
+
+ this.content = content;
+
+ }
+
+
+ /**
+ * Set direct to true, and content will be printed directly, instead
+ * of included (direct == false).
+ */
+ public void
Re: Servlet 2.3 filter
- Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, April 08, 2002 9:21 AM Subject: Re: Servlet 2.3 filter On Sun, 7 Apr 2002, Martin Cooper wrote: Date: Sun, 7 Apr 2002 21:34:37 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Servlet 2.3 filter [snip] I attended Kevin's session, and chatted with him afterwards. The model he described is one where the request URL points directly to the JSP page itself, and the controller does the preparation necessary to display that page. However, this model really only works for simple applications. One example in which this breaks is where some action needs to be taken in addition to displaying the JSP page, and there is no one-to-one relationship between the action and the page. (In Struts-land, this is the equivalent of having multiple actions which may forward to the same JSP page.) ducking-for-cover In other words, Kevin pitched a Model 1 design with the business logic in a filter instead of inside the page? :-) /ducking-for-cover Yup, I guess that's actually a pretty good way of summarising it, although I'm sure he wouldn't be too happy with that description... ;-) -- Martin Cooper Kevin realises now that this is a problem with the approach he presented. I'm sure he'll be giving it more thought, though. ;-) -- Martin Cooper Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Struts menu
Hi All, I was wondering if there are any plans add the following to the Struts menu: -Support for roles -Support for locales (might already be their can't see how to use however) -Support for struts-config forwards. Jon Ridgway www.upco.co.uk -Original Message- From: Vaddiyar, Raghuramudu [mailto:[EMAIL PROTECTED]] Sent: 08 April 2002 11:49 To: 'Struts Users Mailing List' Subject: RE: conditional iterate (3) Better avoid array elements with same compname ... in otherwords create the array elements with unique compname ..avoid elements with same compname... -Original Message- From: Peter Cnops [mailto:[EMAIL PROTECTED]] Sent: Monday, April 08, 2002 12:00 PM To: [EMAIL PROTECTED] Subject: conditional iterate (3) Hi, I made a typo in my request (closing the bean tag), but thas is not the main problem. What I want to do is: 1. iterate through some orderlines 2. if 'compname' of this orderline is not equal to 'compname' of the previous orderline, write the compname, else do not. How do I realise this? Do I have to declare a variable? logic:iterate id=element name=orderlinebean type=com.test.Orderline logic:notEqual name=element property=compname value=--if the compname is the same as the previous line, don't write, else write the compname tr td width=23%nbsp;/td td width=18%bean:write name=element property=compname//td td width=59%bean:write name=element property=number//td /tr /logic:notEqual /logic:iterate Peter Cnops Project Management - MediaTower Digital Photography - PrePress - Digital Printing - Internet Services Veldkant 29, B-2550 Kontich Tel. 03 450 81 00 - Fax 03 450 81 09 http://www.mediatower.be -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] The content of this e-mail is intended only for the confidential use of the person addressed. If you have received this message in error, please notify us immediately by electronic mail, by telephone or by fax at the above num- bers. E-mail communications are not secure and therefore we do not accept any res- ponsibility for the confidentiality or altered contents of this message. Please be aware that SIS Group and its subsidiary companies cannot accept any orders or other legally binding correspondence with a participant as part of an E-mail. The views expressed above are not necessarily those held by SIS Group and its subsidiary companies and not binding for them. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: TR: Multi Device application with STRUTS
Hy, First, I move this thread to struts-user. You can check Tiles capabilities to have different channels. In your case, a channel correspond to a targeted device. This Tiles capability is an attempt to provide an answer to the multi-device problem. You use the same actions for all channels, and different views implementation for each. The struts-config file contains action declarations declaring forwards to logical views. Tiles select appropriate views according to your own criteria (here the device type). The tiles mechanism works in the same way that Java i18n properties work : you have one declaration file for each device, each one declaring tiles definitions for the device. Check the i18n Tiles capabilities, and the multi-channel example coming with Tiles. It should be easy to adapt it to device switching. Hope this help, Cedric Manuel Vilar wrote: Hello, First : I am a French developper, so I apologize for my poor English ! Our society decided to use STRUTS because of its MVC approach ! Our applications have to be accessed by differents customers devices. Each customer device supports different languages ( html, vdxml, WML, etc...) Whats on ? STRUTS having not intrisinc customer device notion, we are thinking about two ways for making STRUTS have a customer device notion. Method 1 : Upgrading ourself STRUTS to implement a device detection ( This info could be retrieved in the fisrt customer header request ). This approach would mean that all the specific device code ( Views, Forms,... ) should be selected automaticly by forwards functions, and generally by all the STRUTS functions expecting a parameter like path=example.jsp or any page indication parameter input=MyForm in the case of an input action). Example : The first application page is index.jsp In struts-config.xml we define this action : !-- Display the welcome page -- actionpath=/welcome forward=/welcome.jsp /action There is no welcome.jsp but two pages named respectivly welcome_A.jsp and contains html code, and welcome_B.jsp which contains WML code. A Customer Device accept html ( Netscape browser ) B Customer Device accept wml ( WAP ) The index.jsp which is the common page could detect customer device and sets the Device Value to A or B. index.jsp contains a link wich page=welcome.do So we start ! When the customer selects the link welcome.do, STRUTS action called forward could return welcome_A.jsp, assuming current device is A. We are here speaking of suffixed pages with A and B. We could use the same pages names but in different directories like that : A/welcome.jsp for A Device ( html ) B/welcome.jsp for B Device.( WML ) Method 2 : Making two applications, the fisrt for A Customer Devices and the second for B Customer Devices, and force them to share ( if we can do so ! ) the ressources that are not Device specific. Questions : Am I Wrong ? ( because none of these methods should be applied or there is a simple way ) Best way ? Thank you all for your answers, Manuel Vilar, -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VelTools]
I am really sorry. My mail went to the wrong list. Gabe Gabriel Sidler wrote: Based on all the feedback and discussions of the last few days I noted the following To Dos and plan to address them this week. - Change initialization of tools to the init()/destroy() approach. = code contribution by Nathan - Change handling of tool life cycle (scope). New it will be determined entirly through the toolbox configuration. Remove everthing related to life cycle from the interfaces and existing tools. - Allow static values of classes String, Integer, etc in toolbox, similar to what the DVSL toolbox currently supports. - Redesign ToolLoader tool based on Nathan's proposal. - VVS: Remove parameter VELOCITY_PROPERTIES - Add respone object to ViewContext and ChainedContext - Add proper URL encoding in LinkTool (requires response object) - Rename directory 'tools' to directory 'library' - Test and upgrade existing example in view directory - Resolve some of the remarked, unlucky naming (if I can come up with a better name...) - Fix absolute path in site.dvsl - Update documentation Not yet addressed are: - How to deal with multi-scope tools Gabe -- Gabriel Sidler Software Engineer, Eivycom GmbH, Zurich, Switzerland -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] . -- -- Gabriel Sidler Software Engineer, Eivycom GmbH, Zurich, Switzerland -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Navigation Bar
Girish Patel [EMAIL PROTECTED] wrote on 09/04/2002 10:59:38 PM: Is there any tag to generate Navigation Bar, Glossary list, FAQ's etc thanks There's a whole project: http://jakarta.apache.org/turbine/maven -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au Developers: http://adslgateway.multitask.com.au/developers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: TR: Multi Device application with STRUTS
Hello Cedric ! Oooops, I haven't yet red tiles functionnnalities, but it really seems that with tiles I could find what I was brain storming for ! Thanks again...( Shame on me !) Manuel Vilar Service developpement 01 45 15 03 32 -Message d'origine- De : Cedric Dumoulin [mailto:[EMAIL PROTECTED]] Envoyé : mardi 9 avril 2002 10:27 À : [EMAIL PROTECTED] Cc : Struts Developers List Objet : Re: TR: Multi Device application with STRUTS Hy, First, I move this thread to struts-user. You can check Tiles capabilities to have different channels. In your case, a channel correspond to a targeted device. This Tiles capability is an attempt to provide an answer to the multi-device problem. You use the same actions for all channels, and different views implementation for each. The struts-config file contains action declarations declaring forwards to logical views. Tiles select appropriate views according to your own criteria (here the device type). The tiles mechanism works in the same way that Java i18n properties work : you have one declaration file for each device, each one declaring tiles definitions for the device. Check the i18n Tiles capabilities, and the multi-channel example coming with Tiles. It should be easy to adapt it to device switching. Hope this help, Cedric Manuel Vilar wrote: Hello, First : I am a French developper, so I apologize for my poor English ! Our society decided to use STRUTS because of it's MVC approach ! Our applications have to be accessed by differents customers devices. Each customer device supports different languages ( html, vdxml, WML, etc...) What's on ? STRUTS having not intrisinc customer device notion, we are thinking about two ways for making STRUTS have a customer device notion. Method 1 : Upgrading ourself STRUTS to implement a device detection ( This info could be retrieved in the fisrt customer header request ). This approach would mean that all the specific device code ( Views, Forms,... ) should be selected automaticly by forwards functions, and generally by all the STRUTS functions expecting a parameter like path=example.jsp or any page indication parameter input=MyForm in the case of an input action). Example : The first application page is index.jsp In struts-config.xml we define this action : !-- Display the welcome page -- actionpath=/welcome forward=/welcome.jsp /action There is no welcome.jsp but two pages named respectivly welcome_A.jsp and contains html code, and welcome_B.jsp which contains WML code. A Customer Device accept html ( Netscape browser ) B Customer Device accept wml ( WAP ) The index.jsp which is the common page could detect customer device and sets the Device Value to A or B. index.jsp contains a link wich page=welcome.do So we start ! When the customer selects the link welcome.do, STRUTS action called forward could return welcome_A.jsp, assuming current device is A. We are here speaking of suffixed pages with A and B. We could use the same pages names but in different directories like that : A/welcome.jsp for A Device ( html ) B/welcome.jsp for B Device.( WML ) Method 2 : Making two applications, the fisrt for A Customer Devices and the second for B Customer Devices, and force them to share ( if we can do so ! ) the ressources that are not Device specific. Questions : Am I Wrong ? ( because none of these methods should be applied or there is a simple way ) Best way ? Thank you all for your answers, Manuel Vilar, -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Is FormBean mandatory???
Web forms can only handle Strings and booleans - so if your value objects have Dates or Integers, get ready for some fun! -Original Message- From: Sachin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 1:47 AM To: [EMAIL PROTECTED] Subject: Is FormBean mandatory??? Hi Action class interacts with a model,where business logic resides.In my project i have designed the model in such a way that there is mapping of a table with a Value Object.So the Value Object will have a setter getter methods.(for eg. if there are 5 columns in a table,then Value object will have 5 setter getter methods ). In action class i call some business methods which returns Value Object .Then i put the Value Object in the session and retrieve the same in jsp page with the help of iterate tag. In this scenario if i donot use form bean,then also i will be able to proceed in my jsp page. Could anyone explain the pros cons of not using form beans in my project and are there any performance issues in this context?? Thanks Regards, Sachin -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Servlet 2.3 filter
Please pardon me for replying to this message in an incorrect manner (if in fact I do) it is my first forray into your community. I'm not sure I see how Kevin was suggesting a model 1 architecture. Model 1 as I understand it, would suggest that a request is made from a browser to a jsp that in turn might instantiate some kind of bean that would access database resources (for example) directly. In an earlier comment in this thread Craig mentioned the fact that using filters the request can be made to a resource that doesn't even exist. In other words the request could be made to a logical name (e.g. displayUser) rather than to a physical name (e.g. DisplayUser.jsp). Filters could be defined that would intercept the request for the logical name displayUser performing business logic in filter1 while generating a response in filter2. In this case it seems to me that the declarative nature of filters are in fact allowing for the configurating of controlling logic prior to the generation of a response. Steve Monday Martin Cooper martin.cooper@tumbl eweed.com 04/09/2002 12:07 AM Please respond toTo: Struts Developers List [EMAIL PROTECTED] Struts Developers cc: List Subject: Re: Servlet 2.3 filter Caterpillar: Confidential Green Retain Until: 05/09/2002 Retention Category: G90 - Information and Reports - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, April 08, 2002 9:21 AM Subject: Re: Servlet 2.3 filter On Sun, 7 Apr 2002, Martin Cooper wrote: Date: Sun, 7 Apr 2002 21:34:37 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Servlet 2.3 filter [snip] I attended Kevin's session, and chatted with him afterwards. The model he described is one where the request URL points directly to the JSP page itself, and the controller does the preparation necessary to display that page. However, this model really only works for simple applications. One example in which this breaks is where some action needs to be taken in addition to displaying the JSP page, and there is no one-to-one relationship between the action and the page. (In Struts-land, this is the equivalent of having multiple actions which may forward to the same JSP page.) ducking-for-cover In other words, Kevin pitched a Model 1 design with the business logic in a filter instead of inside the page? :-) /ducking-for-cover Yup, I guess that's actually a pretty good way of summarising it, although I'm sure he wouldn't be too happy with that description... ;-) -- Martin Cooper Kevin realises now that this is a problem with the approach he presented. I'm sure he'll be giving it more thought, though. ;-) -- Martin Cooper Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Is FormBean mandatory???
--- Matt Raible [EMAIL PROTECTED] wrote: Web forms can only handle Strings and booleans - so if your value objects have Dates or Integers, get ready for some fun! Integers are completely OK, floats depend on sanity of web users. ( imagine some bank clerk who is used to enter dots to separate 000... ) IMHO, struts shall behave more beany/reflection- with possibility to set property editors for a bean. ( now I'm doing blasphemy: like webwork does :) ) regards, = Konstantin Priblouda ( ko5tik )Freelance Software developer http://www.pribluda.de play java games - http://www.yook.de render charts online - http://www.pribluda.de/povray/ __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Is FormBean mandatory???
On Tue, 9 Apr 2002, Konstantin Priblouda wrote: Date: Tue, 9 Apr 2002 08:15:03 -0700 (PDT) From: Konstantin Priblouda [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? --- Matt Raible [EMAIL PROTECTED] wrote: Web forms can only handle Strings and booleans - so if your value objects have Dates or Integers, get ready for some fun! Integers are completely OK, floats depend on sanity of web users. ( imagine some bank clerk who is used to enter dots to separate 000... ) Using int or Integer properties in a form bean misses the whole reason for its existence -- to reproduce the user's input in case they made a mistake. Consider that you've got an input field called size, which (in your business logic should really be an integer). Assume for a moment that you try to use an int or Integer property in the form bean, so that the conversion happens as the form bean properties get populated. Now, assume that the user mis-types 1a3 instead of 123 into this field. Using an int field, you get an ugly exception when the form bean properties are populated -- and any properties that haven't been populated yet have errors. Using a String field, you get the ability to validate the input, produce a nice error message, and (most importantly to meet users expectations) redisplay the input field with the incorrect value that he or she did enter, so that they can fix it. Any user who has ever used a GUI app is going to expect this behavior in a web app. The form bean is part of the VIEW layer in an MVC architecture, not the MODEL layer. It's sole purpose in life is to represent the server-side state of the last set of inputs to a particular form (even if they are not valid). Conversion into value objects (or directly to the database, depending on how you have your business logic set up) should be done by a save type action, after the form fields have been validated. IMHO, struts shall behave more beany/reflection- with possibility to set property editors for a bean. ( now I'm doing blasphemy: like webwork does :) ) It turns out that property editors have technical problems that have been discussed before (check the mail archives for details). However, you should check out the recent changes to ConvertUtils in the commons-beanutils package), which let you plug in your own String-Object converters. This is available in the Struts 1.1 beta, and will also be available in the 1.1 final release. regards, = Konstantin Priblouda ( ko5tik )Freelance Software developer http://www.pribluda.de play java games - http://www.yook.de render charts online - http://www.pribluda.de/povray/ Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Is FormBean mandatory???
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 11:38 AM To: Struts Developers List Cc: [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? On Tue, 9 Apr 2002, Konstantin Priblouda wrote: Date: Tue, 9 Apr 2002 08:15:03 -0700 (PDT) From: Konstantin Priblouda [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? --- Matt Raible [EMAIL PROTECTED] wrote: Web forms can only handle Strings and booleans - so if your value objects have Dates or Integers, get ready for some fun! Integers are completely OK, floats depend on sanity of web users. ( imagine some bank clerk who is used to enter dots to separate 000... ) Using int or Integer properties in a form bean misses the whole reason for its existence -- to reproduce the user's input in case they made a mistake. It's still nice that you can use integer properties, though, for things like select fields and radio buttons...anything that doesn't allow free-form text input. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Is FormBean mandatory???
On Tue, 9 Apr 2002, Tim Moore wrote: Date: Tue, 9 Apr 2002 11:56:22 -0400 From: Tim Moore [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 11:38 AM To: Struts Developers List Cc: [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? On Tue, 9 Apr 2002, Konstantin Priblouda wrote: Date: Tue, 9 Apr 2002 08:15:03 -0700 (PDT) From: Konstantin Priblouda [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? --- Matt Raible [EMAIL PROTECTED] wrote: Web forms can only handle Strings and booleans - so if your value objects have Dates or Integers, get ready for some fun! Integers are completely OK, floats depend on sanity of web users. ( imagine some bank clerk who is used to enter dots to separate 000... ) Using int or Integer properties in a form bean misses the whole reason for its existence -- to reproduce the user's input in case they made a mistake. It's still nice that you can use integer properties, though, for things like select fields and radio buttons...anything that doesn't allow free-form text input. How do *you* know that your Struts client is actually a browser (and therefore using the SELECT box to control the input value that is sent)? It could be a program that is submitting HTTP requests to trigger transactions in your webapp. :-) I take your point that this is a valid assumption in many controlled environments, but certainly not universally. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Is FormBean mandatory???
On Tue, 9 Apr 2002, Tim Moore wrote: It's still nice that you can use integer properties, though, for things like select fields and radio buttons...anything that doesn't allow free-form text input. How do *you* know that your Struts client is actually a browser (and therefore using the SELECT box to control the input value that is sent)? It could be a program that is submitting HTTP requests to trigger transactions in your webapp. :-) Then I'm not concerned about it throwing an exception if I get a garbage value, or maintaining the garbage value for the response. I still do bounds checking of course if that's necessary...it's just nice to have the String to int conversion happen implicitly. Same with booleans and checkboxes. Now I guess if I decide to change my form to use a text input instead of a drop-down, then I have to go back and change the form bean and action. But most of the time, that's not even a remote possibility--like if you're choosing an item from a list and it's sending the primary key back when you submit. In general, though, I don't usually bother making pretty error messages for the types of errors that could have only originated from a buggy or malicious client request; I just throw an exception. Presumably the response isn't going to be displayed directly to the user anyway if they're using a GUI client or something like that. Is there any other reason to use only String properties in that case? Using int properties for a case like this is a very reasonable pragmatic decision. My primary concern is all the people who try to use a form bean as a value object -- that approach is just going to get you in to trouble. -- Tim Moore / Blackboard Inc. / Software Engineer Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Declaritive Security Functionality
I have implemented struts in some projects and have found a need for doing declarative security. Much like your role-based security, I would like to define the security in the struts config xml file, but I am looking at taking a step further. I would appreciate any advice or pointers. This will be my first time getting deep into the Struts source code. The problem I am trying to get a good solution for is redundant code checking conditions at the beginning of each action. If the user doesn't pass all the conditions then they are rejected from the page. The rejection would be configurable to either show as a page not found or would forward/redirect them to a specified page. Here is what I was thinking that the struts config file might look like. security-checker name=roleCheck class=com.schehl.security.IsUserInRole / action path=/showMain type=com.schehl.main.webapp.MainAction securityname=roleCheck param param-nameallow-roles/param-name param-valueadmin/parm-value /param param param-nameallow-users/param-name param-valueadmin/parm-value /param failurepath=/pages/no-access.jsp/ !-- failureresponse=no page / -- /security forward name=success path=/pages/main.jsp / /action The class com.schehl.security.IsUserInRole would extend a class, com.strutssecurity.SecurityChecker, which would be responsible for setting the configuration parameters and would have a method boolean check(HttpRequest request) which would default to pass back true, but would be overridden to perform the checks. I thank you so much for any and all help, advice, or redirection you can give me. Thanks, Micah J. Schehl
Re: Is FormBean mandatory???
Why is there a need for seperate FormBean object in the View? Couldn't you just use a generic bean that could hold your application-specific validation logic and be shared between your view and model? Then, you could repopulate the form directly from the request. One problem I see with this is that the names of your form fields and the fields in other parts of your application (i.e. the model) are coupled. This is a small sacrifice for the automation you get though and most likely the case for many applications already. Second, you lose field-specific filtering. This isn't such a big deal because you really just need to filter out characters that would interfere with your HTML redisplaying properly anyway which will be the same for every field. Lastly, there's the validation. You could go two directions on this one. One, you could have a method built into your domain/value object to perform the validation. Struts would handle the String - Number, etc. conversions automatically returning appropriate error messages. Then, it would call your validation method and append those error messages (the automatic validations would supercede the manual ones). Admittedly this could get a bit tricky, but it may be better than doing this manually. Or two, the Struts user could implement a FormValidator that would work against a generic value Map interface (in HTTP requests, this would be backed by the HTTPRequest object). You could argue that you lose compile time type checking in this case, but is it really that valuable in the current incarnation? Thanks, Bob - Original Message - From: Tim Moore [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, April 09, 2002 11:59 AM Subject: RE: Is FormBean mandatory??? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 12:10 PM To: Struts Developers List Subject: RE: Is FormBean mandatory??? On Tue, 9 Apr 2002, Tim Moore wrote: Date: Tue, 9 Apr 2002 11:56:22 -0400 From: Tim Moore [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 11:38 AM To: Struts Developers List Cc: [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? On Tue, 9 Apr 2002, Konstantin Priblouda wrote: Date: Tue, 9 Apr 2002 08:15:03 -0700 (PDT) From: Konstantin Priblouda [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? --- Matt Raible [EMAIL PROTECTED] wrote: Web forms can only handle Strings and booleans - so if your value objects have Dates or Integers, get ready for some fun! Integers are completely OK, floats depend on sanity of web users. ( imagine some bank clerk who is used to enter dots to separate 000... ) Using int or Integer properties in a form bean misses the whole reason for its existence -- to reproduce the user's input in case they made a mistake. It's still nice that you can use integer properties, though, for things like select fields and radio buttons...anything that doesn't allow free-form text input. How do *you* know that your Struts client is actually a browser (and therefore using the SELECT box to control the input value that is sent)? It could be a program that is submitting HTTP requests to trigger transactions in your webapp. :-) Then I'm not concerned about it throwing an exception if I get a garbage value, or maintaining the garbage value for the response. I still do bounds checking of course if that's necessary...it's just nice to have the String to int conversion happen implicitly. Same with booleans and checkboxes. Now I guess if I decide to change my form to use a text input instead of a drop-down, then I have to go back and change the form bean and action. But most of the time, that's not even a remote possibility--like if you're choosing an item from a list and it's sending the primary key back when you submit. In general, though, I don't usually bother making pretty error messages for the types of errors that could have only originated from a buggy or malicious client request; I just throw an exception. Presumably the response isn't going to be displayed directly to the user anyway if they're using a GUI client or something like that. Is there any other reason to use only String properties in that case? -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe,
Re: Is FormBean mandatory???
I think I may need to elaborate before I get flamed. I do *not* suggest coupling your presentation layer and middle tier with a single value object, as it is often the case that your middle tier objects loosely correspond to the data submitted in your form if at all; if they are a lot alike, your application probably isn't doing much. I am simply asking why using a separate FormBean is the best solution. It seems like an awful lot of work, especially if you are just getting/setting Strings. Bob - Original Message - From: Bob Lee [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, April 09, 2002 1:40 PM Subject: Re: Is FormBean mandatory??? Why is there a need for seperate FormBean object in the View? Couldn't you just use a generic bean that could hold your application-specific validation logic and be shared between your view and model? Then, you could repopulate the form directly from the request. One problem I see with this is that the names of your form fields and the fields in other parts of your application (i.e. the model) are coupled. This is a small sacrifice for the automation you get though and most likely the case for many applications already. Second, you lose field-specific filtering. This isn't such a big deal because you really just need to filter out characters that would interfere with your HTML redisplaying properly anyway which will be the same for every field. Lastly, there's the validation. You could go two directions on this one. One, you could have a method built into your domain/value object to perform the validation. Struts would handle the String - Number, etc. conversions automatically returning appropriate error messages. Then, it would call your validation method and append those error messages (the automatic validations would supercede the manual ones). Admittedly this could get a bit tricky, but it may be better than doing this manually. Or two, the Struts user could implement a FormValidator that would work against a generic value Map interface (in HTTP requests, this would be backed by the HTTPRequest object). You could argue that you lose compile time type checking in this case, but is it really that valuable in the current incarnation? Thanks, Bob - Original Message - From: Tim Moore [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, April 09, 2002 11:59 AM Subject: RE: Is FormBean mandatory??? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 12:10 PM To: Struts Developers List Subject: RE: Is FormBean mandatory??? On Tue, 9 Apr 2002, Tim Moore wrote: Date: Tue, 9 Apr 2002 11:56:22 -0400 From: Tim Moore [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 11:38 AM To: Struts Developers List Cc: [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? On Tue, 9 Apr 2002, Konstantin Priblouda wrote: Date: Tue, 9 Apr 2002 08:15:03 -0700 (PDT) From: Konstantin Priblouda [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? --- Matt Raible [EMAIL PROTECTED] wrote: Web forms can only handle Strings and booleans - so if your value objects have Dates or Integers, get ready for some fun! Integers are completely OK, floats depend on sanity of web users. ( imagine some bank clerk who is used to enter dots to separate 000... ) Using int or Integer properties in a form bean misses the whole reason for its existence -- to reproduce the user's input in case they made a mistake. It's still nice that you can use integer properties, though, for things like select fields and radio buttons...anything that doesn't allow free-form text input. How do *you* know that your Struts client is actually a browser (and therefore using the SELECT box to control the input value that is sent)? It could be a program that is submitting HTTP requests to trigger transactions in your webapp. :-) Then I'm not concerned about it throwing an exception if I get a garbage value, or maintaining the garbage value for the response. I still do bounds checking of course if that's necessary...it's just nice to have the String to int conversion happen implicitly. Same with booleans and checkboxes. Now I guess if I decide to change my form to use a text input instead of a drop-down, then I have to go back and change the form bean and action. But most of the time, that's not even a remote possibility--like
RE: Is FormBean mandatory???
A lot of work to write the bean? Or to synch the values with your business layer? I think both of these are going to get a lot easier as development continues. We already have the DynaFormBean now, helping the former, and with the pluggable ConvertUtils the latter has gotten easier too. Hopefully we'll see a more flexible mapping package soon enough, and eventually get to a point where all of the validation and conversion logic can be specified declaritively. From my experience using Struts I think that keeping the form state as a separate class is definitely the right approach. I just think that there are still some cracks in the framework that could use some filling in to make the whole thing more seamless...I'm sure it will get there eventually. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW / 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Bob Lee [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 2:54 PM To: Struts Developers List Subject: Re: Is FormBean mandatory??? I think I may need to elaborate before I get flamed. I do *not* suggest coupling your presentation layer and middle tier with a single value object, as it is often the case that your middle tier objects loosely correspond to the data submitted in your form if at all; if they are a lot alike, your application probably isn't doing much. I am simply asking why using a separate FormBean is the best solution. It seems like an awful lot of work, especially if you are just getting/setting Strings. Bob - Original Message - From: Bob Lee [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, April 09, 2002 1:40 PM Subject: Re: Is FormBean mandatory??? Why is there a need for seperate FormBean object in the View? Couldn't you just use a generic bean that could hold your application-specific validation logic and be shared between your view and model? Then, you could repopulate the form directly from the request. One problem I see with this is that the names of your form fields and the fields in other parts of your application (i.e. the model) are coupled. This is a small sacrifice for the automation you get though and most likely the case for many applications already. Second, you lose field-specific filtering. This isn't such a big deal because you really just need to filter out characters that would interfere with your HTML redisplaying properly anyway which will be the same for every field. Lastly, there's the validation. You could go two directions on this one. One, you could have a method built into your domain/value object to perform the validation. Struts would handle the String - Number, etc. conversions automatically returning appropriate error messages. Then, it would call your validation method and append those error messages (the automatic validations would supercede the manual ones). Admittedly this could get a bit tricky, but it may be better than doing this manually. Or two, the Struts user could implement a FormValidator that would work against a generic value Map interface (in HTTP requests, this would be backed by the HTTPRequest object). You could argue that you lose compile time type checking in this case, but is it really that valuable in the current incarnation? Thanks, Bob - Original Message - From: Tim Moore [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, April 09, 2002 11:59 AM Subject: RE: Is FormBean mandatory??? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 12:10 PM To: Struts Developers List Subject: RE: Is FormBean mandatory??? On Tue, 9 Apr 2002, Tim Moore wrote: Date: Tue, 9 Apr 2002 11:56:22 -0400 From: Tim Moore [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 11:38 AM To: Struts Developers List Cc: [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? On Tue, 9 Apr 2002, Konstantin Priblouda wrote: Date: Tue, 9 Apr 2002 08:15:03 -0700 (PDT) From: Konstantin Priblouda [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: RE: Is FormBean mandatory??? --- Matt Raible [EMAIL PROTECTED] wrote: Web forms can only handle Strings and booleans - so if your value objects have Dates or Integers, get ready for some fun! Integers are
Re: Declaritive Security Functionality
Brandon, Your project sounds like it could be useful. I am using iPlanet webserver, which is Servlet 2.2 compliant but does implement the Filters for Servlet 2.3. (see below) I read through the mail archives, and hopefully I read everything to date. I had once looked at programmatically telling the webserver container to log the user in. I couldn't find any way of doing that through a servlet spec compliant interface. So I decided to implement programmatic security, where in each action if the user isn't logged in, then they are redirected to a secured link in the container. The container would then pop up the j_security_check form and the user could log in. I can see using filters as being a great improvement, and I looked into using them before, but I wasn't sure how to implement it elegantly with multiple web-apps and with making it work with an application server. I couldn't figure out how to keep the security configurations seperate for each web-app. Oh, and is your source available yet? I looked for it on sourceforge and didn't find it. Thanks, Micah J. Schehl __References__ From iPlanet Web Server: Programmer's Guide to Servlets: http://docs.iplanet.com/docs/manuals/enterprise/50/servlets/war.htm Although iPlanet Web Server 6.0 supports only the Servlet 2.2 API in the web.xml file, the Filter API from the Servlet 2.3 specification is available in the web-apps.xml file. The filter and filter-mapping elements implement the Filter API. They are both subelements of a web-app element in the web-apps.xml file. Except for their file location, filter and filter-mapping are as described in the Servlet 2.3 specification. - Original Message - From: Phase Web and Multimedia [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, April 09, 2002 2:47 PM Subject: RE: Declaritive Security Functionality This look like it could use a Filter if you are on a 2.3 servlet spec Containter. Do a search of Security Solution and the mail-archive. I am developing a security solution that sits in between struts and container managed security and allows for unique error page and login page configuration. I have a sourceforge project that I am setting up with this. Previously I was looking to replace the container managed security. But, now I have found a hook that will allow me to tie into it. Let me know if you find it useful. Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -Original Message- From: Micah J. Schehl [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 12:30 PM To: [EMAIL PROTECTED] Subject: Declaritive Security Functionality I have implemented struts in some projects and have found a need for doing declarative security. Much like your role-based security, I would like to define the security in the struts config xml file, but I am looking at taking a step further. I would appreciate any advice or pointers. This will be my first time getting deep into the Struts source code. The problem I am trying to get a good solution for is redundant code checking conditions at the beginning of each action. If the user doesn't pass all the conditions then they are rejected from the page. The rejection would be configurable to either show as a page not found or would forward/redirect them to a specified page. Here is what I was thinking that the struts config file might look like. security-checker name=roleCheck class=com.schehl.security.IsUserInRole / action path=/showMain type=com.schehl.main.webapp.MainAction securityname=roleCheck param param-nameallow-roles/param-name param-valueadmin/parm-value /param param param-nameallow-users/param-name param-valueadmin/parm-value /param failurepath=/pages/no-access.jsp/ !-- failureresponse=no page / -- /security forward name=success path=/pages/main.jsp / /action The class com.schehl.security.IsUserInRole would extend a class, com.strutssecurity.SecurityChecker, which would be responsible for setting the configuration parameters and would have a method boolean check(HttpRequest request) which would default to pass back true, but would be overridden to perform the checks. I thank you so much for any and all help, advice, or redirection you can give me. Thanks, Micah J. Schehl -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7892] New: - Using Multiple Resource Bundles for an Application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7892. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7892 Using Multiple Resource Bundles for an Application Summary: Using Multiple Resource Bundles for an Application Product: Struts Version: 1.1 Beta 1 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When using multiple resource bundles for an application, there are some issues that make it tricky to create ActionErrors. Because you can only specifiy the bundle for the ErrorsTag at the collection level, every ActionError object in the collection must come from the same bundle. This is not a huge issue, but limits the natural way an application may choose to setup it's bundles. Wouldn't it be better if you specified the bundle for a key when creating the ActionError object? This would allow you to have messages from various bundles within the ActionErrors collection. Chuck -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Declaritive Security Functionality
I will be making it available on sourceforge this week. I am trying to document it better and clean up some rough edges. I can send it to you how it is but it is only tested on Tomcat 4. good ol alpha quality stuff. Let me know, Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -Original Message- From: Micah J. Schehl [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 2:06 PM To: Struts Developers List Subject: Re: Declaritive Security Functionality Brandon, Your project sounds like it could be useful. I am using iPlanet webserver, which is Servlet 2.2 compliant but does implement the Filters for Servlet 2.3. (see below) I read through the mail archives, and hopefully I read everything to date. I had once looked at programmatically telling the webserver container to log the user in. I couldn't find any way of doing that through a servlet spec compliant interface. So I decided to implement programmatic security, where in each action if the user isn't logged in, then they are redirected to a secured link in the container. The container would then pop up the j_security_check form and the user could log in. I can see using filters as being a great improvement, and I looked into using them before, but I wasn't sure how to implement it elegantly with multiple web-apps and with making it work with an application server. I couldn't figure out how to keep the security configurations seperate for each web-app. Oh, and is your source available yet? I looked for it on sourceforge and didn't find it. Thanks, Micah J. Schehl __References__ From iPlanet Web Server: Programmer's Guide to Servlets: http://docs.iplanet.com/docs/manuals/enterprise/50/servlets/war.htm Although iPlanet Web Server 6.0 supports only the Servlet 2.2 API in the web.xml file, the Filter API from the Servlet 2.3 specification is available in the web-apps.xml file. The filter and filter-mapping elements implement the Filter API. They are both subelements of a web-app element in the web-apps.xml file. Except for their file location, filter and filter-mapping are as described in the Servlet 2.3 specification. - Original Message - From: Phase Web and Multimedia [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, April 09, 2002 2:47 PM Subject: RE: Declaritive Security Functionality This look like it could use a Filter if you are on a 2.3 servlet spec Containter. Do a search of Security Solution and the mail-archive. I am developing a security solution that sits in between struts and container managed security and allows for unique error page and login page configuration. I have a sourceforge project that I am setting up with this. Previously I was looking to replace the container managed security. But, now I have found a hook that will allow me to tie into it. Let me know if you find it useful. Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -Original Message- From: Micah J. Schehl [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 09, 2002 12:30 PM To: [EMAIL PROTECTED] Subject: Declaritive Security Functionality I have implemented struts in some projects and have found a need for doing declarative security. Much like your role-based security, I would like to define the security in the struts config xml file, but I am looking at taking a step further. I would appreciate any advice or pointers. This will be my first time getting deep into the Struts source code. The problem I am trying to get a good solution for is redundant code checking conditions at the beginning of each action. If the user doesn't pass all the conditions then they are rejected from the page. The rejection would be configurable to either show as a page not found or would forward/redirect them to a specified page. Here is what I was thinking that the struts config file might look like. security-checker name=roleCheck class=com.schehl.security.IsUserInRole / action path=/showMain type=com.schehl.main.webapp.MainAction securityname=roleCheck param param-nameallow-roles/param-name param-valueadmin/parm-value /param param param-nameallow-users/param-name param-valueadmin/parm-value /param failurepath=/pages/no-access.jsp/ !-- failureresponse=no page / -- /security forward name=success path=/pages/main.jsp / /action The class com.schehl.security.IsUserInRole would extend a class, com.strutssecurity.SecurityChecker, which would be responsible for setting the configuration parameters and would have a method boolean check(HttpRequest request) which would default to pass back true, but would be overridden to perform the
Security Question getRemoteUser() or getUserPrincipal()
Sorry all I know this isn't a struts question. But I have a security framework that will give more flexiblity to struts and tomcat(+ other containers). I am able to tie it into the container managed security. But, I need a question answered? what is the difference between getRemoteUser() and getUserPrincipal()? From what I can tell getRemoteUser() returns the username in string form and the only method in the Principal class is the getName() which returns the usersname. Why do we have both and if I am doing programmatic security checks which should I use and why? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7902] New: - The exception handling declaration in the DTD doesn't allow you to pick a bundle for the key
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7902. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7902 The exception handling declaration in the DTD doesn't allow you to pick a bundle for the key Summary: The exception handling declaration in the DTD doesn't allow you to pick a bundle for the key Product: Struts Version: 1.1 Beta 1 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In would be a nice feature to allow you to specify which MessageResource bundle the key is from for the exception element. Right now, the messages must all come from the default bundle and this limits the usefulness of multiple bundles. This should be an easy feature to add. Chuck -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is FormBean mandatory???
This logic is essentially correct in that the framework needs to process front end stuff prior to mapping to a view object. However, there are good reasons to not want to have a form bean and a view object and an entity bean. Memory usage -- while frivolous object creation is ok in small to medium sized apps, larger apps can have thousands of view, form combinations and object trees. you really dont want to be instantiating a view from the bean and then a form from the view (even though that may be the purest way to do it currently) Ease of development -- dynaForms make for easy form beans but they dont make for easy mapping from form-validate-view-entity. Also, having to glue all of that together creates as much confusion as the original type 1 infrastructures. Maintainability -- the current mechanism is somewhat clugey at best and results in significant conversion code that has nothing to do with business logic. Design Clarity -- I have spent numerous hours with junior programmers in code reviews dealing with inconsistent transformation strategies, in appropriate amounts of object creation, etc. on relatively simple apps. Interestingly enough it does create something of an opportunity. Using proxies and some basic mapping/templating patterns the form bean could be 'split' to represent a combination of the VIEW and MODEL while maintaining there relationship and consistency using mapping/validation language in the config file. Wouldnt that just be cool. Automate the view-form bean up to a certain point of complexity, and then provide programming hooks for more robust functionality. Basically there is an opportunity to take struts one step further by providing apis for app server integration. Paul - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, April 09, 2002 2:52 PM Subject: Re: Is FormBean mandatory??? On Tue, 9 Apr 2002, Bob Lee wrote: Date: Tue, 9 Apr 2002 13:53:57 -0500 From: Bob Lee [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Is FormBean mandatory??? I think I may need to elaborate before I get flamed. I do *not* suggest coupling your presentation layer and middle tier with a single value object, as it is often the case that your middle tier objects loosely correspond to the data submitted in your form if at all; if they are a lot alike, your application probably isn't doing much. The form bean and value object bean will be similar in the set of properties they expose, simply because the UI in many applications directly mirrors properties in the underlying persistence layer objects. However, they serve different purposes. - The form bean is simply the place on the server side to accumulate the input fields from the screen in an organized way so that you can validate them. You really don't want to start modifying the underlying database information until *after* validation has been successfully completed. Data types (particularly for input fields that are rendered as text boxes) should be strings so that you can redisplay what the user typed if they made a mistake. The only logic in a form bean will typically be the validate() and reset() methods. - The value object is used to either transport the validated properties to the underlying EJB or database layer, and/or to abstract away the details of exactly how persistence is accomplished (so, for example, you could switch from JDBC calls to EJB if needed later). The data types in a value object will typically be the same as the underlying data types stored in the database (int, Timestamp, or whatever). I am simply asking why using a separate FormBean is the best solution. It seems like an awful lot of work, especially if you are just getting/setting Strings. There is a time delay and a feedback loop involved here. Let's see if I can draw it with ASCII art: - Input Form on browser / (redisplayed with previous |data if errors happen) | | | | Submit | v |Form Bean is reset() and |then populated (to deal |correctly with checkboxes) | | | | Validate (if not cancelled) | Error / \ \ Passes | Action Called (goes elsewhere if transaction was cancelled) | | Transfer to | value object | v V.O. sent to the Persistence Layer If you skip the form bean, you have lots of undersireable consequences like updating the value object even when the input data is invalid, not being able to deal correctly with checkboxes, and inability to deal with a Cancel button. If writing form bean classes
DO NOT REPLY [Bug 7890] - Struts html messages tag does not exist
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7890. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7890 Struts html messages tag does not exist [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-04-10 01:53 --- The messages tag and the ActionMessages class are new in Struts 1.1, and are included in Beta 1 and the nightly builds. In this bug report, you marked the Version field as Nightly Build, but the documentation link you provided is for Struts 1.0.x. If you are in fact using Struts 1.0.2 or earlier, you will not be able to use the messages tag or the ActionMessages class. You may want to upgrade to Struts 1.1 Beta 1 instead. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Nightly Build 04/09/02 - Problem with Tiles
I updated to the nightly build tonight and when running Tiles, I get the error below. I was using a recent build (2-3 weeks) for the past couple weeks and it's been running fine - anything change? In JSP: [Exception in:/layouts/menuLayout.jsp] org.apache.struts.tiles.xmlDefinition.XmlAttribute In Error Log: 2002-04-09 23:59:20 ApplicationDispatcher[/onpoint] Servlet.service() for servlet jsp threw exception java.lang.ClassCastException: org.apache.struts.tiles.xmlDefinition.XmlAttribute at org.apache.jsp.menuLayout$jsp._jspService(menuLayout$jsp.java:105) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.netbeans.modules.tomcat.tomcat40.runtime.IDEJspServlet$JspServletWrapper .service(IDEJspServlet.java:172) at org.netbeans.modules.tomcat.tomcat40.runtime.IDEJspServlet.serviceJspFile(ID EJspServlet.java:234) at org.netbeans.modules.tomcat.tomcat40.runtime.IDEJspServlet.service(IDEJspSer vlet.java:326) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
