Re: Does the /do/* will be supported with modules
The other things with the prefix, is that it maps nicely with CMA security for the modules. Ex: Only users in the Admin role can go to /admin/*. etc. .V OT: pet peve: Since the struts example show login via code (the wrong way) Every Struts book, save Teds and FastTrack, shows the wrong way to login, not the right declarative way. Ted Husted wrote: Only if someone can figure out how to make it work with the current approach to organizng the modules =:0) It's not that we don't ~want~ prefix matching to work with modules, it's that we don't know ~how~. I'm sure that a future release may use a more sophisticated approach to routing the requests, but that might require more surgery that we can justify in a .# release. If you using either prefix or suffix matching properly, you should be able to switch between them by just editing the struts-config. So, technically, it should not make any difference which you use until you're ready to use modules. -Ted. 11/19/2002 7:48:44 AM, Emmanuel Boudrant [EMAIL PROTECTED] wrote: Hi, Actually the /do/* path mapped pattern doesn't work fine with modules, does this pattern will work with final release ...And, is it a good advice to use /do/* instead of *.do Thanx, -emmanuel ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com -- 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]
DO NOT REPLY [Bug 14706] New: - multiple setters
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=14706.
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=14706
multiple setters
Summary: multiple setters
Product: Struts
Version: 1.0.2 Final
Platform: All
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: Controller
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I prefer having the option to set a value with multiple setters, hiding the
actual datatype within the class. This is one of the cardinal principals of
Object Oriented Programming, Polymorphism. Struts ActionForm and the bean
taglib fail when there are multiple setters. I get the error,
package_name.html.BEAN.
My preferrd method of polymorphism, hiding the datatype within the class:
public class Foo {
String var;
public Foo(int v) {}
public Foo(String v) {}
public void setVar(String v) {}
public void setVar(int v) {}
}
Moving data in and out of a JSP, you will always have a String. Through
reflection you will find the setter methods that corresponds to
the value in the JSP. If there is one that uses a string, use it, otherwise
look for one you can convert your string to.
If I've overlooked something in the functionality of Struts and this actually
works, I'll be delighted. If not, please consider allowing polymorphism
in the names of the setters.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11932] - (Message Resource is not multi-app aware) Multi-Resource not work in Multi-Appliction config environment
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=11932. 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=11932 (Message Resource is not multi-app aware) Multi-Resource not work in Multi-Appliction config environment --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 14:32 --- I've implemented a quick dirty solution for the issue: 1) ActionServlet.initApplicationMessageResources(ApplicationConfig) This method now puts the messages resources in the servlet context using as a key Action.MESSAGES_KEY + prefix + bundle: getServletContext().setAttribute(Action.MESSAGES_KEY + config.getPrefix() + mrcs [i].getKey(), resources); 2) RequestUtils.selectApplication(String, HttpServletRequest, ServletContext) This method no longer deals with message resources. In 1.1 b2 it puts the correct message resource for a sub-app in the request. However, it was not dealing with possible bundle keys. Is there a benifit that results form taking the correct message resources from the servlet context and putting them in the request? I could not think of any so I removed all the code from this method that deals with MessageResources objects (the last 7 lines). 3) RequestUtils.message(PageContext, String, String, Object) and RequestUtils.present(PageContext, String, String, Object) These methods use a new method getMessageResources(PageContext pageContext, String bundle) to get a correct message resources object. This new method factors out the common logic for these 2 methods, as Martin suggested. The getMessageResources() method basically just retreives the correct MessageResources object from the ServletContext (that was put there by the initApplicationMessageResources() method). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5518] - Convert HTML Tags to be XHTML-compliant when html:html xhtml=true
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=5518. 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=5518 Convert HTML Tags to be XHTML-compliant when html:html xhtml=true --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 14:59 --- Nope, I missed that one. Do you know what affects this has on javascript form validation? Will js still work with an id attribute instead of name? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14706] - multiple setters
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=14706. 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=14706 multiple setters [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 15:07 --- First, you're talking about method overloading not polymorphism. Second, this violates the JavaBean specification that says your setter must accept the same datatype as the underlying variable. It gets confused when you have two setters for the same property accepting different datatypes. Generally, your ActionForms should accept strings and then populate a business object with the correct datatypes that you pass into the business logic methods. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5518] - Convert HTML Tags to be XHTML-compliant when html:html xhtml=true
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=5518. 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=5518 Convert HTML Tags to be XHTML-compliant when html:html xhtml=true --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 15:29 --- The affect it will have on javascript form validation is that you have to use document.forms[#] to get the form element, or you can use the DOM with the following: document.getElementById(formId); document.getElementsByTagName(form).item(0); Here is an example I worked up to demonstrate. I validated it at: http://validator.w3.org/file-upload.html !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; html head titleXHTML Test/title meta http-equiv=Content-Type content=text/html; charset=utf-8/ /head body form id=test action= p input type=text name=yo id=yo value=My test / /p /form p script type=text/javascript !-- // this doesn't work in XHTML Strict and // seems to stop all statement from working //document.write(document.test.yo.value: + document.test.yo.value); document.write(br/document.getElementById(\yo\).value: + document.getElementById(yo).value); // or you can get the form, then the value */ var form = document.getElementById(test); // this seems to work regardless of whether input has a name attribute document.write(br/document.getElementById(\test\).yo.value: + form.yo.value); // you can also get it by form number var form1 = document.forms[0]; document.write(br/document.forms[0].yo.value: + form1.yo.value); // or by document.getElementsByTagName var form2 = document.getElementsByTagName(form).item(0); document.write(br/document.getElementsByTagName(\form\).item(0).yo.value: + form2.yo.value); //-- /script /p /body /html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14715] New: - Please update Runtime Collective to indicate geographical area
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=14715. 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=14715 Please update Runtime Collective to indicate geographical area Summary: Please update Runtime Collective to indicate geographical area Product: Struts Version: Unknown Platform: All URL: http://jakarta.apache.org/struts/resources/consultants.h tml OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Web Site AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Rather than Runtime Collective - Steve Crossan we'd request Runtime Collective (UK, Canada, Switzerland, Brazil) - Steve Crossan thank you. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts At ApacheCon 2002
Craig, It was nice meeting you and attending your Struts 1.1 session on Tuesday. I'm curious what came of the BOF to discuss the future of Struts. I'd be really interested in your thoughts on the XDoclet work I've done, especially in the Struts Validator realm. I'm generating validation.xml completely, and also all the form bean definitions in our system. I also use XDoclet to process form beans for a one-time starter code generation of a JSP page (templated to our specific look and feel) for a specified form bean, as well as the resource properties that can be used as a starting point for the application resource properties for the field labels. Its amazing amount of generation just on the Struts-side of things, but we use XDoclet for even more than that too. As for DynaActionForm's I still don't get their benefit. Do you use them? Or right ActionForm subclasses? Its even less code to write to do a form bean for me, because my IDE generates all the getter/setters, and being able to generate validation.xml makes it so worthwhile. :) Take care and hopefully I'll get a chance to chat with you further at some point during the week at ApacheCon. Erik Craig R. McClanahan wrote: If you're coming to Las Vegas this week for ApacheCon, there will be two sessions and a BOF specifically focused on Struts: * Session TU07 (Tuesday, 1:30-2:30) - What's New In Struts 1.1 * Session WE06 (Wednesday, 10:00-11:00) - Building Web Applications With Struts * BOF BOF03 (Tuesday, 8:00p-9:00p) - Struts After 1.1 -- Where Do We Go From Here? The BOF is primarily an opportunity to gather input from folks on our initial thinking about the 1.2 and 2.0 roadmaps, and to answer any general questions that people have. I look forward to meeting any Struts users (and developers) attending the conference. You can find me at one of these sessions, or hanging around the Sun booths in the Exhibit Hall. Craig McClanahan -- 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 14716] New: - Add a method putToken() to Action class
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=14716. 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=14716 Add a method putToken() to Action class Summary: Add a method putToken() to Action class Product: Struts Version: 1.1 Beta 2 Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Action has saveToken() which always save a new token in session. But a new token is only needed when transaction is submitted. Consider the situation a user inputs half way on a page that has a transaction token, and clicks a link to another page to look at some information, and then uses back button to come back to the first page. If both pages used saveToken(), then the user can not submit transaction from first page anymore because a new token was saved in the session. putToken() will check whether transaction token exists. It saves a new token in the session only when one does not already exist. In the above situation, if putToken() is used, the 2nd page will get the same transaction token as the 1st page, and the user can still submit from the 1st page. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Does the /do/* will be supported with modules
Hi, question below A Dimecres 20 Novembre 2002 00:37, Craig R. McClanahan va escriure: On Tue, 19 Nov 2002, Emmanuel Boudrant wrote: Date: Tue, 19 Nov 2002 13:48:44 +0100 (CET) From: Emmanuel Boudrant [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Does the /do/* will be supported with modules Hi, Actually the /do/* path mapped pattern doesn't work fine with modules, does this pattern will work with final release At the moment, it appears that the restriction that extension mapping must be used for application modules will remain in the final release. Two things would be necessary to change this: * Someone would have to come up with a strategy that resovles the problem of how to define path-mapped URLs that still include the module prefix in some reasonable fashion that can be parsed. Do you mean, for example if the servlet mapping is /do/* and an action path is /actionPath, the path /do/actionPath should be translated to /do/modulePath/actionPath ? * Someone would have to implement this strategy. ...And, is it a good advice to use /do/* instead of *.do For a non-module scenario, this is pretty much a cosmetics issue -- whichever style creates URLs that you like better is the one you should use. Thanx, -emmanuel Craig Salut! -- Antoni Reus -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts At ApacheCon 2002
I think it is time to start packaging tools and generators with Struts to help the developer Thats a really good initiative Easy Struts will be volunteer ;) -emmanuel --- Craig R. McClanahan [EMAIL PROTECTED] a écrit : On Wed, 20 Nov 2002, Erik Hatcher wrote: Date: Wed, 20 Nov 2002 00:09:36 -0800 From: Erik Hatcher [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Struts At ApacheCon 2002 Craig, It was nice meeting you and attending your Struts 1.1 session on Tuesday. I'm curious what came of the BOF to discuss the future of Struts. Well, there were only a few of us, and no video equipment :-), but it was a good discussion. We basically walked through some of the items that are already on the STATUS page sections on the 1.2 roadmap (likely to stay backwards compatible) and the 2.0 roadmap (likely to be rebuilt on top of Filters). However, I've added some items I've been thinking about, one of which makes your message quite timely. I think it is time to start packaging tools and generators with Struts to help the developer -- either as standalone packages included for convenience, or integrated into the architecture of the package. It wouldbe interesting to explore how XDoclet fits in to this vision. I'd be really interested in your thoughts on the XDoclet work I've done, especially in the Struts Validator realm. I'm generating validation.xml completely, and also all the form bean definitions in our system. I also use XDoclet to process form beans for a one-time starter code generation of a JSP page (templated to our specific look and feel) for a specified form bean, as well as the resource properties that can be used as a starting point for the application resource properties for the field labels. Its amazing amount of generation just on the Struts-side of things, but we use XDoclet for even more than that too. I haven't done a huge amount of review, but I like the basic notion of generating things like this. I'm still getting my head around the idea of doing this from special tags in the source, but I'll get there ... As for DynaActionForm's I still don't get their benefit. Do you use them? Or right ActionForm subclasses? Its even less code to write to do a form bean for me, because my IDE generates all the getter/setters, and being able to generate validation.xml makes it so worthwhile. :) I can see your point in a world where the cost of creating standard ActionForm beans is so low (because the tool does it for you). However, there's a couple of themes that are still involved: * Lots of people are still stuck in a world where they generate these things by hand (even though some level of tooling support is freely available). For those folks, not having to create these classes is a real benefit. * Even in a tool-generated world, it's simpler for a tool to generate just the struts-config.xml fragment than the whole bean classes -- to say nothing of not needing to compile anything. * You should still be able to generate validation.xml if you start from a common definition of the fields. One of the things I want to investigate is embedding the validation rules directly in the form-bean element, for example, so everything about the bean is in one place. (In a high-level UML based tool, for example, all this stuff would be part of the metadata about a particular form captured in the model.) * DynaBean in 1.1 only solves part of the dynamic needs people have. The next logical step is an abstraction that does not predefine the set of properties at all (consider a SQL browser that dynamically creates properties for each row based on the column names included in your SELECT). We'll be able to build this on top of the existing DynaBean infrastructure much more easily than we could on top of standard JavaBeans. Take care and hopefully I'll get a chance to chat with you further at some point during the week at ApacheCon. I will be in the hacker's lounge this afternoon (after lunch until 3:30), and will then be either there or in the Exhibition Hall most of tomorrow. I'd be happy to sit down and talk some more, although I'm unlikely to have time for any in depth reviews first. Erik Craig Craig R. McClanahan wrote: If you're coming to Las Vegas this week for ApacheCon, there will be two sessions and a BOF specifically focused on Struts: * Session TU07 (Tuesday, 1:30-2:30) - What's New In Struts 1.1 * Session WE06 (Wednesday, 10:00-11:00) - Building Web Applications With Struts * BOF BOF03 (Tuesday, 8:00p-9:00p) - Struts After 1.1 -- Where Do We Go From Here? The BOF is primarily an opportunity to gather input from folks on our initial thinking about the 1.2 and 2.0 roadmaps, and to answer
Re: Struts At ApacheCon 2002
Struts Console too. -james --- Emmanuel Boudrant [EMAIL PROTECTED] wrote: I think it is time to start packaging tools and generators with Struts to help the developer Thats a really good initiative Easy Struts will be volunteer ;) -emmanuel --- Craig R. McClanahan [EMAIL PROTECTED] a écrit : On Wed, 20 Nov 2002, Erik Hatcher wrote: Date: Wed, 20 Nov 2002 00:09:36 -0800 From: Erik Hatcher [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Struts At ApacheCon 2002 Craig, It was nice meeting you and attending your Struts 1.1 session on Tuesday. I'm curious what came of the BOF to discuss the future of Struts. Well, there were only a few of us, and no video equipment :-), but it was a good discussion. We basically walked through some of the items that are already on the STATUS page sections on the 1.2 roadmap (likely to stay backwards compatible) and the 2.0 roadmap (likely to be rebuilt on top of Filters). However, I've added some items I've been thinking about, one of which makes your message quite timely. I think it is time to start packaging tools and generators with Struts to help the developer -- either as standalone packages included for convenience, or integrated into the architecture of the package. It wouldbe interesting to explore how XDoclet fits in to this vision. I'd be really interested in your thoughts on the XDoclet work I've done, especially in the Struts Validator realm. I'm generating validation.xml completely, and also all the form bean definitions in our system. I also use XDoclet to process form beans for a one-time starter code generation of a JSP page (templated to our specific look and feel) for a specified form bean, as well as the resource properties that can be used as a starting point for the application resource properties for the field labels. Its amazing amount of generation just on the Struts-side of things, but we use XDoclet for even more than that too. I haven't done a huge amount of review, but I like the basic notion of generating things like this. I'm still getting my head around the idea of doing this from special tags in the source, but I'll get there ... As for DynaActionForm's I still don't get their benefit. Do you use them? Or right ActionForm subclasses? Its even less code to write to do a form bean for me, because my IDE generates all the getter/setters, and being able to generate validation.xml makes it so worthwhile. :) I can see your point in a world where the cost of creating standard ActionForm beans is so low (because the tool does it for you). However, there's a couple of themes that are still involved: * Lots of people are still stuck in a world where they generate these things by hand (even though some level of tooling support is freely available). For those folks, not having to create these classes is a real benefit. * Even in a tool-generated world, it's simpler for a tool to generate just the struts-config.xml fragment than the whole bean classes -- to say nothing of not needing to compile anything. * You should still be able to generate validation.xml if you start from a common definition of the fields. One of the things I want to investigate is embedding the validation rules directly in the form-bean element, for example, so everything about the bean is in one place. (In a high-level UML based tool, for example, all this stuff would be part of the metadata about a particular form captured in the model.) * DynaBean in 1.1 only solves part of the dynamic needs people have. The next logical step is an abstraction that does not predefine the set of properties at all (consider a SQL browser that dynamically creates properties for each row based on the column names included in your SELECT). We'll be able to build this on top of the existing DynaBean infrastructure much more easily than we could on top of standard JavaBeans. Take care and hopefully I'll get a chance to chat with you further at some point during the week at ApacheCon. I will be in the hacker's lounge this afternoon (after lunch until 3:30), and will then be either there or in the Exhibition Hall most of tomorrow. I'd be happy to sit down and talk some more, although I'm unlikely to have time for any in depth reviews first. Erik Craig Craig R. McClanahan wrote: If you're coming to Las Vegas this week for ApacheCon, there will be two sessions and a BOF specifically focused on Struts: * Session TU07 (Tuesday, 1:30-2:30) - What's New In Struts 1.1 * Session WE06 (Wednesday, 10:00-11:00) - Building Web Applications
DO NOT REPLY [Bug 14720] New: - Javascript tag NPEs if a depends rule is not in rules file
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=14720. 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=14720 Javascript tag NPEs if a depends rule is not in rules file Summary: Javascript tag NPEs if a depends rule is not in rules file Product: Struts Version: Nightly Build Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] the html:Javascript tag will throw an NPE at line 338: String javascript = va.getJavascript(); if va == null. va will == null only if the depends string was not found in the validator-rules.xml. A warning log message or clearer exception would be nicer and make it easier to debug why a JSP page is getting an NPE from this custom tag. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14716] - Add a method putToken() to Action class
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=14716. 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=14716 Add a method putToken() to Action class [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-11-20 22:19 --- The whole idea of using token is to discourage the user from using, the browser buttons. The only time your Action is called is when the Form is submitted. It is your Action classes that change the token. If the user only clicks on a link, then the token will not be saved/changed in the session because a submit has not been performed. Then they are free to use the 'back' button, and all will work ok. If the link has a JavaScript onclick submit, that tells me you want Struts to process the form, then your Action will need to handle this situation, by differentiating between a submit by a Submit button and a submit by a link click. You could set a hidden field value if a button submit was sent as apposed to a link submit. However, it doesn't sound like your 'links' are doing submits. If that is the case then there should be no problem. Is this a specific problem you are encountering, or are you in the design stage performing a what-if analysis ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tools in Struts [was: Re: Struts At ApacheCon 2002]
James Holmes wrote: Struts Console too. -james --- Emmanuel Boudrant [EMAIL PROTECTED] wrote: I think it is time to start packaging tools and generators with Struts to help the developer Thats a really good initiative Easy Struts will be volunteer ;) -emmanuel Would the source reside in jakrata-Struts or just the applications? The reason I ask is that for speed of evolution it might be reasonable to keep/place the source code on SourceForge, in an open community. That way Emmanuel and James could draw from a seperate pool of developers as THEY saw fit. Also then they might combine resources and create a hybrid product. I am not opposed to including the source in Jakarta-Struts, just asking a question. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Nightly] Documentation
Next time the Nightly documentation is updated, I'd like to request that the JavaDoc also be updated. From what I can tell it hasn't been updated for at least a month or so. I have read the directions for updating the web site, but don't knoe if I myself have access to do it ? -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Does the /do/* will be supported with modules
Hi, I have a similar problem, in that I would like to use path mappings, and modules (which are not supported in 1.1). Is there a clear explanation of the issue with implementing it? From Craig's comment below, * Someone would have to come up with a strategy that resovles the problem of how to define path-mapped URLs that still include the module prefix in some reasonable fashion that can be parsed. I understand that there is a problem, but not the *actual* part which makes it difficult (most likely due my limited understanding of the insides of struts). Does anyone have a clear description of the problem, and issues which make including this difficult? At least then maybe some of the list readers could think about possible solutions. Regards, - Tim Antoni Reus [EMAIL PROTECTED] on 21/11/2002 06:17:44 Please respond to Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] cc: Subject: Re: Does the /do/* will be supported with modules Hi, question below A Dimecres 20 Novembre 2002 00:37, Craig R. McClanahan va escriure: On Tue, 19 Nov 2002, Emmanuel Boudrant wrote: Date: Tue, 19 Nov 2002 13:48:44 +0100 (CET) From: Emmanuel Boudrant [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Does the /do/* will be supported with modules Hi, Actually the /do/* path mapped pattern doesn't work fine with modules, does this pattern will work with final release At the moment, it appears that the restriction that extension mapping must be used for application modules will remain in the final release. Two things would be necessary to change this: * Someone would have to come up with a strategy that resovles the problem of how to define path-mapped URLs that still include the module prefix in some reasonable fashion that can be parsed. Do you mean, for example if the servlet mapping is /do/* and an action path is /actionPath, the path /do/actionPath should be translated to /do/modulePath/actionPath ? * Someone would have to implement this strategy. ...And, is it a good advice to use /do/* instead of *.do For a non-module scenario, this is pretty much a cosmetics issue -- whichever style creates URLs that you like better is the one you should use. Thanx, -emmanuel Craig Salut! -- Antoni Reus -- 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: Does the /do/* will be supported with modules
11/20/2002 7:35:50 AM, V. Cekvenich [EMAIL PROTECTED] wrote: The other things with the prefix, is that it maps nicely with CMA security for the modules. Ex: Only users in the Admin role can go to /admin/*. etc. .V Actually, prefix mapping works just fine with container- basedsecurity. You just include the prefix with the constraint: web-resource-nameAdministrative/web-resource-name !-- The URLs to protect -- url-pattern/do/admin/*/url-pattern /web-resource-collection It's also possible that this strategy could also be applied to modules. Instead of declaring your modules to be payables/, we might be able to accept do/payables/ where /do/* is mapped to the ActionServlet. The gotcha would be an assumption that there are no slashes in the module name. But since there is already a flag for prefix matching, that's something we could watch for. Another approach might be to use the existing prefix matching flag to automatically prepend the prefix. We couldn't do that at first because it would mean the pages would have to be stored under /do/ too, which wouldn't work. But, we've since added a setting to munge the path used to find the pages (so they can be placed under /WEBINF/$MODULE for example). We should be able to use that feature to relocate the pages so that they are not directly under /do/, and get the system to look under /pages/do/payable or /WEBINF/do/payable instead. Unforunately, everything I have open right now is 1.0, and so I can't run any quick tests. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13701] - newline swallowed bei MultipartElement or MultipartIterator
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=13701. 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=13701 newline swallowed bei MultipartElement or MultipartIterator --- Additional Comments From [EMAIL PROTECTED] 2002-11-21 00:09 --- We are also seeing this problem in 1.1b2. The browser does not seem to matter -- it happens with IE 6 and Mozilla 1.1, neither of which does UTF-8, AFAIK. It can be worked around with JavaScript in the submission, but that's quite ugly. So far it appears to be in MultipartBoundaryInputStream; we're still trying to nail it down. Our environment: JDK 1.4.1, Resin 2.1.5, Struts 1.1b2 on Solaris 8 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Tools
11/20/2002 2:46:08 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: I think it is time to start packaging tools and generators with Struts to help the developer -- either as standalone packages included for convenience, or integrated into the architecture of the package. As it stands, there is already a very healthy add-in marketplace for Struts. I think this is one reason why Struts has become so popular, and anything we do should be with an eye toward expanding the universe of Struts extensions. Personally, I am vastly impressed by the community support for Eclipse plug-ins. I wold very much like to help create the same sort of environment for Struts. I am also vastly impressed by the way some Maven-based packages (like Jelly) are able to automatically download whatever JARs they need. What I would like to work toward is an environment where there is a distinct Struts core, accompanied by a number of easy-to-install standard options (Tiles, Validator, Struts-EL, Console, and so forth). Of course, any third-party options would be just as easy to install as the standards maintained by the Struts Committers. An important idea would be that when we provide standard options, we are also demonstrating how others can plug-in their own options instead. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tools in Struts [was: Re: Struts At ApacheCon 2002]
11/20/2002 5:29:24 PM, Robert Leland [EMAIL PROTECTED] wrote: Would the source reside in jakrata-Struts or just the applications? The reason I ask is that for speed of evolution it might be reasonable to keep/place the source code on SourceForge, in an open community. That way Emmanuel and James could draw from a seperate pool of developers as THEY saw fit. Also then they might combine resources and create a hybrid product. I am not opposed to including the source in Jakarta-Struts, just asking a question. If anyone is interested, I have a Struts project setup at SourceForge that is open to all comers. http://sourceforge.net/projects/struts I wouldn't mind turning this into a Struts commons, where we can all cooperate on developing various extensions to the Struts core. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/resources consultants.xml
dgraham 2002/11/20 17:38:32 Modified:doc/resources consultants.xml Log: Updated text for Bugzilla PR# 14715. Revision ChangesPath 1.10 +1 -1 jakarta-struts/doc/resources/consultants.xml Index: consultants.xml === RCS file: /home/cvs/jakarta-struts/doc/resources/consultants.xml,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- consultants.xml 29 Oct 2002 04:03:59 - 1.9 +++ consultants.xml 21 Nov 2002 01:38:32 - 1.10 @@ -52,7 +52,7 @@ pa href=http://www.oio.de/struts-consulting.htm;Orientation in Objects (Germany)/a - a href=mailto:[EMAIL PROTECTED];Thomas Bayer/a./p pa href=http://www.projectrefinery.com;Project Refinery/a - a href=mailto:[EMAIL PROTECTED]; Jason Smith/a/p pa href=http://www.raibledesigns.com/;Raible Designs/a - a href=mailto:[EMAIL PROTECTED];Matt Raible/a./p -pa href=http://www.runtime-collective.com;Runtime Collective/a - a href=mailto:[EMAIL PROTECTED];Steve Crossan/a/p +pa href=http://www.runtime-collective.com;Runtime Collective (UK, Canada, Switzerland, Brazil)/a - a href=mailto:[EMAIL PROTECTED];Steve Crossan/a/p pa href=http://www.sbti.com/;Segue Solutions/a - a href=mailto:[EMAIL PROTECTED];John J. Thomas/a./p pa href=http://www.scioworks.com/;Scioworks Technologies [Singapore]/a - a href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a./p pa href=http://www.sharedskills.com/;Shared Skills Ltd (UK)/a - a href=mailto:[EMAIL PROTECTED];Mike Way/a./p -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13574] - taglib tld URIs need updating
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=13574. 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=13574 taglib tld URIs need updating [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-21 01:48 --- I removed the version numbers yesterday. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html JavascriptValidatorTag.java
dgraham 2002/11/20 18:02:16
Modified:src/share/org/apache/struts/taglib/html
JavascriptValidatorTag.java
Log:
Throw a nicer NPE for Bugzilla PR# 14720.
Revision ChangesPath
1.18 +11 -2
jakarta-struts/src/share/org/apache/struts/taglib/html/JavascriptValidatorTag.java
Index: JavascriptValidatorTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/html/JavascriptValidatorTag.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- JavascriptValidatorTag.java 20 Nov 2002 05:56:08 - 1.17
+++ JavascriptValidatorTag.java 21 Nov 2002 02:02:16 - 1.18
@@ -333,8 +333,17 @@
// Create list of ValidatorActions based on lActionMethods
for (Iterator i = lActionMethods.iterator(); i.hasNext();) {
-ValidatorAction va = resources.getValidatorAction((String)
i.next());
+String depends = (String) i.next();
+ValidatorAction va = resources.getValidatorAction(depends);
+// throw nicer NPE for easier debugging
+if (va == null) {
+throw new NullPointerException(
+Depends string \
++ depends
++ \ was not found in validator-rules.xml.);
+}
+
String javascript = va.getJavascript();
if (javascript != null javascript.length() 0) {
lActions.add(va);
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14720] - Javascript tag NPEs if a depends rule is not in rules file
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=14720. 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=14720 Javascript tag NPEs if a depends rule is not in rules file [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-21 02:05 --- It now throws a NPE with a descriptive message. If there is a more appropriate message than the one I've written please provide a suggestion. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13701] - newline swallowed bei MultipartElement or MultipartIterator
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=13701. 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=13701 newline swallowed bei MultipartElement or MultipartIterator --- Additional Comments From [EMAIL PROTECTED] 2002-11-21 02:49 --- If you are seeing this bug in Struts 1.1b2, and you believe the problem is in MultipartBoundaryInputStream, then you must be explicitly overriding the multipart request handler in your Struts configuration. Struts 1.1b2 contains a new multipart implementation which resolves this issue. The new implementation is now the default multipart handler, and does not use the MultipartBoundaryInputStream class, which is why it looks like you must be specifying the old handler explicitly. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13701] - newline swallowed bei MultipartElement or MultipartIterator
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=13701. 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=13701 newline swallowed bei MultipartElement or MultipartIterator --- Additional Comments From [EMAIL PROTECTED] 2002-11-21 02:56 --- Yes, we are using DiskMultipartRequestHandler instead of the default. We copied an existing project that used it. Thanks for the response and sorry for the confusion. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Ted Husted, Member of the Apache Software Foundation
11/19/2002 6:43:54 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: Please join me in congratulating Ted -- at the Apache Software Foundation Member's Meeting (held last night at ApacheCon), Ted was approved for membership in the ASF. Way to go Ted! Thanks! =:0) I was happy to be one of several Jakarta Comitters voted in the other night. It's good to see our fellow Apaches acknowledging the good work we do here with our only currency -- recognition =:) (PS: Struts In Action is for sale at the bookstore, and I've autographed several copies already :-) (Of course, Craig's been known to autograph just about anything, books, t-shirts, coffee mugs (hmmm, should have spoken to the publisher about more merchandising) =:0) -T. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-struts/src/share/org/apache/struts/tiles/definition ComponentDefinitionsFactoryWrapper.java ReloadableDefinitionsFactory.java
martinc 2002/11/20 19:42:21
Modified:src/share/org/apache/struts/taglib/template PutTag.java
src/share/org/apache/struts/tiles
ActionComponentServlet.java
ComponentDefinition.java DefaultTilesUtilImpl.java
DefinitionsUtil.java TilesPlugin.java
src/share/org/apache/struts/tiles/definition
ComponentDefinitionsFactoryWrapper.java
ReloadableDefinitionsFactory.java
Log:
Replace calls to Class.forName() with RequestUtils.applicationClass().
Add a missing license header to one file.
Revision ChangesPath
1.12 +6 -5
jakarta-struts/src/share/org/apache/struts/taglib/template/PutTag.java
Index: PutTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/template/PutTag.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- PutTag.java 12 Nov 2002 03:56:09 - 1.11
+++ PutTag.java 21 Nov 2002 03:42:21 - 1.12
@@ -68,6 +68,7 @@
import org.apache.struts.Globals;
import org.apache.struts.taglib.template.util.Content;
+import org.apache.struts.util.RequestUtils;
/**
* Tag handler for lt;template:putgt;, which puts content into request scope.
@@ -279,7 +280,7 @@
Class klass = null; // cant name variable class
try {
- klass = Class.forName(className);
+ klass = RequestUtils.applicationClass(className);
}
catch(ClassNotFoundException ex) {
pageContext.setAttribute(Globals.EXCEPTION_KEY, ex,
1.5 +6 -4
jakarta-struts/src/share/org/apache/struts/tiles/ActionComponentServlet.java
Index: ActionComponentServlet.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/tiles/ActionComponentServlet.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ActionComponentServlet.java 12 Nov 2002 03:56:08 - 1.4
+++ ActionComponentServlet.java 21 Nov 2002 03:42:21 - 1.5
@@ -76,6 +76,7 @@
import org.apache.struts.action.ActionServlet;
import org.apache.struts.taglib.html.Constants;
import org.apache.struts.upload.MultipartRequestWrapper;
+import org.apache.struts.util.RequestUtils;
/**
* Action Servlet to be used with Tiles and Struts 1.0.x.
@@ -111,7 +112,8 @@
{
// Check struts version by checkin PlugIn classes existance.
try {
-Class plugInClass = Class.forName(org.apache.struts.action.PlugIn);
+Class plugInClass = RequestUtils.applicationClass(
+org.apache.struts.action.PlugIn);
// Class exist == struts 1.1 or greater
log(
Warning - ActionComponentServlet class: This class is to be used
with Struts1.0.x only.
1.4 +5 -4
jakarta-struts/src/share/org/apache/struts/tiles/ComponentDefinition.java
Index: ComponentDefinition.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/tiles/ComponentDefinition.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- ComponentDefinition.java 16 Nov 2002 04:07:54 - 1.3
+++ ComponentDefinition.java 21 Nov 2002 03:42:21 - 1.4
@@ -67,6 +67,7 @@
import java.util.HashMap;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
+import org.apache.struts.util.RequestUtils;
/**
* Definition of a template / component attributes.
@@ -571,7 +572,7 @@
{
try
{
- Class requestedClass = Class.forName(classname);
+ Class requestedClass = RequestUtils.applicationClass(classname);
Object instance = requestedClass.newInstance();
/*
if( instance instanceof org.apache.struts.action.Action )
1.3 +5 -4
jakarta-struts/src/share/org/apache/struts/tiles/DefaultTilesUtilImpl.java
Index: DefaultTilesUtilImpl.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/tiles/DefaultTilesUtilImpl.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- DefaultTilesUtilImpl.java 16 Nov 2002 06:04:28 - 1.2
+++ DefaultTilesUtilImpl.java 21 Nov 2002 03:42:21 - 1.3
@@ -72,6 +72,7 @@
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.struts.tiles.definition.ComponentDefinitionsFactoryWrapper;
+import org.apache.struts.util.RequestUtils;
/**
* Default
