Re: ValidatorLookupDispatchAction or VLDAction
The alternative Erik is thinking of is FindForward http://cvs.apache.org/viewcvs/jakarta-struts/contrib/scaffold/src/java/org/apache/struts/scaffold/FindForwardAction.java The idea is that you include a forward=whatever in the request, and it trundles through the local and global forwards looking for whatever. So, rather than select a dispatch method, you can select a forward. Personally, I'd say rather than worry about whether Action is an Interface, that the controller should be able to support more than one type of action class. Ideally, we should be able to extend it to support *any* type of action. But, that's the stuff of 2.x. Meanwhile, if I wanted to have a base action that could also be or not be a dispatch action, I would probably just rip-off the dispatch mechanism from the original. (Ah, the miracle of open source.) There would be duplicated code between the original and mine, but my application wouldn't be using the original. If that was still unacceptable, I wager that the dispatch mechanism in DispatchAction could be refactored into a utility class than other Actions could call. Or, it's even possible that the utility code could be moved up into the base Action, so any subclass could use it. -Ted Erik Hatcher wrote: On Monday, March 31, 2003, at 10:01 AM, Brandon Goodin wrote: I'm curious why you consider it such a problem. It has solved several issues for me. Quite the opposite. I rarely use the base Action class :-) LookupDispatchAction itself requires a tighter coupling between what is in the presentation (the button labels) than achieving something like that should. I like Ted Husted's approach in his book better (I don't recall the class name he developed off the top of my head though). I never extend Action directly either. I like to have a thin layer between actions and Action... with an intermediate BaseAction, which extends Action. But now what happens when you want to use LookupDispatchAction? You can't, cleanly. So then we'd end up with a BaseLookupDispatchAction to maintain that thin layer, and there would be duplicated code. I suspect there is some way to use aggregation to embed a LookupDispatchAction instance inside a BaseLookupDispatchAction, but my current project does not have forms that have multiple submit buttons, so its not an issue currently. In other words, inheritance sucks :) thats a bit of harsh and untrue statement, I know, but the point is that its the strongest OO coupling out there, and loosely coupled is the ideal goal, not strongly coupled. Action should be an interface! Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
Craig R. McClanahan wrote: These tags don't belong in struts-html because they don't generate any HTML-speicifc output -- they are perfectly usable when you are generating WML, for example. It's fine to consider a new library for HTML-independent output, but I'm -1 on dumping them into struts-html simply because they are Struts specific. It's not simply because they are Struts specific. It's because they relate to operations associated with HTML pages. For example, I can create a redirect with a HTML page by doing this: html head META HTTP-EQUIV=Refresh CONTENT=0;URL=./Welcome.do /head body /body /html Our redirect tag is the functional equivalent. There's not an equivalent for the forward tag, but the forward tag should be kept with the redirect tag. Coincidentally, this also puts all the Struts specific tags in one library, but that's just icing. -Ted. -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18370] - generate MANIFEST.MF with ant task
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=18370. 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=18370 generate MANIFEST.MF with ant task --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 17:09 --- Makes sense to put in the version number from the build.xml Couple of differences with Guillaume though - still recommend having rest of the info in a MANIFEST.MF file and checking that out, as is being done currently. (Actually, his example kind of conforms to this, wherein he uses both the 'manifest' attribute and 'manifest' nested element, thereby merging both of them) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
On Fri, 4 Apr 2003, Ted Husted wrote: Date: Fri, 04 Apr 2003 07:29:00 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Craig R. McClanahan wrote: These tags don't belong in struts-html because they don't generate any HTML-speicifc output -- they are perfectly usable when you are generating WML, for example. It's fine to consider a new library for HTML-independent output, but I'm -1 on dumping them into struts-html simply because they are Struts specific. It's not simply because they are Struts specific. It's because they relate to operations associated with HTML pages. Don't they work in WML pages (or any other XML-based document format) too? They are HTTP specific (or, more properly, redirect is HTTP specific and forward is servlet-api-specific), not HTML specific. As a thought experiment, where would you put a new tag to add an HTTP header? Or set a cookie? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ValidatorLookupDispatchAction or VLDAction
The ValidatorLookupDispatchAction is it's own class. I DID duplicate the code and made some changes that I felt needed to exist in the current LoookupDispatchAction. For example, if the parameter is not in the the request then it will default to the uspecified method. For example, assuming submit is the parameter, '/my/foo/action.do' and '/my/foo/action.do?submit=' will both resolve to the unspecified method. Anyways, you can check out the code. I do like the idea of Utilitizing the lookup process or including it in the base action. That would be ideal to me. Utilitizing the Validator lookup would be good too. The same process that is used in the form is the same process that is used in the ValidatorLookupDispatchAction. Anyways, that's my .02. For now you can get the code to the VLD at the link that is supplied on the enhancement submission. Brandon Goodin P.S. When will the 2.0 discussions start? I would love to be involved in them... -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 5:14 AM To: Struts Developers List Subject: Re: ValidatorLookupDispatchAction or VLDAction The alternative Erik is thinking of is FindForward http://cvs.apache.org/viewcvs/jakarta-struts/contrib/scaffold/src/java/org/a pache/struts/scaffold/FindForwardAction.java The idea is that you include a forward=whatever in the request, and it trundles through the local and global forwards looking for whatever. So, rather than select a dispatch method, you can select a forward. Personally, I'd say rather than worry about whether Action is an Interface, that the controller should be able to support more than one type of action class. Ideally, we should be able to extend it to support *any* type of action. But, that's the stuff of 2.x. Meanwhile, if I wanted to have a base action that could also be or not be a dispatch action, I would probably just rip-off the dispatch mechanism from the original. (Ah, the miracle of open source.) There would be duplicated code between the original and mine, but my application wouldn't be using the original. If that was still unacceptable, I wager that the dispatch mechanism in DispatchAction could be refactored into a utility class than other Actions could call. Or, it's even possible that the utility code could be moved up into the base Action, so any subclass could use it. -Ted Erik Hatcher wrote: On Monday, March 31, 2003, at 10:01 AM, Brandon Goodin wrote: I'm curious why you consider it such a problem. It has solved several issues for me. Quite the opposite. I rarely use the base Action class :-) LookupDispatchAction itself requires a tighter coupling between what is in the presentation (the button labels) than achieving something like that should. I like Ted Husted's approach in his book better (I don't recall the class name he developed off the top of my head though). I never extend Action directly either. I like to have a thin layer between actions and Action... with an intermediate BaseAction, which extends Action. But now what happens when you want to use LookupDispatchAction? You can't, cleanly. So then we'd end up with a BaseLookupDispatchAction to maintain that thin layer, and there would be duplicated code. I suspect there is some way to use aggregation to embed a LookupDispatchAction instance inside a BaseLookupDispatchAction, but my current project does not have forms that have multiple submit buttons, so its not an issue currently. In other words, inheritance sucks :) thats a bit of harsh and untrue statement, I know, but the point is that its the strongest OO coupling out there, and loosely coupled is the ideal goal, not strongly coupled. Action should be an interface! Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18221] - Move custom taglibs into their own jar/distribution
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=18221. 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=18221 Move custom taglibs into their own jar/distribution --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 17:34 --- Anyone care to set a target milestone on this one? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
I would do those things in an Action as I can't see how they're related to the view. If they were tags they would most definitely not go in the html taglib. David From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Date: Fri, 4 Apr 2003 09:11:24 -0800 (PST) On Fri, 4 Apr 2003, Ted Husted wrote: Date: Fri, 04 Apr 2003 07:29:00 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Craig R. McClanahan wrote: These tags don't belong in struts-html because they don't generate any HTML-speicifc output -- they are perfectly usable when you are generating WML, for example. It's fine to consider a new library for HTML-independent output, but I'm -1 on dumping them into struts-html simply because they are Struts specific. It's not simply because they are Struts specific. It's because they relate to operations associated with HTML pages. Don't they work in WML pages (or any other XML-based document format) too? They are HTTP specific (or, more properly, redirect is HTTP specific and forward is servlet-api-specific), not HTML specific. As a thought experiment, where would you put a new tag to add an HTTP header? Or set a cookie? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
+1 IMHO, we are talking about View - [Protocol] - Controller layers. We have taglibs for the View and Actions for the Controller. logic:redirect and logic:forward are definitely an encroachment of the view on controller domain. In an ideal world we should just take them out. Barring which (though I dont really have a use-case), I would recommend having a 'http' taglib for http specific tags (maybe have 'wap' etc as needed). Mohan --- David Graham [EMAIL PROTECTED] wrote: I would do those things in an Action as I can't see how they're related to the view. If they were tags they would most definitely not go in the html taglib. David From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Date: Fri, 4 Apr 2003 09:11:24 -0800 (PST) On Fri, 4 Apr 2003, Ted Husted wrote: Date: Fri, 04 Apr 2003 07:29:00 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Craig R. McClanahan wrote: These tags don't belong in struts-html because they don't generate any HTML-speicifc output -- they are perfectly usable when you are generating WML, for example. It's fine to consider a new library for HTML-independent output, but I'm -1 on dumping them into struts-html simply because they are Struts specific. It's not simply because they are Struts specific. It's because they relate to operations associated with HTML pages. Don't they work in WML pages (or any other XML-based document format) too? They are HTTP specific (or, more properly, redirect is HTTP specific and forward is servlet-api-specific), not HTML specific. As a thought experiment, where would you put a new tag to add an HTTP header? Or set a cookie? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: logic:forward and logic:redirect
The one legitimate use for them that I can think of to have the welcome-page of your web app forward or redirect to an action, because you can't (portably) use an action as the welcome-page. -Original Message- From: Mohan Kishore [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 1:41 PM To: Struts Developers List Subject: Re: logic:forward and logic:redirect +1 IMHO, we are talking about View - [Protocol] - Controller layers. We have taglibs for the View and Actions for the Controller. logic:redirect and logic:forward are definitely an encroachment of the view on controller domain. In an ideal world we should just take them out. Barring which (though I dont really have a use-case), I would recommend having a 'http' taglib for http specific tags (maybe have 'wap' etc as needed). Mohan --- David Graham [EMAIL PROTECTED] wrote: I would do those things in an Action as I can't see how they're related to the view. If they were tags they would most definitely not go in the html taglib. David From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Date: Fri, 4 Apr 2003 09:11:24 -0800 (PST) On Fri, 4 Apr 2003, Ted Husted wrote: Date: Fri, 04 Apr 2003 07:29:00 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Craig R. McClanahan wrote: These tags don't belong in struts-html because they don't generate any HTML-speicifc output -- they are perfectly usable when you are generating WML, for example. It's fine to consider a new library for HTML-independent output, but I'm -1 on dumping them into struts-html simply because they are Struts specific. It's not simply because they are Struts specific. It's because they relate to operations associated with HTML pages. Don't they work in WML pages (or any other XML-based document format) too? They are HTTP specific (or, more properly, redirect is HTTP specific and forward is servlet-api-specific), not HTML specific. As a thought experiment, where would you put a new tag to add an HTTP header? Or set a cookie? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: logic:forward and logic:redirect
But you can use a filter or code the http redirect pragma by hand. The redirect and forward tags don't belong in our taglibs, IMO. David From: Jeff Robertson [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: logic:forward and logic:redirect Date: Fri, 4 Apr 2003 13:44:13 -0500 The one legitimate use for them that I can think of to have the welcome-page of your web app forward or redirect to an action, because you can't (portably) use an action as the welcome-page. -Original Message- From: Mohan Kishore [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 1:41 PM To: Struts Developers List Subject: Re: logic:forward and logic:redirect +1 IMHO, we are talking about View - [Protocol] - Controller layers. We have taglibs for the View and Actions for the Controller. logic:redirect and logic:forward are definitely an encroachment of the view on controller domain. In an ideal world we should just take them out. Barring which (though I dont really have a use-case), I would recommend having a 'http' taglib for http specific tags (maybe have 'wap' etc as needed). Mohan --- David Graham [EMAIL PROTECTED] wrote: I would do those things in an Action as I can't see how they're related to the view. If they were tags they would most definitely not go in the html taglib. David From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Date: Fri, 4 Apr 2003 09:11:24 -0800 (PST) On Fri, 4 Apr 2003, Ted Husted wrote: Date: Fri, 04 Apr 2003 07:29:00 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Craig R. McClanahan wrote: These tags don't belong in struts-html because they don't generate any HTML-speicifc output -- they are perfectly usable when you are generating WML, for example. It's fine to consider a new library for HTML-independent output, but I'm -1 on dumping them into struts-html simply because they are Struts specific. It's not simply because they are Struts specific. It's because they relate to operations associated with HTML pages. Don't they work in WML pages (or any other XML-based document format) too? They are HTTP specific (or, more properly, redirect is HTTP specific and forward is servlet-api-specific), not HTML specific. As a thought experiment, where would you put a new tag to add an HTTP header? Or set a cookie? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: logic:forward and logic:redirect
In real life usually *do* code the redirects by hand. Reading this discussion was the first time I'd actually thought of using them for that. However, using the actions has one advantage. Compare: logic:forward name=welcome / to jsp:forward page=/welcome.do / These are mostly equivalent, except that the second explicitly contains the controller's extension mapping. This is information that we would like to encapsulate if possible. The first version does that nicely. I admit that this is a minor nit to pick.. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 1:51 PM To: [EMAIL PROTECTED] Subject: RE: logic:forward and logic:redirect But you can use a filter or code the http redirect pragma by hand. The redirect and forward tags don't belong in our taglibs, IMO. David From: Jeff Robertson [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: logic:forward and logic:redirect Date: Fri, 4 Apr 2003 13:44:13 -0500 The one legitimate use for them that I can think of to have the welcome-page of your web app forward or redirect to an action, because you can't (portably) use an action as the welcome-page. -Original Message- From: Mohan Kishore [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 1:41 PM To: Struts Developers List Subject: Re: logic:forward and logic:redirect +1 IMHO, we are talking about View - [Protocol] - Controller layers. We have taglibs for the View and Actions for the Controller. logic:redirect and logic:forward are definitely an encroachment of the view on controller domain. In an ideal world we should just take them out. Barring which (though I dont really have a use-case), I would recommend having a 'http' taglib for http specific tags (maybe have 'wap' etc as needed). Mohan --- David Graham [EMAIL PROTECTED] wrote: I would do those things in an Action as I can't see how they're related to the view. If they were tags they would most definitely not go in the html taglib. David From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Date: Fri, 4 Apr 2003 09:11:24 -0800 (PST) On Fri, 4 Apr 2003, Ted Husted wrote: Date: Fri, 04 Apr 2003 07:29:00 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Craig R. McClanahan wrote: These tags don't belong in struts-html because they don't generate any HTML-speicifc output -- they are perfectly usable when you are generating WML, for example. It's fine to consider a new library for HTML-independent output, but I'm -1 on dumping them into struts-html simply because they are Struts specific. It's not simply because they are Struts specific. It's because they relate to operations associated with HTML pages. Don't they work in WML pages (or any other XML-based document format) too? They are HTTP specific (or, more properly, redirect is HTTP specific and forward is servlet-api-specific), not HTML specific. As a thought experiment, where would you put a new tag to add an HTTP header? Or set a cookie? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
RE: ValidatorLookupDispatchAction or VLDAction
:-D Oh, okay... so we aren't going to get ahead of ourselves? Shucks! I thought the goal was to get everything done good enough and then move on ;-). Thanks for the tip. I will check out the needs in commons. Brandon Goodin -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 11:25 AM To: [EMAIL PROTECTED] Subject: RE: ValidatorLookupDispatchAction or VLDAction P.S. When will the 2.0 discussions start? I would love to be involved in them... If you're anxious to talk about 2.0 why not volunteer some time in the commons projects we're dependant on so we can finish 1.1? DBCP and Pool still need some work. David _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: logic:forward and logic:redirect
That argument only holds as long as you're on a pre-servlet 2.3 container. 2.3 and up support filters so the tags become obsolete. I think the tags should be deprecated soon and removed in whatever release we set out minimum servlet version to 2.3 in. David From: Jeff Robertson [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: logic:forward and logic:redirect Date: Fri, 4 Apr 2003 13:59:34 -0500 In real life usually *do* code the redirects by hand. Reading this discussion was the first time I'd actually thought of using them for that. However, using the actions has one advantage. Compare: logic:forward name=welcome / to jsp:forward page=/welcome.do / These are mostly equivalent, except that the second explicitly contains the controller's extension mapping. This is information that we would like to encapsulate if possible. The first version does that nicely. I admit that this is a minor nit to pick.. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 1:51 PM To: [EMAIL PROTECTED] Subject: RE: logic:forward and logic:redirect But you can use a filter or code the http redirect pragma by hand. The redirect and forward tags don't belong in our taglibs, IMO. David From: Jeff Robertson [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: logic:forward and logic:redirect Date: Fri, 4 Apr 2003 13:44:13 -0500 The one legitimate use for them that I can think of to have the welcome-page of your web app forward or redirect to an action, because you can't (portably) use an action as the welcome-page. -Original Message- From: Mohan Kishore [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 1:41 PM To: Struts Developers List Subject: Re: logic:forward and logic:redirect +1 IMHO, we are talking about View - [Protocol] - Controller layers. We have taglibs for the View and Actions for the Controller. logic:redirect and logic:forward are definitely an encroachment of the view on controller domain. In an ideal world we should just take them out. Barring which (though I dont really have a use-case), I would recommend having a 'http' taglib for http specific tags (maybe have 'wap' etc as needed). Mohan --- David Graham [EMAIL PROTECTED] wrote: I would do those things in an Action as I can't see how they're related to the view. If they were tags they would most definitely not go in the html taglib. David From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Date: Fri, 4 Apr 2003 09:11:24 -0800 (PST) On Fri, 4 Apr 2003, Ted Husted wrote: Date: Fri, 04 Apr 2003 07:29:00 -0500 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Craig R. McClanahan wrote: These tags don't belong in struts-html because they don't generate any HTML-speicifc output -- they are perfectly usable when you are generating WML, for example. It's fine to consider a new library for HTML-independent output, but I'm -1 on dumping them into struts-html simply because they are Struts specific. It's not simply because they are Struts specific. It's because they relate to operations associated with HTML pages. Don't they work in WML pages (or any other XML-based document format) too? They are HTTP specific (or, more properly, redirect is HTTP specific and forward is servlet-api-specific), not HTML specific. As a thought experiment, where would you put a new tag to add an HTTP header? Or set a cookie? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com - To unsubscribe,
RE: ValidatorLookupDispatchAction or VLDAction
:-D Oh, okay... so we aren't going to get ahead of ourselves? Shucks! I thought the goal was to get everything done good enough and then move on ;-). Thanks for the tip. I will check out the needs in commons. Thanks! Any help you can give is much appreciated. David _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've always wanted to move them to the HTML taglib, since they are tied to the Struts controller (where the other taglibs are not). This would put, I believe, all the Struts-dependant tags in one place. Nope. I'd say bean:struts is Struts-specific. ;-) -- Martin Cooper I don't think we need to pull them, but I would be in favor of deprecating them as logic tags and placing them in the html taglib (next time around). David Graham wrote: IMHO, the logic:forward and logic:redirect tags implement a business logic function in the view layer rather than in an Action. The rest of the tags in the logic taglib provide view layer functionality. I think we should deprecate logic:forward and logic:redirect to enforce a cleaner MVC implementation. Thoughts? David _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[OT}So I did a bug query and...
I queryed the bug database and I see 10 or fewer bugs for commons dbcp and pool. I assume these are the bugs that need to be fixed. But, I have a few questions. 1) When I queried the bug database there were several parameters that I wasn't sure about... How do I know I am querying the database for the full list current bugs etc...? Following is my query for dbcp. Is this producing an honest listing of needed fixes? http://issues.apache.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=ASSI GNEDbug_status=REOPENEDemail1=emailtype1=substringemailassigned_to1=1em ail2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=change din=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Commonscompone nt=Dbcpshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type =allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=key words_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doit order=Reuse+same+sort+as+last+time 2) How do I know which bugs are higher priority. I know that people who submit them often set the priorities different than the committers would. So, are the but reports edited to reflect their true priority. 3) How do I know if someone has started working on a patch/fix for a bug already? Brandon Goodin -Original Message- From: Brandon Goodin [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 12:02 PM To: Struts Developers List Subject: RE: ValidatorLookupDispatchAction or VLDAction :-D Oh, okay... so we aren't going to get ahead of ourselves? Shucks! I thought the goal was to get everything done good enough and then move on ;-). Thanks for the tip. I will check out the needs in commons. Brandon Goodin -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 11:25 AM To: [EMAIL PROTECTED] Subject: RE: ValidatorLookupDispatchAction or VLDAction P.S. When will the 2.0 discussions start? I would love to be involved in them... If you're anxious to talk about 2.0 why not volunteer some time in the commons projects we're dependant on so we can finish 1.1? DBCP and Pool still need some work. David _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: logic:forward and logic:redirect
-Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED] Sent: Friday, April 04, 2003 2:11 PM To: [EMAIL PROTECTED] Subject: Re: logic:forward and logic:redirect Ted Husted [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've always wanted to move them to the HTML taglib, since they are tied to the Struts controller (where the other taglibs are not). This would put, I believe, all the Struts-dependant tags in one place. Nope. I'd say bean:struts is Struts-specific. ;-) And logic:messagePresent as well. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
File upload Validator
Hi all! I have development/design question. Please do not read it as a atack of any kind. I jsut try to understand what I am missing. Beacuse obviously I am missing something. First an only question: why org.apache.struts.upload.FormFile is not on the list of types suported by org.apache.struts.validator.DynaActionForm? I believe that it will be nice to have possibility of building dynamic form with file upload. Specially that it works already! The only part which is not implemented is the validator of the file size. This will be nice to have such validator. Of course there is small draw back - we cannot validate size of uploaded file on the JavaScript side (but who said that we have to). I believe that this will add the flexibility to the existing official way (based on struts-upload examlpe) and simplify the page development. I already developed such validator. If somebody think that it can be a good idea to add it after testing to org.apache.struts.validator.FieldChecks or make any use of this - I will be happy to send the solution to whoever wish to take a look. It works for me for any form which implements org.apache.commons.beanutils.DynaBean and any form which has geters and seters set the standard way. Best regards Jerzy Puchala - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: File upload Validator
Submit an *enhancement* request in bugzilla and attach a cvs diff -u format patch file to it so we can consider it. David From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: File upload Validator Date: Fri, 4 Apr 2003 14:49:39 -0500 (EST) Hi all! I have development/design question. Please do not read it as a atack of any kind. I jsut try to understand what I am missing. Beacuse obviously I am missing something. First an only question: why org.apache.struts.upload.FormFile is not on the list of types suported by org.apache.struts.validator.DynaActionForm? I believe that it will be nice to have possibility of building dynamic form with file upload. Specially that it works already! The only part which is not implemented is the validator of the file size. This will be nice to have such validator. Of course there is small draw back - we cannot validate size of uploaded file on the JavaScript side (but who said that we have to). I believe that this will add the flexibility to the existing official way (based on struts-upload examlpe) and simplify the page development. I already developed such validator. If somebody think that it can be a good idea to add it after testing to org.apache.struts.validator.FieldChecks or make any use of this - I will be happy to send the solution to whoever wish to take a look. It works for me for any form which implements org.apache.commons.beanutils.DynaBean and any form which has geters and seters set the standard way. Best regards Jerzy Puchala - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18725] New: - New tool should be added into Visual Tools section
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=18725. 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=18725 New tool should be added into Visual Tools section Summary: New tool should be added into Visual Tools section Product: Struts Version: Unknown Platform: Other URL: http://jakarta.apache.org/struts/resources/tools.html OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Web Site AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Recently new visual tool become available for Struts community: Struts Studio from Exadel Inc. ? powerful visual tool for Struts See http://www.exadel.com/products_strutsstudio.htm Exadel Struts Studio is a visual building tool for the Jakarta Struts Framework, the most used J2EE/Web MVC (Model-View-Controller) framework. Struts Studio is designed for the rapid development of Web applications. Our unique visual drag-and-connect approach to this task is essential for the rapid development and re-engineering of Web applications with minimal coding. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16107] - Configure if you want to call ActionForm.reset() in action element in struts-config.
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=16107. 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=16107 Configure if you want to call ActionForm.reset() in action element in struts-config. --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 21:14 --- This is a hugely nasty bug. I spent days trying to figure out why my chained actions kept having empty forms. You shouldn't let it sit around. The problem is that newbies will try to do this because: everybody talks about how you should chain actions, newbies wanting to make everything perfect will implement a reset method, then they try to use these chained actions and nothing works. If you're like me, you try changing the scope, turning off validation, etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16107] - Configure if you want to call ActionForm.reset() in action element in struts-config.
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=16107. 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=16107 Configure if you want to call ActionForm.reset() in action element in struts-config. --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 21:20 --- Your statement everybody talks about how you should chain actions is patently untrue. Amongst the committers, at least, I believe you will find the concensus, or certainly majority, view is that action chaining is a very bad idea. I am very strongly in that camp, having been converted some time ago, and I, for one, am not interested in making changes to support chaining actions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 16107] - Configure if you want to call ActionForm.reset()in action element in struts-config.
We need an FAQ about action chaining that lists the reasons that it is a bad idea. Then we could point people to that page. David From: [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 16107] - Configure if you want to call ActionForm.reset() in action element in struts-config. Date: 4 Apr 2003 21:20:24 - 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=16107. 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=16107 Configure if you want to call ActionForm.reset() in action element in struts-config. --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 21:20 --- Your statement everybody talks about how you should chain actions is patently untrue. Amongst the committers, at least, I believe you will find the concensus, or certainly majority, view is that action chaining is a very bad idea. I am very strongly in that camp, having been converted some time ago, and I, for one, am not interested in making changes to support chaining actions. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18727] New: - Html page freezes upon form submital.
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=18727. 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=18727 Html page freezes upon form submital. Summary: Html page freezes upon form submital. Product: Struts Version: 1.1 RC1 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The html page freezes when a form is submitted. What I mean by freezes is that I have an amimated gif that is intended to indicate that the page is being processed. The gif stops animating when the form is submitted. This occurs whether the image is within the form tags or not within the form tags. I have confirmed that this does not occur with this particular animated gif outside of struts. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18727] - Html page freezes upon form submital.
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=18727. 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=18727 Html page freezes upon form submital. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 22:00 --- This is not a Struts problem. Please post questions to the struts-user mailing list. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18727] - Html page freezes upon form submital.
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=18727. 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=18727 Html page freezes upon form submital. [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 22:07 --- This is a struts problem. It occurs only when submitting a form within the struts framework. I have verified this by setting the form up using several different frameworks and it only occurs when using struts. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 18727] - Html page freezes upon formsubmital.
As David said when closing this bug PLEASE POST QUESTIONS TO THE USERS LIST On Fri, 2003-04-04 at 17:07, [EMAIL PROTECTED] wrote: 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=18727. 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=18727 Html page freezes upon form submital. [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 22:07 --- This is a struts problem. It occurs only when submitting a form within the struts framework. I have verified this by setting the form up using several different frameworks and it only occurs when using struts. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- James Mitchell Software Developer/Struts Evangelist http://www.open-tools.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18727] - Html page freezes upon form submital.
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=18727. 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=18727 Html page freezes upon form submital. [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 22:16 --- When someone suggests that you post your question to the user's list it is wise for you to do so before reopening a bug. Failing to take that advice is considered impolite. When reporting bugs we need more to go on than what you've given us. However, in this case it is *extremely* unlikely that Struts is causing your problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18727] - Html page freezes upon form submital.
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=18727. 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=18727 Html page freezes upon form submital. --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 22:24 --- Obviously this bug is not going to get any attention. To further my request, I would like to add that form actually submits sucessfully. The problem is that while the processingAction is occuring, the page freezes until the page processing action is finished and then forwards to the next page of the application. I believe it is not a problem with one of the tag libraries because I have tested it without using html:tags and it still freezes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18727] - Html page freezes upon form submital.
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=18727. 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=18727 Html page freezes upon form submital. --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 22:36 --- Why don't you atleast try it and see for yourself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
Jeff Robertson wrote: In real life usually *do* code the redirects by hand. Reading this discussion was the first time I'd actually thought of using them for that. However, using the actions has one advantage. Compare: logic:forward name=welcome / to jsp:forward page=/welcome.do / These are mostly equivalent, except that the second explicitly contains the controller's extension mapping. This is information that we would like to encapsulate if possible. The first version does that nicely. I admit that this is a minor nit to pick.. But I think an important one. Moving forward, I'd like to eliminate needing to embed the extension mapping anywhere. We made a real stride in this regard by adding action to the html:link tag. We really should be able to run everything on logical names. I use this exact technique in all my tag-based apps to get around the welcome page use. There should be an action property here too, so that we can go directly to the Welcome action, or whatever is appropriate for the application. -T. -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
There should be an action property here too, so that we can go directly to the Welcome action, or whatever is appropriate for the application. Ted, I really think these tags violate MVC principles and the functionality they provide should be contained in Actions. Can you explain how you view this issue? Thanks, Dave _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
In general, I only use them to get around the bootstrapping issue. You can't use an ActionMapping as a Welcome page. I realize there may be alternatives available for later specifications, but not for the one we support today. Another likely use might be to assert a page's preconditions and forward to an error page if the controller did not keep its contract. Though, I don't really buy the MVC principles argument. Since the tags can specify a forward, rather than a direct link, it's no different than html:link or html:forward, or any of the others. A page does need to know its logical destinations. The MVC violation would be inducing people to hand-code pragmas embeded with system URIs. In any event, we can't deprecate them until we move to a servlet spec that provides an alternative. So, we will need to retain them into the near future. I feel that they replicate funcationality defined in the HTML specification, and therefore belong in the html taglib. http://www.w3.org/TR/html4/struct/global.html#h-7.4.4 This is unlike the other logic tags, which have nothing like them in HTML. Though, I've felt this way since the day the logic and html taglibs were born (Craig didn't agree with me then, either), and so my feelings won't be hurt if it doesn't change at this late date =:0) Of course, for the most part, it's all moot to me personally. I'm not basing new development on JSPs at this point. We could scuttle all the taglibs, and I'd barely notice =:) -Ted. David Graham wrote: There should be an action property here too, so that we can go directly to the Welcome action, or whatever is appropriate for the application. Ted, I really think these tags violate MVC principles and the functionality they provide should be contained in Actions. Can you explain how you view this issue? Thanks, Dave _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
A few comments: 1) All of the tags in the logic taglib relate to flow control. There are two sets - conditionals and 'goto's - but they are all flow control. I find it strange to want to claim that some flow control tags break the MVC model while others don't. 2) If we removed these tags, we wouldn't be enforcing anything. People who use them today would just switch to using jsp:forward and c:redirect, but would lose the convenience of using logical names, as with other Struts tags, and have to hard code them instead. 3) Many people, including myself, have been using these tags since the earliest days of Struts. (They were created in September 2000.) To my knowledge, this is the first time that anyone has suggested that they break the MVC model. If other people really believed that, I would have expected it to come up before now. 4) Just for fun: I find it interesting that David is so impassioned about cleaning up the logic taglib when he's usually the first person to suggest that people forget that taglib and use JSTL instead. ;-) ;-) -- Martin Cooper David Graham [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] IMHO, the logic:forward and logic:redirect tags implement a business logic function in the view layer rather than in an Action. The rest of the tags in the logic taglib provide view layer functionality. I think we should deprecate logic:forward and logic:redirect to enforce a cleaner MVC implementation. Thoughts? David _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
--- Martin Cooper [EMAIL PROTECTED] wrote: 1) All of the tags in the logic taglib relate to flow control. There are two sets - conditionals and 'goto's Not true - conditionals relate to layout and display (i.e. View) - gotos send control out of the current file (i.e. Control) 2) If we removed these tags, we wouldn't be enforcing anything. But, we will be making a statement about the MVC pattern. e.g. People can still put in java code in scriptlets in JSP pages, we are not stopping them. We just have a stand and promote better practices... imho __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18343] - Nested tags cannot find bean in any scope in included JSP
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=18343. 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=18343 Nested tags cannot find bean in any scope in included JSP --- Additional Comments From [EMAIL PROTECTED] 2003-04-04 23:39 --- Think have identified the source of the problem. elaine is trying to use the 'id' attribute in 'nested:iterate' tag to create a bean which she uses in the included JSP. This will not work as the bean is created in 'page' scope. If she wishes she can put in a 'define' right after the 'iterate' tag, and push in this bean into 'request' scope. Alternatively, as Arron suggests take out the 'name' attributes in the included JSP. Nested tags will find their parent tags. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
Mohan Kishore [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] --- Martin Cooper [EMAIL PROTECTED] wrote: 1) All of the tags in the logic taglib relate to flow control. There are two sets - conditionals and 'goto's Not true - conditionals relate to layout and display (i.e. View) Conditionals relate to whatever the developer wants them to relate to. They are in no way limited to layout and display. I can just as easily use a conditional tag to control (sic) a SQL update as I can to determine whether or not to show someone's credit card number. - gotos send control out of the current file (i.e. Control) In my view (!), you are splitting hairs here. You are saying that if a tag exerts control over the flow that takes that flow out of the page, that is Control. But if a tag exerts control over the flow such that the flow remains within the page, that is View. 2) If we removed these tags, we wouldn't be enforcing anything. But, we will be making a statement about the MVC pattern. e.g. People can still put in java code in scriptlets in JSP pages, we are not stopping them. We just have a stand and promote better practices... I agree with promoting best practices, of course. And I claim that using logical names in preference to hard coded URLs is a best practice, and that logic:forward and logic:redirect promote this practice. -- Martin Cooper imho __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
A few comments:
1) All of the tags in the logic taglib relate to flow control. There are
two
sets - conditionals and 'goto's - but they are all flow control. I find it
strange to want to claim that some flow control tags break the MVC model
while others don't.
I see the usage as being something like:
if user is a manager {
logic:redirect...
}
Which, IMO, is logic that belongs in an Action.
2) If we removed these tags, we wouldn't be enforcing anything. People who
use them today would just switch to using jsp:forward and c:redirect,
but would lose the convenience of using logical names, as with other Struts
tags, and have to hard code them instead.
True, but we wouldn't have to maintain them.
3) Many people, including myself, have been using these tags since the
earliest days of Struts. (They were created in September 2000.) To my
knowledge, this is the first time that anyone has suggested that they break
the MVC model. If other people really believed that, I would have expected
it to come up before now.
There's a first time for everything :-).
4) Just for fun: I find it interesting that David is so impassioned about
cleaning up the logic taglib when he's usually the first person to suggest
that people forget that taglib and use JSTL instead. ;-) ;-)
:-) I don't use the logic taglib at all so this is more of a philosophical
issue than anything else. One reason I brought up this topic is that there
are several inconsistencies and enhancement requests for these tags that I'd
rather not deal with. Deprecating them makes sense to me because you can
accomplish the same logic in Actions but it's not a big issue.
David
_
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: logic:forward and logic:redirect
--- Martin Cooper [EMAIL PROTECTED] wrote: Conditionals relate to whatever the developer wants them to relate to. They are in no way limited to layout and display. I can just as easily use a conditional tag to control (sic) a SQL update as I can to determine whether or not to show someone's credit card number. True, and we should try to dissuade people doing non-view stuff in JSP. - gotos send control out of the current file (i.e. Control) In my view (!), you are splitting hairs here. You are saying that if a tag exerts control over the flow that takes that flow out of the page, that is Control. But if a tag exerts control over the flow such that the flow remains within the page, that is View. Actually imho, a pretty important distinction. The whole MVC pattern is based on the controller delegating the flow FROM controller TO the view. If we have the views again delegating flow amongst themselves, the role of controller seems compromised...(poor thing, it will go out of control :) I agree with promoting best practices, of course. And I claim that using logical names in preference to hard coded URLs is a best practice, and that logic:forward and logic:redirect promote this practice. True, i guess the discussion is about where to use these. I second David in saying that Actions are the more appropriate place. and like him, its more of a philosophical discussion for me too - would readily bow before people in the field really using these heavily... regards, Mohan. __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18727] - Html page freezes upon form submital.
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=18727. 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=18727 Html page freezes upon form submital. --- Additional Comments From [EMAIL PROTECTED] 2003-04-05 05:02 --- The reason why it's not going to get any attention soon, is because the informtion provided is simply not enough to go on. We need adequate proof that the problem is indeed struts. For example, if the form tag is written out one way, it works, but Struts' way is broken (and supply that example as well). It's not the server side, because there's nothing binding the html page to the server. But at the very least, we need much more than my animated gif isn't working. If you can't pin it down to exact behavior that is incorrect on Struts' behalf, then supply your example as an attachement. Then, maybe, a developer may pick it up and play and see what the deal is. Until then, I'm sorry to say that this bug report is going to lay quite idle in the invalid basket. It was flagged as invalid, largely because animating gif's have typically nothing to do with web serving frameworks. If you can show me how and where in Struts that the problem echo's from, I'll happily patch it myself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Bugzilla status for bugs with patches
Hi, Is it a standard (at least within jakarta) to prefix the bugs with patches available with a [PATCH]? Any ideas w.r.t creating a status called Has Patch? I ask because there are quite a few bugs in the commons which have no indication about available patches. I guess the commiters can finish up (or reject) the ones with patches, while the rest of us can try our hands at the ones which do not have any fix yet... regards, Mohan. __ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
