Custom Actions? (was RE: Benefits of Dynaforms)
ok, this one sentence in ted's post caught my eye: I rarely write custom Actions any more. whoah. how is this possible? most of our web pages represent some sort of database operation: displaying, creating, updating, or deleting. i can see how you can minimize the amount of code that would vary in individual Action classes, but i don't see how could eliminate the need for subclassing altogether. maybe i'm just completely misunderstanding here. could you elaborate on your process? thanks, ab Ideally, a framework like Struts should just be passing gestures and data back and forth between the presentation pages and business tier. IMHO, doing any real programming in Struts is an engineering compromise. Architecturally, we should be trying to help developers avoid as many necessary evils as possible. DynaBeans serve that purpose by making it possible to avoid creating and maintaining yet-another Java class, which, in practice, often encroaches on the business tier. Before DynaBeans, that practice was unavoidable (or at least caused greater evils). With DynaBeans, there is a real possibility that you could code the Struts portion of an application entirely through XML configuration files, and keep all the real programming on the business tier. Here's another kicker: Components like the Validator aren't just for the web tier. You could also be using the Commons Validator in the business tier, which opens the door to a common Validator configuration shared by Struts and the business tier. DynaBeans also have the potential of being the missing buffer we need for data-entry. What about a DynaBean class that included a shadow String field with every dynamic property? (All we need is another map.) If we integrated a DynaBeanBuffer subclass with the Validator, we could then declare field-level validations for our properties. A validate method on the DynaBean could check each of its buffers, and transfer the datea if validation passed, but raise a flag if it didn't. We could then finally use the same bean on the Web tier as we do on the business tier. This sort of thing is a bear to code with conventional JavaBean, but might be worth doing with something like the DynaBean. -Ted. -- 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: Custom Actions? (was RE: Benefits of Dynaforms)
Can anyone point me to the apis for dynaforms (beans) fs -Original Message- From: Andre Beskrowni [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 9:48 AM To: 'Struts Developers List' Subject: Custom Actions? (was RE: Benefits of Dynaforms) ok, this one sentence in ted's post caught my eye: I rarely write custom Actions any more. whoah. how is this possible? most of our web pages represent some sort of database operation: displaying, creating, updating, or deleting. i can see how you can minimize the amount of code that would vary in individual Action classes, but i don't see how could eliminate the need for subclassing altogether. maybe i'm just completely misunderstanding here. could you elaborate on your process? thanks, ab Ideally, a framework like Struts should just be passing gestures and data back and forth between the presentation pages and business tier. IMHO, doing any real programming in Struts is an engineering compromise. Architecturally, we should be trying to help developers avoid as many necessary evils as possible. DynaBeans serve that purpose by making it possible to avoid creating and maintaining yet-another Java class, which, in practice, often encroaches on the business tier. Before DynaBeans, that practice was unavoidable (or at least caused greater evils). With DynaBeans, there is a real possibility that you could code the Struts portion of an application entirely through XML configuration files, and keep all the real programming on the business tier. Here's another kicker: Components like the Validator aren't just for the web tier. You could also be using the Commons Validator in the business tier, which opens the door to a common Validator configuration shared by Struts and the business tier. DynaBeans also have the potential of being the missing buffer we need for data-entry. What about a DynaBean class that included a shadow String field with every dynamic property? (All we need is another map.) If we integrated a DynaBeanBuffer subclass with the Validator, we could then declare field-level validations for our properties. A validate method on the DynaBean could check each of its buffers, and transfer the datea if validation passed, but raise a flag if it didn't. We could then finally use the same bean on the Web tier as we do on the business tier. This sort of thing is a bear to code with conventional JavaBean, but might be worth doing with something like the DynaBean. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Tools
The Tomcat plugin is quite useful as well. I'm using the SolarEclipse plugin for jsp and xml formatting but it's still in the early stages of development. I like the DBEdit plugin for viewing databases. This is a good site for finding Eclipse plugins: http://eclipse-plugins.2y.net/eclipse/index.jsp Dave From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Struts Tools Date: Thu, 21 Nov 2002 19:32:04 -0500 11/20/2002 3:15:37 PM, Emmanuel Boudrant [EMAIL PROTECTED] wrote: Easy Struts will be volunteer ;) How about us putting together our own distribution of Eclipse, with things like *, EZ Struts, Console, and so forth, already bundled in? Or at least a HOW-TO for putting together a complete Struts environment in Eclipse? This would also give people a model to follow to setup comparable howtos for IntelliJ and so forth. One thing about Eclipse is that is already (like Struts) an embarassment of riches. There are so many plugins floating around, you spend a lot of time just separating the wheat from the chaff =:0) For work on the Struts site, I'm finding XML Buddy quite helpful, but I'm not sure where they will be going with the licensing later. Anyone other suggestions for a XML plugin for workign with XML files? (like those we use at Jakarta) -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Custom Actions? (was RE: Benefits of Dynaforms)
dynabeans: http://jakarta.apache.org/commons/beanutils/api/org/apache/commons/beanutils /package-summary.html dynaforms: http://jakarta.apache.org/struts/api/org/apache/struts/action/package-summar y.html -Original Message- From: Satterwhite, Frank [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 9:56 AM To: 'Struts Developers List' Subject: RE: Custom Actions? (was RE: Benefits of Dynaforms) Can anyone point me to the apis for dynaforms (beans) fs -Original Message- From: Andre Beskrowni [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 9:48 AM To: 'Struts Developers List' Subject: Custom Actions? (was RE: Benefits of Dynaforms) ok, this one sentence in ted's post caught my eye: I rarely write custom Actions any more. whoah. how is this possible? most of our web pages represent some sort of database operation: displaying, creating, updating, or deleting. i can see how you can minimize the amount of code that would vary in individual Action classes, but i don't see how could eliminate the need for subclassing altogether. maybe i'm just completely misunderstanding here. could you elaborate on your process? thanks, ab Ideally, a framework like Struts should just be passing gestures and data back and forth between the presentation pages and business tier. IMHO, doing any real programming in Struts is an engineering compromise. Architecturally, we should be trying to help developers avoid as many necessary evils as possible. DynaBeans serve that purpose by making it possible to avoid creating and maintaining yet-another Java class, which, in practice, often encroaches on the business tier. Before DynaBeans, that practice was unavoidable (or at least caused greater evils). With DynaBeans, there is a real possibility that you could code the Struts portion of an application entirely through XML configuration files, and keep all the real programming on the business tier. Here's another kicker: Components like the Validator aren't just for the web tier. You could also be using the Commons Validator in the business tier, which opens the door to a common Validator configuration shared by Struts and the business tier. DynaBeans also have the potential of being the missing buffer we need for data-entry. What about a DynaBean class that included a shadow String field with every dynamic property? (All we need is another map.) If we integrated a DynaBeanBuffer subclass with the Validator, we could then declare field-level validations for our properties. A validate method on the DynaBean could check each of its buffers, and transfer the datea if validation passed, but raise a flag if it didn't. We could then finally use the same bean on the Web tier as we do on the business tier. This sort of thing is a bear to code with conventional JavaBean, but might be worth doing with something like the DynaBean. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc/faqs netbeans.xml project.xml newbie.xml
I think you meant to say JNI instead of JNDI calls to the OS. It's a bit misleading to say it's fast as hell on Windows without mentioning that it runs on Linux as well. SWT is what Swing should have been. Native calls for OS supported widgets, java imitations for other widgets. Dave From: [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-struts/doc/faqs netbeans.xml project.xml newbie.xml Date: 22 Nov 2002 02:45:23 - husted 2002/11/21 18:45:23 Modified:doc/faqs project.xml newbie.xml Added: doc/faqs netbeans.xml Log: Add NetBeans howto by James Mitchell. Revision ChangesPath 1.4 +1 -0 jakarta-struts/doc/faqs/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-struts/doc/faqs/project.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- project.xml 17 Nov 2002 22:07:54 - 1.3 +++ project.xml 22 Nov 2002 02:45:22 - 1.4 @@ -12,6 +12,7 @@ /menu menu name=Howtos +item href=netbeans.html name=Netbeans/ item href=ssl.html name=SSL/ /menu 1.4 +2 -0 jakarta-struts/doc/faqs/newbie.xml Index: newbie.xml === RCS file: /home/cvs/jakarta-struts/doc/faqs/newbie.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- newbie.xml 6 Nov 2002 22:48:46 - 1.3 +++ newbie.xml 22 Nov 2002 02:45:22 - 1.4 @@ -48,6 +48,8 @@ lia href=#linkWhy does the lt;html:link tag URL-encode javascript and mailto links?/a/li +liWhy can't I disable URL-encoding in the Struts taglibs?/li + liWhen is the best time to validate input?/li liHow can I avoid validating a form before data is entered?/li 1.1 jakarta-struts/doc/faqs/netbeans.xml Index: netbeans.xml === ?xml version=1.0? document url=./ssl.xml properties authorJames Mitchell/author titleHow to setup struts in Netbeans IDE - Apache Struts/title /properties body chapter href=netbeans name=How to setup struts in Netbeans IDE section name=For working on the distribution itself ol li Create a new project (from the Project Manager window) /li li Download the struts source distribution (or use built-in cvs to get the module) /li li Extract to a local drive (if on windoze, try not to have spaces in the directory (such as C:\My Documents) /li li Mount the directory you unzipped to /li li Copy build.properties.sample to build.properties and customize to point to where you keep those jars /li li Mount each of the source directories that you wish to work in For me, I use:br / code jakarta-struts/src/sharebr / jakarta-struts/src/example /code /li li Mount each jar referenced in the build.properties filebr / bNote/b - NetBeans has built in support for auto-mounting these if your build.xml specifies the jars in the project.classpath, but that's not the case for the default struts distribution. /li /ol /section section name=For doing your own thing ol li Create a new project (from the Project Manager window) /li li Download (or build for yourself) the required jarsbr / (See the jakarta-struts-1.1-b2/webapps/struts-example.war) /li li Create a directory (I use a structure similar to how the webapp will exist) pre +-/my-project | +-/WEB-INF | +-/classes | +-/lib | +-/src/pre /li li Create a build.xml for your project (so ant can build and war it for you). I recommend you use an existing file to get a jump start on development. Actually, I recommend you re-use someone's entire existing project. That will surely get you ahead of the game. /li li Mount that directorybr / iIf you specified the build classpath and the jars are there, NetBeans will mount the jars for you automatically./i /li li Mount each of the source directories that you wish to work in /myproject/WEB-INF/src /li li Always work in the node in #6 when modifying your java files. /li /ol p I'll also take this opportunity to tell you that I recommend using Eclipse. I was a NetBeans advocate for the longest time, but a few weeks ago several discussion had prompted me to try out Eclipse, and I can say without a doubt, that it is much more mature an IDE than NetBeans. And since they are both Open Source.heywhy not? /p p One definite advantage Eclipse has over NetBeans is that Eclipse is built using SWT (Standard Widget Toolkit). That means that the IDE is written in Java, but the underlying
RE: bloated docs? [was: cvs commit: jakarta-struts/doc/faqs netbeans.xml project.xml newbie.xml]
Yes Sir, you are correct as Mr Karr also pointed out. I'll be committing the complete tutorial later today or first thing tomorrow. So don't worry about changing it for now. As I'm hammering through these screenshots, I hate to think that I will single handedly increase the documentation by 2 Meg. I'm about 60% complete with NetBeans and about 30% with Eclipse. I was planning to add the same for JBuilder 6 Personal Edition, but not sure about legal issues with displaying their product (you would think that they would appreciate more coverage, who knows :/ ) Your thoughts? -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens? - Seymour Cray (1925-1996), father of supercomputing -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 10:06 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-struts/doc/faqs netbeans.xml project.xml newbie.xml I think you meant to say JNI instead of JNDI calls to the OS. It's a bit misleading to say it's fast as hell on Windows without mentioning that it runs on Linux as well. SWT is what Swing should have been. Native calls for OS supported widgets, java imitations for other widgets. Dave From: [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-struts/doc/faqs netbeans.xml project.xml newbie.xml Date: 22 Nov 2002 02:45:23 - husted 2002/11/21 18:45:23 Modified:doc/faqs project.xml newbie.xml Added: doc/faqs netbeans.xml Log: Add NetBeans howto by James Mitchell. Revision ChangesPath 1.4 +1 -0 jakarta-struts/doc/faqs/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-struts/doc/faqs/project.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- project.xml 17 Nov 2002 22:07:54 - 1.3 +++ project.xml 22 Nov 2002 02:45:22 - 1.4 @@ -12,6 +12,7 @@ /menu menu name=Howtos +item href=netbeans.html name=Netbeans/ item href=ssl.html name=SSL/ /menu 1.4 +2 -0 jakarta-struts/doc/faqs/newbie.xml Index: newbie.xml === RCS file: /home/cvs/jakarta-struts/doc/faqs/newbie.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- newbie.xml6 Nov 2002 22:48:46 - 1.3 +++ newbie.xml22 Nov 2002 02:45:22 - 1.4 @@ -48,6 +48,8 @@ lia href=#linkWhy does the lt;html:link tag URL-encode javascript and mailto links?/a/li +liWhy can't I disable URL-encoding in the Struts taglibs?/li + liWhen is the best time to validate input?/li liHow can I avoid validating a form before data is entered?/li 1.1 jakarta-struts/doc/faqs/netbeans.xml Index: netbeans.xml === ?xml version=1.0? document url=./ssl.xml properties authorJames Mitchell/author titleHow to setup struts in Netbeans IDE - Apache Struts/title /properties body chapter href=netbeans name=How to setup struts in Netbeans IDE section name=For working on the distribution itself ol li Create a new project (from the Project Manager window) /li li Download the struts source distribution (or use built-in cvs to get the module) /li li Extract to a local drive (if on windoze, try not to have spaces in the directory (such as C:\My Documents) /li li Mount the directory you unzipped to /li li Copy build.properties.sample to build.properties and customize to point to where you keep those jars /li li Mount each of the source directories that you wish to work in For me, I use:br / code jakarta-struts/src/sharebr / jakarta-struts/src/example /code /li li Mount each jar referenced in the build.properties filebr / bNote/b - NetBeans has built in support for auto-mounting these if your build.xml specifies the jars in the project.classpath, but that's not the case for the default struts distribution. /li /ol /section section name=For doing your own thing ol li Create a new project (from the Project Manager window) /li li Download (or build for yourself) the required jarsbr / (See the jakarta-struts-1.1-b2/webapps/struts-example.war) /li li Create a directory (I use a structure similar to how the webapp will exist) pre +-/my-project
RE: bloated docs? [was: cvs commit: jakarta-struts/doc/faqs netbeans.xmlproject.xml newbie.xml]
I don't think it's illegal to display screenshots of their product in this context. We're not getting any money for this :-). David From: James Mitchell [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: bloated docs? [was: cvs commit: jakarta-struts/doc/faqs netbeans.xml project.xml newbie.xml] Date: Fri, 22 Nov 2002 10:18:38 -0500 Yes Sir, you are correct as Mr Karr also pointed out. I'll be committing the complete tutorial later today or first thing tomorrow. So don't worry about changing it for now. As I'm hammering through these screenshots, I hate to think that I will single handedly increase the documentation by 2 Meg. I'm about 60% complete with NetBeans and about 30% with Eclipse. I was planning to add the same for JBuilder 6 Personal Edition, but not sure about legal issues with displaying their product (you would think that they would appreciate more coverage, who knows :/ ) Your thoughts? -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens? - Seymour Cray (1925-1996), father of supercomputing -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 10:06 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-struts/doc/faqs netbeans.xml project.xml newbie.xml I think you meant to say JNI instead of JNDI calls to the OS. It's a bit misleading to say it's fast as hell on Windows without mentioning that it runs on Linux as well. SWT is what Swing should have been. Native calls for OS supported widgets, java imitations for other widgets. Dave From: [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-struts/doc/faqs netbeans.xml project.xml newbie.xml Date: 22 Nov 2002 02:45:23 - husted 2002/11/21 18:45:23 Modified:doc/faqs project.xml newbie.xml Added: doc/faqs netbeans.xml Log: Add NetBeans howto by James Mitchell. Revision ChangesPath 1.4 +1 -0 jakarta-struts/doc/faqs/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-struts/doc/faqs/project.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- project.xml 17 Nov 2002 22:07:54 - 1.3 +++ project.xml 22 Nov 2002 02:45:22 - 1.4 @@ -12,6 +12,7 @@ /menu menu name=Howtos +item href=netbeans.html name=Netbeans/ item href=ssl.html name=SSL/ /menu 1.4 +2 -0 jakarta-struts/doc/faqs/newbie.xml Index: newbie.xml === RCS file: /home/cvs/jakarta-struts/doc/faqs/newbie.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- newbie.xml 6 Nov 2002 22:48:46 - 1.3 +++ newbie.xml 22 Nov 2002 02:45:22 - 1.4 @@ -48,6 +48,8 @@ lia href=#linkWhy does the lt;html:link tag URL-encode javascript and mailto links?/a/li +liWhy can't I disable URL-encoding in the Struts taglibs?/li + liWhen is the best time to validate input?/li liHow can I avoid validating a form before data is entered?/li 1.1 jakarta-struts/doc/faqs/netbeans.xml Index: netbeans.xml === ?xml version=1.0? document url=./ssl.xml properties authorJames Mitchell/author titleHow to setup struts in Netbeans IDE - Apache Struts/title /properties body chapter href=netbeans name=How to setup struts in Netbeans IDE section name=For working on the distribution itself ol li Create a new project (from the Project Manager window) /li li Download the struts source distribution (or use built-in cvs to get the module) /li li Extract to a local drive (if on windoze, try not to have spaces in the directory (such as C:\My Documents) /li li Mount the directory you unzipped to /li li Copy build.properties.sample to build.properties and customize to point to where you keep those jars /li li Mount each of the source directories that you wish to work in For me, I use:br / code jakarta-struts/src/sharebr / jakarta-struts/src/example /code /li li Mount each jar referenced in the build.properties filebr / bNote/b - NetBeans has built in support for auto-mounting these if your build.xml specifies the jars in the project.classpath, but that's not the case for the default struts distribution. /li /ol
pre-populated ActionForms / suggestion [patch] for beta1.1b2
[ posted to struts-user but i just realized struts-dev might be a better
place for this]
Hi there,
I'm trying to create a form with some pre-filled which either come from a
cookie or a database. i browsed the archive and found a comment from Craig
where he says the best way to do this is by routing the specified request
into a action and populate the form there. IMHO this way would complicate
the Actions execute method unnecessary complicat cause it must have a
action-case for prepopulate.
IMHO the best way to handle what i would want to do would be done like this.
1. introduce a prepare(HttpServletRequest request) method info
ActionForm
2. invoke this method in RequestUtils.createActionForm(...) right after
instance.setServlet(servlet) in line 638
inside the Forms prepare (populate or some other name) Method i could
prepare all fields like i want including setting values from session,
request, cookies, context, db, etc since i get the current request as a
method param.
dunno how to submit patches to struts but it would look something like this:
class: org.apache.struts.action.ActionForm
[snip]
/**
* Prepare the form before it gets displayed first.
* p
* The default implementation does nothing. Subclasses can
* override this method to insert values from a DB/Cookie into
* the form
*
* @param request The servlet request we are processing
*/
public void prepare(HttpServletRequest request) {
; // Default implementation does nothing
}
[/snip]
All forms written before this method would still work and it eases the work
of setting form values by cookies alot.
Comments welcome ...
thanks,
Thomas Heller
Date: Tue, 25 Jun 2002 20:17:35 -0400 (EDT)
From: Matt Barnicle [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Playing with cookies - How?
Thanks again, Chris. This helps me out a bit, but I'm still clueless on
how to take the cookie value to pre-populate the form. I know I could
come up with some way to rig it, like:
html:radio name=foo value=1
logic:equal name=mycookie property=value
value=1checked=checked
But that seems to defeat the usefulness of Struts, and I'm sure there's a
more appropriate way to do it. How?
This kind of syntax actually won't work anyway -- you cannot nest an XML
tag inside an attribute value.
IMHO, the best way to deal with situations like this is the same as any
other situation where you need to pre-populate a form -- route the
incoming request through an Action that pulls out whatever you need from
your cookies and uses it to populate beans that are later used by the JSP
page that you forward to.
The struts-example application uses this design pattern (although with a
database lookup instead of cookies) when you select the edit your
profile option. This is routed through the /editRegistration action,
which looks in the pseudo-database and prepopulates the form bean for the
registration form.
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: pre-populated ActionForms / suggestion [patch] for beta1.1b2
Thomas Heller wrote:
[ posted to struts-user but i just realized struts-dev might be a better
place for this]
... actually, it's a struts-user question.
Hi there,
I'm trying to create a form with some pre-filled which either come from a
cookie or a database. i browsed the archive and found a comment from Craig
where he says the best way to do this is by routing the specified request
into a action and populate the form there. IMHO this way would complicate
the Actions execute method unnecessary complicat cause it must have a
action-case for prepopulate.
That's the way it's done.
IMHO the best way to handle what i would want to do would be done like this.
1. introduce a prepare(HttpServletRequest request) method info
ActionForm
2. invoke this method in RequestUtils.createActionForm(...) right after
instance.setServlet(servlet) in line 638
Forms are just a conduit by which data is transferred from the user to
an action. In addition, you may wish to use the same form with
different actions (and have it contain different data). The forms
should be as stupid as possible - your suggestions don't allow that. Of
course, if you really insist on this behavior ... you have the source :-)
inside the Forms prepare (populate or some other name) Method i could
prepare all fields like i want including setting values from session,
request, cookies, context, db, etc since i get the current request as a
method param.
You can do that in your action :-) and since you can associate a form
with many different actions you have the flexibility to populate it in
different ways depending on the action that actually populates it ;-)
dunno how to submit patches to struts but it would look something like this:
http://issues.apache.org/bugzilla --- Our bug database. Create a bug
and then attach your code as a cvs diff -u.
class: org.apache.struts.action.ActionForm
[snip]
/**
* Prepare the form before it gets displayed first.
* p
* The default implementation does nothing. Subclasses can
* override this method to insert values from a DB/Cookie into
* the form
*
* @param request The servlet request we are processing
*/
public void prepare(HttpServletRequest request) {
; // Default implementation does nothing
}
[/snip]
All forms written before this method would still work and it eases the work
of setting form values by cookies alot.
I don't really see how it does anything but limit the use of the form.
You would have no additional functionality available to you in the
proposed prepare method compared to what you can do in an action's
execute method. Again, if you wish to make your forms so specfic,
there's nothing to keep you from doing it - the source if freely
available, and there's nothing that keeps you from modifying it to suit
your own needs.
Comments welcome ...
thanks,
Thomas Heller
--
Eddie Bush
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14730] - bean:write/ does not filter UK pound signs correctly
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=14730. 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=14730 bean:write/ does not filter UK pound signs correctly --- Additional Comments From [EMAIL PROTECTED] 2002-11-22 15:35 --- First, you should always use the -u option to diff when creating patches. It's just good form. Second, Is this really a good idea? Is the purpose of the ResponseUtils to escape every char? Will we end up with a case statement for every UniCode character? I'm just trying to be Devil's advocate. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: pre-populated ActionForms / suggestion [patch] for beta1.1b2
The best way to go about this is by creating an enhancement request in
bugzilla and attaching a patch to it, not just code. I think your idea is
interesting though :-).
David
From: Thomas Heller [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: pre-populated ActionForms / suggestion [patch] for beta1.1b2
Date: Fri, 22 Nov 2002 16:28:01 +0100
[ posted to struts-user but i just realized struts-dev might be a better
place for this]
Hi there,
I'm trying to create a form with some pre-filled which either come from a
cookie or a database. i browsed the archive and found a comment from Craig
where he says the best way to do this is by routing the specified request
into a action and populate the form there. IMHO this way would complicate
the Actions execute method unnecessary complicat cause it must have a
action-case for prepopulate.
IMHO the best way to handle what i would want to do would be done like
this.
1. introduce a prepare(HttpServletRequest request) method info
ActionForm
2. invoke this method in RequestUtils.createActionForm(...) right after
instance.setServlet(servlet) in line 638
inside the Forms prepare (populate or some other name) Method i could
prepare all fields like i want including setting values from session,
request, cookies, context, db, etc since i get the current request as a
method param.
dunno how to submit patches to struts but it would look something like
this:
class: org.apache.struts.action.ActionForm
[snip]
/**
* Prepare the form before it gets displayed first.
* p
* The default implementation does nothing. Subclasses can
* override this method to insert values from a DB/Cookie into
* the form
*
* @param request The servlet request we are processing
*/
public void prepare(HttpServletRequest request) {
; // Default implementation does nothing
}
[/snip]
All forms written before this method would still work and it eases the work
of setting form values by cookies alot.
Comments welcome ...
thanks,
Thomas Heller
Date: Tue, 25 Jun 2002 20:17:35 -0400 (EDT)
From: Matt Barnicle [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Playing with cookies - How?
Thanks again, Chris. This helps me out a bit, but I'm still clueless on
how to take the cookie value to pre-populate the form. I know I could
come up with some way to rig it, like:
html:radio name=foo value=1
logic:equal name=mycookie property=value
value=1checked=checked
But that seems to defeat the usefulness of Struts, and I'm sure there's
a
more appropriate way to do it. How?
This kind of syntax actually won't work anyway -- you cannot nest an XML
tag inside an attribute value.
IMHO, the best way to deal with situations like this is the same as any
other situation where you need to pre-populate a form -- route the
incoming request through an Action that pulls out whatever you need from
your cookies and uses it to populate beans that are later used by the JSP
page that you forward to.
The struts-example application uses this design pattern (although with a
database lookup instead of cookies) when you select the edit your
profile option. This is routed through the /editRegistration action,
which looks in the pseudo-database and prepopulates the form bean for the
registration form.
Craig
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14774] New: - Extra line in HTML when using tag html:javascript.
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=14774. 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=14774 Extra line in HTML when using tag html:javascript. Summary: Extra line in HTML when using tag html:javascript. Product: Struts Version: 1.1 Beta 2 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When we use tag 'javascript' in struts-html library in version 1.1-b2: html:javascript formName=logonForm dynamicJavascript=true staticJavascript=false/ an extra line is displayed in the HTML page // End -- We looked at source code and found that if we commented out one line in method 'getJavascriptEnd()' of class JavascriptValidatorTag in package org.apache.struts.taglib.html ... sb.append(// End --\n); ... the extra line disappears. Does any people have the same experience and what have been done? Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: pre-populated ActionForms / suggestion [patch] for beta1.1b2
On Fri, 22 Nov 2002, Thomas Heller wrote:
[ posted to struts-user but i just realized struts-dev might be a better
place for this]
Hi there,
I'm trying to create a form with some pre-filled which either come from a
cookie or a database. i browsed the archive and found a comment from Craig
where he says the best way to do this is by routing the specified request
into a action and populate the form there. IMHO this way would complicate
the Actions execute method unnecessary complicat cause it must have a
action-case for prepopulate.
IMHO the best way to handle what i would want to do would be done like this.
1. introduce a prepare(HttpServletRequest request) method info
ActionForm
2. invoke this method in RequestUtils.createActionForm(...) right after
instance.setServlet(servlet) in line 638
I agree with Eddie that you really should be doing this work in an action.
Even if you did have a prepare() method, this certainly isn't where you
would want it to be called, and there's nowhere else Struts could call it
that would make sense.
The problem with calling it here is that I really don't think you want to
be going through all the trouble of filling out the form fields right
before Struts overwrites them with the parameters of an incoming request.
Remember that form beans are created for you when a request comes in, and
your prepare() method would be called then too.
--
Martin Cooper
inside the Forms prepare (populate or some other name) Method i could
prepare all fields like i want including setting values from session,
request, cookies, context, db, etc since i get the current request as a
method param.
dunno how to submit patches to struts but it would look something like this:
class: org.apache.struts.action.ActionForm
[snip]
/**
* Prepare the form before it gets displayed first.
* p
* The default implementation does nothing. Subclasses can
* override this method to insert values from a DB/Cookie into
* the form
*
* @param request The servlet request we are processing
*/
public void prepare(HttpServletRequest request) {
; // Default implementation does nothing
}
[/snip]
All forms written before this method would still work and it eases the work
of setting form values by cookies alot.
Comments welcome ...
thanks,
Thomas Heller
Date: Tue, 25 Jun 2002 20:17:35 -0400 (EDT)
From: Matt Barnicle [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: Playing with cookies - How?
Thanks again, Chris. This helps me out a bit, but I'm still clueless on
how to take the cookie value to pre-populate the form. I know I could
come up with some way to rig it, like:
html:radio name=foo value=1
logic:equal name=mycookie property=value
value=1checked=checked
But that seems to defeat the usefulness of Struts, and I'm sure there's a
more appropriate way to do it. How?
This kind of syntax actually won't work anyway -- you cannot nest an XML
tag inside an attribute value.
IMHO, the best way to deal with situations like this is the same as any
other situation where you need to pre-populate a form -- route the
incoming request through an Action that pulls out whatever you need from
your cookies and uses it to populate beans that are later used by the JSP
page that you forward to.
The struts-example application uses this design pattern (although with a
database lookup instead of cookies) when you select the edit your
profile option. This is routed through the /editRegistration action,
which looks in the pseudo-database and prepopulates the form bean for the
registration form.
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
servletMapping field in ActionServlet (1.0.2)
Hi; I'm looking at the v1.0.2 ActionServlet's addServletMapping() method, and I'm noticing that it only handles the case where the ActionServlet has one servlet mapping associated with it. But it's legal (is it not?) to establish several servlet mappings for a Servlet under the 2.2 spec, right? In our case, we have an ActionServlet that is currently set up to handle several different paths. These paths are not really important to the Actions per se, but (depending on various factors) may be important for reporting purposes (i.e. did the person get into the website via path A, path B or path C, even though all will route him to ActionA). The Form tag seems to be the only Struts tag that uses the servletMapping attribute. Because the addServletMapping() method only ever takes the last mapping it finds, it will always look (if I'm reading the code right) like all requests that make use of the Form tag were submitted to path C. Is there a simple workaround for this, or should I look into submitting a patch? Or should I just not worry about it? :-) Thanks kindly and happy Friday. Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: pre-populated ActionForms / suggestion [patch] for beta1.1b2
On Fri, 22 Nov 2002, Martin Cooper wrote: Date: Fri, 22 Nov 2002 09:08:36 -0800 (PST) From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: pre-populated ActionForms / suggestion [patch] for beta1.1b2 On Fri, 22 Nov 2002, Thomas Heller wrote: [ posted to struts-user but i just realized struts-dev might be a better place for this] Hi there, I'm trying to create a form with some pre-filled which either come from a cookie or a database. i browsed the archive and found a comment from Craig where he says the best way to do this is by routing the specified request into a action and populate the form there. IMHO this way would complicate the Actions execute method unnecessary complicat cause it must have a action-case for prepopulate. IMHO the best way to handle what i would want to do would be done like this. 1. introduce a prepare(HttpServletRequest request) method info ActionForm 2. invoke this method in RequestUtils.createActionForm(...) right after instance.setServlet(servlet) in line 638 I agree with Eddie that you really should be doing this work in an action. Even if you did have a prepare() method, this certainly isn't where you would want it to be called, and there's nowhere else Struts could call it that would make sense. The problem with calling it here is that I really don't think you want to be going through all the trouble of filling out the form fields right before Struts overwrites them with the parameters of an incoming request. Remember that form beans are created for you when a request comes in, and your prepare() method would be called then too. I agree with Eddie and Martin that this is probably not a good idea, but for a different reason -- it would violate the layering of the MVC model. Remember that form beans are part of the View tier. Adding a prepare() method for the purposes you propose would typically involve interacting with the model (getting stuff from the database, applying business rules to decide what information to display, and so on. That kind of thing should really be done via an Action, which is why Struts encourages the current approach. -- Martin Cooper Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: servletMapping field in ActionServlet (1.0.2)
On Fri, 22 Nov 2002, Nelson, Laird wrote: Date: Fri, 22 Nov 2002 12:18:16 -0500 From: Nelson, Laird [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: servletMapping field in ActionServlet (1.0.2) Hi; I'm looking at the v1.0.2 ActionServlet's addServletMapping() method, and I'm noticing that it only handles the case where the ActionServlet has one servlet mapping associated with it. But it's legal (is it not?) to establish several servlet mappings for a Servlet under the 2.2 spec, right? It's definitely legal from the servlet spec perspective, but not from the Struts ActionServlet perspective. Struts currently does not know how to reliably compute URLs for things like html:form in the face of more than one mapping. In our case, we have an ActionServlet that is currently set up to handle several different paths. These paths are not really important to the Actions per se, but (depending on various factors) may be important for reporting purposes (i.e. did the person get into the website via path A, path B or path C, even though all will route him to ActionA). The Form tag seems to be the only Struts tag that uses the servletMapping attribute. Because the addServletMapping() method only ever takes the last mapping it finds, it will always look (if I'm reading the code right) like all requests that make use of the Form tag were submitted to path C. A subtle point needs to be remembered -- from the client viewpoint, the URL you *submit* to (i.e. the action) is what shows in the Location bar on a browser. Since the Action that is invoked can return an ActionForward to *any* page, the same URL can literally display anything. This applies to any scenario that uses RequestDispatcher.forward(), not just to Struts. More fundamentally, then, I would contend that the absolute value of a URL is totally meaningless in a web application based on an MVC architecture that uses RD.forward() the way Struts uses it. They are simply an internal implementation detail of the communication, and have no meaning in and of themselves. Web Applications != Web Sites Is there a simple workaround for this, or should I look into submitting a patch? Or should I just not worry about it? :-) There is not going to be a useful workaround for this -- it's fundamental to the nature of the architecture. Thanks kindly and happy Friday. Laird Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Velocity vs. JSP: objective tests?
I have settled on Struts as my application framework, assuming that there will continue to major shifts in the future (like the shift to 1.1 has been, which I like). However, I have not decided on the scripting language, if that is what you want to call it, viz. JSP vs. Velocity or some other choice. At the risk of engendering the passions of the committed, does anyone know an especially reliable guide to the pros and cons of the various choices? Micael --- This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: servletMapping field in ActionServlet (1.0.2)
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Struts currently does not know how to reliably compute URLs for things like html:form in the face of more than one mapping. OK. A subtle point needs to be remembered -- from the client viewpoint, the URL you *submit* to (i.e. the action) is what shows in the Location bar on a browser. Since the Action that is invoked can return an ActionForward to *any* page, the same URL can literally display anything. This applies to any scenario that uses RequestDispatcher.forward(), not just to Struts. Right. The reporting folks unfortunately have always attached--and continue to attach--great significance to said URL. We have grumbled and gotten around this problem by logging the page that is forwarded to as the request processing completes (in processActionForward() if I remember correctly). Not pretty, but satisfies the twin demons of architectural correctness on the one hand (what you are espousing here and what I agree with) and but-we've-already-firmed-up-the-URLs-and-this-is-how-it's-always-worked reporting requirements on the other. More fundamentally, then, I would contend that the absolute value of a URL is totally meaningless in a web application based on an MVC architecture that uses RD.forward() the way Struts uses it. I agree wholesale with you. That does not change the fact that unfortunately old habits die hard, especially where reporting and URL analysis is concerned. :-( Web Applications != Web Sites Agreed. There is not going to be a useful workaround for this -- it's fundamental to the nature of the architecture. OK. So not even an extra optional attribute on the form tag somewhere (Use servletPath X instead of servletPath Y), bearing in mind the limitations of our current reporting requirements? Is my company unique in trying to do things this way? Thanks for your time and help. Laird -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: pre-populated ActionForms / suggestion [patch] for beta1.1b2
Hi, I agree with Eddie and Martin that this is probably not a good idea, but for a different reason -- it would violate the layering of the MVC model. Remember that form beans are part of the View tier. Adding a prepare() method for the purposes you propose would typically involve interacting with the model (getting stuff from the database, applying business rules to decide what information to display, and so on. That kind of thing should really be done via an Action, which is why Struts encourages the current approach. -- Martin Cooper Craig I partly agree with you. I agree that forms should be inside the View tier, but IMHO the methods reset and validate are methods of business/controller logic. Ideally i have our webdesigners create all the forms as _very_ simple beans (just some getters and setters). wether the the received input is valid shouldnt be decided/checked by them instead i (controller) should do it. For example if i look at the current implementation of the struts-example.war I find an issue that should point out what i mean. If u take RegistrationForm.java and SaveRegistrationAction.java for example the forms validate method does a simple check wether both entered passwords match. now later in the Action there are some more tests (username unique, etc) and perhaps another ActionErrors instance is created. We now did a form-validate (Form) and the action again does some kind-of form-validation. maybe my suggested prepare method and the reset, validate method would fit better into the Action class as prepareForm, resetForm, validateForm. Thomas -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
I believe the Velocity site has a comparison to JSP. Of course, they like Velocity better. If it's important that new developers be productive immediately I would go with JSP because that's a java standard that they will already know. David From: micael [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Velocity vs. JSP: objective tests? Date: Fri, 22 Nov 2002 10:14:45 -0800 I have settled on Struts as my application framework, assuming that there will continue to major shifts in the future (like the shift to 1.1 has been, which I like). However, I have not decided on the scripting language, if that is what you want to call it, viz. JSP vs. Velocity or some other choice. At the risk of engendering the passions of the committed, does anyone know an especially reliable guide to the pros and cons of the various choices? Micael --- This electronic mail transmission and any accompanying documents contain information belonging to the sender which may be confidential and legally privileged. This information is intended only for the use of the individual or entity to whom this electronic mail transmission was sent as indicated above. If you are not the intended recipient, any disclosure, copying, distribution, or action taken in reliance on the contents of the information contained in this transmission is strictly prohibited. If you have received this transmission in error, please delete the message. Thank you -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Velocity vs. JSP: objective tests?
One thing that should be considered is not a technical issue. It's clear that the number of JSP developers is much larger than Velocity developers. That doesn't mean JSP is better than Velocity, but it means that people and training will be more portable when using JSP. Assuming that same population disparity, however, you can also assume that many Velocity developers will be at least somewhat familiar with JSP, but not as much the other way around. -Original Message- From: micael [mailto:[EMAIL PROTECTED]] I have settled on Struts as my application framework, assuming that there will continue to major shifts in the future (like the shift to 1.1 has been, which I like). However, I have not decided on the scripting language, if that is what you want to call it, viz. JSP vs. Velocity or some other choice. At the risk of engendering the passions of the committed, does anyone know an especially reliable guide to the pros and cons of the various choices? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Unverified Sender] RE: servletMapping field in ActionServlet (1.0.2)
-Original Message-
From: Nelson, Laird [mailto:[EMAIL PROTECTED]]
OK. So not even an extra optional attribute on the form tag
somewhere (Use
servletPath X instead of servletPath Y), bearing in mind the
limitations of
our current reporting requirements?
Following up my own message: or how about simply using the servlet path
instead of the servlet mapping when you're not using extension mapping?
Something like this (starting at line 713 in ...taglib.html.FormTag in the
getActionMappingURL() method; I changed the final else block as follows):
if (servletMapping.startsWith(*.)) {
value.append(actionMapping);
value.append(servletMapping.substring(1));
} else {
// In the case of path mapping, just use the servlet path,
// since we are guaranteed by the 2.2 spec that it will reflect
// the correct servlet mapping
value.append(pageContext.getRequest().getServletPath());
value.append(actionMapping);
}
(Warning: code is untested, but you get the idea.)
The basic gist is that if path mapping is in effect, use the servlet path
instead, because the servlet 2.2 specification, section 5.4, guarantees that
the servlet path will be what you want. Or, another way to put it is that
the servlet mapping is only really important when it's extension mapping, as
far as I can tell, since the servlet path will otherwise give you what you
want.
Cheers,
Laird
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: servletMapping field in ActionServlet (1.0.2)
On Fri, 22 Nov 2002, Nelson, Laird wrote: [snip] There is not going to be a useful workaround for this -- it's fundamental to the nature of the architecture. OK. So not even an extra optional attribute on the form tag somewhere (Use servletPath X instead of servletPath Y), bearing in mind the limitations of our current reporting requirements? Is my company unique in trying to do things this way? I suppose there actually is one way to influence the URLs to behave more like what reporting mechanisms would expect - use redirects instead of forwards. The costs of this are very high (cannot use request attributes to forward information to the view, and the time required for the extra round trip to the client), but you'd then have the JSP page URL, instead of the action URL, in your access logs. Your company is probably not unique in misunderstanding this -- but using the request URLs in a Struts-based app for reporting activity would be like using an irrelevant benchmark and believing that it told you anything useful about how *your* app will perform. You are just going to get misled. If you have folks willing to be convinced, it would not take a lot of effort to create a very simple little Struts app that had a single Action, which could return an ActionForward for any JSP page within the app. Run this app, and select each of the JSP pages in turn. Then, look at the access log and see that the requested URL was the same in every case. Then ask so why do you care so much about URLs? :-) Thanks for your time and help. Laird Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14780] New: - Utility class FIFO name value pair collection
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=14780.
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=14780
Utility class FIFO name value pair collection
Summary: Utility class FIFO name value pair collection
Product: Struts
Version: 1.1 Beta 2
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Other
Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
/**
* a collection to merge and support the differences in the way struts can
* handle collections for the purposes of html select option lists
*/
package org.apache.struts.util;
import java.util.Collection;
import java.util.Iterator;
import java.util.Set;
import org.apache.commons.beanutils.PropertyUtils;
/**
* this is a FIFO list designed for handling small sets for use in html
* select statements and is specifically designed to work with
* LabelValueBeans.
* @author Edgar P. Dollin
*/
class ObjectListElement implements java.io.Serializable {
/**
* the payload of the item
*/
protected Object element = null;
/**
* the next in the collection
*/
protected ObjectListElement next = null;
/**
* the prior element in the collection
*/
protected ObjectListElement prior = null;
/**
* get the value of the element in the collection
* @return the value of the payload
*/
public String getValue() {
if (element instanceof LabelValueBean)
return ((LabelValueBean) element).getValue();
return element.toString();
}
/**
* get the label value of the element
* @return the label of the payload
*/
public String getLabel() {
if (element instanceof LabelValueBean)
return ((LabelValueBean) element).getLabel();
return element.toString();
}
/**
* test if these are the same items
* @param o is the object to test equality against
* @return equality of the items
*/
public boolean equals(Object o) {
return element.equals(o);
}
}
/**
* class implements a FIFO set, library only has a LIFO set
* @author Edgar P. Dollin
*/
class IteratorFIFOList implements Iterator {
/**
* the position in the list
*/
private ObjectListElement position = null;
/**
* when we start the interator it is 'already' at the first item in
* the list
*/
private boolean alreadyFirst = true;
/**
* prevent random instantiation
*/
private IteratorFIFOList() { ; }
/**
* the constructor of the iterator
* @param o is the object to build the iterator for
*/
public IteratorFIFOList (LabelValueList o) {
position = o.first;
alreadyFirst = true;
}
/**
* the has next operation
* @return whether there is another item to be had in the set
*/
public boolean hasNext() {
if (position == null)
return false;
if (alreadyFirst == true) {
if (position == null)
return false;
else
return true;
}
if (position.next == null)
return false;
return true;
}
/**
* the next operation
* @return the next object in the set
*/
public Object next() {
if (alreadyFirst == true) {
alreadyFirst = false;
return position.element;
}
if (position != null)
position = position.next;
return position.element;
}
/**
* we don't need to remove but the spec says we do
*/
public void remove() {
}
}
/**
* the actual class implementation
* @author Edgar P. Dollin
*/
public class LabelValueList implements Set {
/**
* the first element in the collection
*/
protected ObjectListElement first = null;
/**
* the last element in the collection
*/
protected ObjectListElement last = null;
/**
* the number of items in the colleciton
*/
private int count = 0;
/**
* getter method for the the number of elements in the collection
* @return the count
*/
public int size() {
return count;
}
/**
* add the object on the end of the list
* @param o the object to add
* @return whether the object was added
*/
public boolean add(Object o) {
// defend against bad adds
if (o == null)
return false;
// skip duplications of LabelValueBeans
if (o instanceof LabelValueBean) {
for (ObjectListElement i = first; i != null; i = i.next) {
if (i.element
RE: Velocity vs. JSP: objective tests?
On Fri, 22 Nov 2002, Karr, David wrote:
Date: Fri, 22 Nov 2002 11:08:49 -0800
From: Karr, David [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: RE: Velocity vs. JSP: objective tests?
One thing that should be considered is not a technical issue.
I would say it is not *just* a technical issue. There's emotion, and
personal syntax likes/dislikes, involved as well.
It's clear that the number of JSP developers is much larger than
Velocity developers. That doesn't mean JSP is better than Velocity,
but it means that people and training will be more portable when using
JSP. Assuming that same population disparity, however, you can also
assume that many Velocity developers will be at least somewhat familiar
with JSP, but not as much the other way around.
I would not necessarily make the last assumption (that Velocity developers
are at least somewhat familiar with JSP) -- especially with the recent
changes like JSTL and JSP 2.0.
The first part of the decision process is fundamentally one of preferences
for the syntax. For example, here's a simple little loop example in
Velocity syntax and a couple approaches in JSP:
Velocity:
(Note -- it's assumed that the Customer collection has been stored in the
VelocityContext by some preceding business logic.)
#foreach $result in $results {
tr
td$result.ID/td
td$result.Name/td
/tr
}
JSP 1.1 (with Scriptlets):
=
%
Customer custs = ...;
for (int i=0; i custs.length; i++) {
%
tr
td%= custs[i].getId() %/td
td%= custs[i].getName() %/td
/tr
%
}
%
JSP 1.1 (with custom tags):
==
(Note -- it is assumed here and in the following examples that the
Customer collection has been stored by some preceding business logic.)
logic:iterate id=cust name=custs
tr
tdjsp:getProperty name=cust property=id//td
tdjsp:getProperty name=cust property=name//td
/tr
/logic:iterate
JSP 1.2 + JSTL 1.0:
==
c:forEach var=cust items=${custs}
tr
tdc:out value=${cust.id}//td
tdc:out value=${cust.name}//td
/tr
/c:forEach
JSP 2.0 + JSTL 1.0:
==
c:forEach var=cust items=${custs}
tr
td${cust.id}/td
td${cust.name}/td
/tr
/c:forEach
As you can see, JSP is evolving to the point where the same kinds of
things are just as succinct as Velocity. It comes down to whether you
think using XML/HTML style elements and attributes is the greatest thing
since sliced bread or the worst possible way to describe something.
Other issues that may be important to you:
* Velocity can be used in contexts other than web presentation.
You can use it for general text transformations with dynamic
content, similar in spirit to what XSLT lets you do, for example.
Sometimes it is convenient to only have to learn one syntax
for doing multiple things.
* It's quite possible that Velocity pages will render faster than
JSP pages if the JSP page compiler isn't very good (in Tomcat,
that means before the introduction of Jasper2).
* Velocity advocates used to argue that using Velocity was safer
because it restricted what a page designer could do to calling
getter methods. This was never a completely true argument
(how do *you* know that the getter method of the beans you are
calling doesn't mutate something?), but it's been pretty much
eliminated by the fact that you can call arbitrary methods
in Velocity.
There was an interesting article on onjava.com about a project to
implement a simple blogger app that used both Struts and Velocity:
http://www.onjava.com/pub/a/onjava/2002/04/17/wblogosj2ee.html
I was particularly struck by the following snippet of Velocity code:
$macros.showNavBar(true)
which builds part of the UI by rendering the navigation bar. I don't know
about you, but that looks an awful lot like a scriptlet equivalent:
% macros.showNavBar(true); %
to me :-).
At any rate, Velocity works just fine with Struts, if you choose to use
it. Ted's book (Struts in Action) has quite a bit of coverage of this.
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
11/22/2002 1:14:45 PM, micael [EMAIL PROTECTED] wrote: I have settled on Struts as my application framework, assuming that there will continue to major shifts in the future (like the shift to 1.1 has been, which I like). However, I have not decided on the scripting language, if that is what you want to call it, viz. JSP vs. Velocity or some other choice. At the risk of engendering the passions of the committed, does anyone know an especially reliable guide to the pros and cons of the various choices? Micael The best thing is to just try the alternate approaches and decide for yourself. Personally, I would agree with the other postings: the pro of JSP is that a lot of people already use it. =:0) Otherwise, in a MVC/Model 2 application, the two are technically equivalent. It's really not about which works best, it's about which works best for you. There's an simple register application at SourceForge that shows a couple of JSP and Velocity pages side-by-side. http://prdownloads.sourceforge.net/struts/logon-velocity.war? download Here's more sophisticated application that I'm working on now: http://prdownloads.sourceforge.net/wqdata/cpu_20021121.war? download No business logic yet, but you can see how things work. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Custom Actions? (was RE: Benefits of Dynaforms)
The idea behind a Struts Action is that it suppose to give you a place to call your business logic components. Rather than call various business processes through a subclass, I continue the decorator pattern by declaring the process to call as part of the ActionMapping. I then use a standard Action which automatically populates the designed business bean and invokes the business process. The business process returns a specialized result object that the standard Action analyzes. The result object has properties that can return messsages, data, and/or new routing instructions to the Action. Basically, I'm putting my business tier behind a facade, and using the ActionMapping decorator to tell the standard Action which operation to invoke. The facade provides a consistent interface and minimizes what the Struts tier needs to know about each operation. -Ted. 11/22/2002 9:47:43 AM, Andre Beskrowni [EMAIL PROTECTED] wrote: ok, this one sentence in ted's post caught my eye: I rarely write custom Actions any more. whoah. how is this possible? most of our web pages represent some sort of database operation: displaying, creating, updating, or deleting. i can see how you can minimize the amount of code that would vary in individual Action classes, but i don't see how could eliminate the need for subclassing altogether. maybe i'm just completely misunderstanding here. could you elaborate on your process? thanks, ab Ideally, a framework like Struts should just be passing gestures and data back and forth between the presentation pages and business tier. IMHO, doing any real programming in Struts is an engineering compromise. Architecturally, we should be trying to help developers avoid as many necessary evils as possible. DynaBeans serve that purpose by making it possible to avoid creating and maintaining yet-another Java class, which, in practice, often encroaches on the business tier. Before DynaBeans, that practice was unavoidable (or at least caused greater evils). With DynaBeans, there is a real possibility that you could code the Struts portion of an application entirely through XML configuration files, and keep all the real programming on the business tier. Here's another kicker: Components like the Validator aren't just for the web tier. You could also be using the Commons Validator in the business tier, which opens the door to a common Validator configuration shared by Struts and the business tier. DynaBeans also have the potential of being the missing buffer we need for data-entry. What about a DynaBean class that included a shadow String field with every dynamic property? (All we need is another map.) If we integrated a DynaBeanBuffer subclass with the Validator, we could then declare field-level validations for our properties. A validate method on the DynaBean could check each of its buffers, and transfer the datea if validation passed, but raise a flag if it didn't. We could then finally use the same bean on the Web tier as we do on the business tier. This sort of thing is a bear to code with conventional JavaBean, but might be worth doing with something like the DynaBean. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:struts-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:struts-dev- [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
David said: I believe the Velocity site has a comparison to JSP. Of course, they like Velocity better. If it's important that new developers be productive immediately I would go with JSP because that's a java standard that they will already know. also, if you haven't already, be sure you look into the Velocity Tools subproject. a fair bit of work has already been done there to integrate Struts and Velocity. personally, i use the two together and am really enjoying the process. i'm of the lucky few :) that has had almost no experience with JSP, so i'm no doubt a little biased, but i don't think you need to worry about time spent learning Velocity. it's really quite small and simple; the basics can be picked up quickly. if you want to do JSP well, you can easily spend more time learning taglibs (unless you already know them of course). one thing that may ease your concern is that with the Velocity Tools project, it is quite easy to use both Velocity and JSP side by side. there are examples included there for that. also, the Veltag allows you to use Velocity right inside JSP (link below). the one drawback you should be aware of for Struts+Velocity is that not as many people do it yet, and there's not exactly prodigous amounts of documentation or examples floating around yet. the Velocity Tools stuff is a good start though, and if you look into it, be aware that much of the documentation for tool management and such is mostly in the javadocs right now. here's some links that may be of interest to you: Gabe Sidler's docs on Velocity+Struts: http://www.teamup.com/jakarta-velocity-tools/struts/docs/index.html Velocity Tools home: http://jakarta.apache.org/velocity/toolsubproject.html Veltag: http://jakarta.apache.org/velocity/veltag.html Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14780] - Utility class FIFO name value pair collection
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=14780. 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=14780 Utility class FIFO name value pair collection --- Additional Comments From [EMAIL PROTECTED] 2002-11-22 20:53 --- Can you please describe how to use all these classes and how they're helpful? In the future don't paste the code into the bugzilla message, just attach it to the report so we can download it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
Craig said:
...
For example, here's a simple little loop example in
Velocity syntax and a couple approaches in JSP:
Velocity:
(Note -- it's assumed that the Customer collection has been stored in the
VelocityContext by some preceding business logic.)
actually, if you are using the Velocity/Struts support in the Velocity Tools
project, the recommended pattern is to define a set of tools in an xml
config. these will then be automatically placed in the template's Context
and available for you to pull the needed data. there are other ways of
getting objects into the template still, but i don't have time to detail
them here. see the docs concerning the VelocityViewServlet for that. oh,
and Jon Stevens does a good job of explaining the Pull MVC Model here:
http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
#foreach $result in $results {
tr
td$result.ID/td
td$result.Name/td
/tr
}
actually, this is syntax is almost completely wrong. :)
a more fitting example would be:
#foreach( $result in $sometool.results )
tr
td$result.ID/td
td$result.Name/td
/tr
#end
velocity and it's supporting tools are evolving too. :-)
...
* Velocity advocates used to argue that using Velocity was safer
because it restricted what a page designer could do to calling
getter methods. This was never a completely true argument
(how do *you* know that the getter method of the beans you are
calling doesn't mutate something?), but it's been pretty much
eliminated by the fact that you can call arbitrary methods
in Velocity.
yes, it is possible to design badly even in Velocity, but perhaps we could
agree it's at least harder in Velocity to do so.
...
There was an interesting article on onjava.com about a project to
implement a simple blogger app that used both Struts and Velocity:
http://www.onjava.com/pub/a/onjava/2002/04/17/wblogosj2ee.html
I was particularly struck by the following snippet of Velocity code:
$macros.showNavBar(true)
which builds part of the UI by rendering the navigation bar. I don't know
about you, but that looks an awful lot like a scriptlet equivalent:
% macros.showNavBar(true); %
to me :-).
yeah, no offense intended to David Johnson, but that's a really poor way to
use Velocity. it looks as though that method is intended to spit out some
HTML hardcoded into whatever $macros is or some such thing. the HTML
shouldn't come from the java, it should be in the template to begin with, or
at least defined the global Velocimacro library. that way the code could
just be:
#showNavBar( true)
anyway, i hope i'm not coming off too argumentative, it's just that these
are poor examples of using velocity. i wouldn't want people to get the
wrong idea. :)
Nathan Bubna
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: RE: servletMapping field in ActionServlet (1.0.2)
11/22/2002 1:26:45 PM, Nelson, Laird [EMAIL PROTECTED] wrote: Is my company unique in trying to do things this way? Probably not, but Struts hasn't been trying to be all things to all people. =:0) It does what the people working on it need it to do, and if it doesn't do what we need, then we work to change it. But we're not sitting around a whiteboard trying to figure out the best way to capture market share. Struts does restrict what URIs you can map to an Action. The underlying issue, as Craig pointed out, is that the Action path is not a truly logical identifier. It's a hash based on the URI that Struts munged and demunges. There are of course other ways we could link up actions and URIs, but that would be something we'd explore in the Struts 2.0 frame. -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Struts logo
Hi, That's not an important question but does the Struts logo was final ? ... if no, what about organize a Struts Logo Competition like other Jakarta project ;) -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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Velocity vs. JSP: objective tests?
See comments below...
yeah, no offense intended to David Johnson, but that's a
really poor way to use Velocity. it looks as though that
method is intended to spit out some HTML hardcoded into
whatever $macros is or some such thing. the HTML shouldn't
come from the java, it should be in the template to begin
with, or at least defined the global Velocimacro library.
that way the code could just be:
#showNavBar( true)
anyway, i hope i'm not coming off too argumentative, it's
just that these are poor examples of using velocity. i
wouldn't want people to get the wrong idea. :)
As I am a committer on the Roller project - I'm curious to know what a
better way of implementing this would be. We do want Roller to be a
best-practices examples - so any advice is appreciated!
Thanks,
Matt
-Original Message-
From: Nathan Bubna [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 22, 2002 2:12 PM
To: Struts Developers List
Subject: Re: Velocity vs. JSP: objective tests?
Craig said:
...
For example, here's a simple little loop example in
Velocity syntax and a couple approaches in JSP:
Velocity:
(Note -- it's assumed that the Customer collection has been
stored in
the VelocityContext by some preceding business logic.)
actually, if you are using the Velocity/Struts support in the
Velocity Tools project, the recommended pattern is to define
a set of tools in an xml config. these will then be
automatically placed in the template's Context and available
for you to pull the needed data. there are other ways of
getting objects into the template still, but i don't have
time to detail them here. see the docs concerning the
VelocityViewServlet for that. oh, and Jon Stevens does a
good job of explaining the Pull MVC Model here:
http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
#foreach $result in $results {
tr
td$result.ID/td
td$result.Name/td
/tr
}
actually, this is syntax is almost completely wrong. :)
a more fitting example would be:
#foreach( $result in $sometool.results )
tr
td$result.ID/td
td$result.Name/td
/tr
#end
velocity and it's supporting tools are evolving too. :-)
...
* Velocity advocates used to argue that using Velocity was safer
because it restricted what a page designer could do to calling
getter methods. This was never a completely true argument
(how do *you* know that the getter method of the beans you are
calling doesn't mutate something?), but it's been pretty much
eliminated by the fact that you can call arbitrary methods
in Velocity.
yes, it is possible to design badly even in Velocity, but
perhaps we could agree it's at least harder in Velocity to do so.
...
There was an interesting article on onjava.com about a project to
implement a simple blogger app that used both Struts and Velocity:
http://www.onjava.com/pub/a/onjava/2002/04/17/wblogosj2ee.html
I was particularly struck by the following snippet of Velocity code:
$macros.showNavBar(true)
which builds part of the UI by rendering the navigation
bar. I don't
know about you, but that looks an awful lot like a scriptlet
equivalent:
% macros.showNavBar(true); %
to me :-).
yeah, no offense intended to David Johnson, but that's a
really poor way to use Velocity. it looks as though that
method is intended to spit out some HTML hardcoded into
whatever $macros is or some such thing. the HTML shouldn't
come from the java, it should be in the template to begin
with, or at least defined the global Velocimacro library.
that way the code could just be:
#showNavBar( true)
anyway, i hope i'm not coming off too argumentative, it's
just that these are poor examples of using velocity. i
wouldn't want people to get the wrong idea. :)
Nathan Bubna
[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:struts-dev- [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: Velocity vs. JSP: objective tests?
On Fri, 22 Nov 2002, Nathan Bubna wrote:
Date: Fri, 22 Nov 2002 13:12:19 -0800
From: Nathan Bubna [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Velocity vs. JSP: objective tests?
Craig said:
...
For example, here's a simple little loop example in
Velocity syntax and a couple approaches in JSP:
Velocity:
(Note -- it's assumed that the Customer collection has been stored in the
VelocityContext by some preceding business logic.)
actually, if you are using the Velocity/Struts support in the Velocity Tools
project, the recommended pattern is to define a set of tools in an xml
config. these will then be automatically placed in the template's Context
and available for you to pull the needed data. there are other ways of
getting objects into the template still, but i don't have time to detail
them here. see the docs concerning the VelocityViewServlet for that. oh,
and Jon Stevens does a good job of explaining the Pull MVC Model here:
http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
#foreach $result in $results {
tr
td$result.ID/td
td$result.Name/td
/tr
}
actually, this is syntax is almost completely wrong. :)
a more fitting example would be:
#foreach( $result in $sometool.results )
tr
td$result.ID/td
td$result.Name/td
/tr
#end
velocity and it's supporting tools are evolving too. :-)
Sorry ... I was following an example from a published article (don't
remember where) so I presume that it (at least) *used* to be correct :-0.
...
* Velocity advocates used to argue that using Velocity was safer
because it restricted what a page designer could do to calling
getter methods. This was never a completely true argument
(how do *you* know that the getter method of the beans you are
calling doesn't mutate something?), but it's been pretty much
eliminated by the fact that you can call arbitrary methods
in Velocity.
yes, it is possible to design badly even in Velocity, but perhaps we could
agree it's at least harder in Velocity to do so.
Harder != Impossible.
This used to be the most compelling pro-Velocity argument, IMHO,
especially for people managing large content-rich web sites where you
really don't want a page author to be able to totally screw things up by
executing arbitarry code. General method calls are very convenient (and
they're in JSP 2.0's version of the expression language as well :-), but
there is no longer a difference in this regard.
...
There was an interesting article on onjava.com about a project to
implement a simple blogger app that used both Struts and Velocity:
http://www.onjava.com/pub/a/onjava/2002/04/17/wblogosj2ee.html
I was particularly struck by the following snippet of Velocity code:
$macros.showNavBar(true)
which builds part of the UI by rendering the navigation bar. I don't know
about you, but that looks an awful lot like a scriptlet equivalent:
% macros.showNavBar(true); %
to me :-).
yeah, no offense intended to David Johnson, but that's a really poor way to
use Velocity. it looks as though that method is intended to spit out some
HTML hardcoded into whatever $macros is or some such thing. the HTML
shouldn't come from the java, it should be in the template to begin with, or
at least defined the global Velocimacro library. that way the code could
just be:
#showNavBar( true)
Fine ... still looks like a scriptlet to me :-).
It's very reasonable to have a preference for one kind of syntax over the
other. And it's probably fine to make a choice between the two solely, or
primarily, on this basis. I just get amused by people who contend that
the relatively minor syntax differences are fundamental technical
discriminators between two architectures.
anyway, i hope i'm not coming off too argumentative, it's just that these
are poor examples of using velocity. i wouldn't want people to get the
wrong idea. :)
Nah, we're just having a reasonable discussion, unlike some of the more
adamant Velocity advocates :-).
Actually, Ted's Struts book (Struts In Action) devotes an entire chapter
to using Velocity and Struts together, including how VelocityViewServlet
helps you out. It would make a pretty good starting point for people
interested in learning how to combine them.
Nathan Bubna
[EMAIL PROTECTED]
Craig
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts logo
On Fri, 22 Nov 2002, Emmanuel Boudrant wrote: Date: Fri, 22 Nov 2002 22:30:53 +0100 (CET) From: Emmanuel Boudrant [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Struts logo Hi, That's not an important question but does the Struts logo was final ? ... if no, what about organize a Struts Logo Competition like other Jakarta project ;) +1 from me. I'm not an artist by any stretch of the imagination, so I won't be entering any proposals, but I'll sure enjoy seeing the results. The only potential caveat would be that any selected submission would need to be publishable under the standard ASF license agreement (same as the code and the docs). -emmanuel Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Velocity vs. JSP: objective tests?
On Fri, 22 Nov 2002, Matt Raible wrote: Date: Fri, 22 Nov 2002 14:38:02 -0700 From: Matt Raible [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Velocity vs. JSP: objective tests? See comments below... yeah, no offense intended to David Johnson, but that's a really poor way to use Velocity. it looks as though that method is intended to spit out some HTML hardcoded into whatever $macros is or some such thing. the HTML shouldn't come from the java, it should be in the template to begin with, or at least defined the global Velocimacro library. that way the code could just be: #showNavBar( true) anyway, i hope i'm not coming off too argumentative, it's just that these are poor examples of using velocity. i wouldn't want people to get the wrong idea. :) As I am a committer on the Roller project - I'm curious to know what a better way of implementing this would be. We do want Roller to be a best-practices examples - so any advice is appreciated! It would also be an interesting experiment to see how people would approach this with JSP (and probably using Tiles for the standard layout stuff). Thanks, Matt Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
I've always found it amusing that people are worried about page authors
totally screwing up the application by executing arbitrary code. Who are
these rogue page authors you're hiring that will destroy your app?
We can't pass anything but a value bean with read only properties to this
idiot page designers or they'll screw us!.
I'm not implying that this is your view Craig, I have heard architects use
this argument before though.
David
From: Craig R. McClanahan [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Velocity vs. JSP: objective tests?
Date: Fri, 22 Nov 2002 13:47:48 -0800 (PST)
On Fri, 22 Nov 2002, Nathan Bubna wrote:
Date: Fri, 22 Nov 2002 13:12:19 -0800
From: Nathan Bubna [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Subject: Re: Velocity vs. JSP: objective tests?
Craig said:
...
For example, here's a simple little loop example in
Velocity syntax and a couple approaches in JSP:
Velocity:
(Note -- it's assumed that the Customer collection has been stored in
the
VelocityContext by some preceding business logic.)
actually, if you are using the Velocity/Struts support in the Velocity
Tools
project, the recommended pattern is to define a set of tools in an xml
config. these will then be automatically placed in the template's
Context
and available for you to pull the needed data. there are other ways
of
getting objects into the template still, but i don't have time to detail
them here. see the docs concerning the VelocityViewServlet for that.
oh,
and Jon Stevens does a good job of explaining the Pull MVC Model here:
http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
#foreach $result in $results {
tr
td$result.ID/td
td$result.Name/td
/tr
}
actually, this is syntax is almost completely wrong. :)
a more fitting example would be:
#foreach( $result in $sometool.results )
tr
td$result.ID/td
td$result.Name/td
/tr
#end
velocity and it's supporting tools are evolving too. :-)
Sorry ... I was following an example from a published article (don't
remember where) so I presume that it (at least) *used* to be correct :-0.
...
* Velocity advocates used to argue that using Velocity was safer
because it restricted what a page designer could do to calling
getter methods. This was never a completely true argument
(how do *you* know that the getter method of the beans you are
calling doesn't mutate something?), but it's been pretty much
eliminated by the fact that you can call arbitrary methods
in Velocity.
yes, it is possible to design badly even in Velocity, but perhaps we
could
agree it's at least harder in Velocity to do so.
Harder != Impossible.
This used to be the most compelling pro-Velocity argument, IMHO,
especially for people managing large content-rich web sites where you
really don't want a page author to be able to totally screw things up by
executing arbitarry code. General method calls are very convenient (and
they're in JSP 2.0's version of the expression language as well :-), but
there is no longer a difference in this regard.
...
There was an interesting article on onjava.com about a project to
implement a simple blogger app that used both Struts and Velocity:
http://www.onjava.com/pub/a/onjava/2002/04/17/wblogosj2ee.html
I was particularly struck by the following snippet of Velocity code:
$macros.showNavBar(true)
which builds part of the UI by rendering the navigation bar. I don't
know
about you, but that looks an awful lot like a scriptlet equivalent:
% macros.showNavBar(true); %
to me :-).
yeah, no offense intended to David Johnson, but that's a really poor way
to
use Velocity. it looks as though that method is intended to spit out
some
HTML hardcoded into whatever $macros is or some such thing. the HTML
shouldn't come from the java, it should be in the template to begin
with, or
at least defined the global Velocimacro library. that way the code
could
just be:
#showNavBar( true)
Fine ... still looks like a scriptlet to me :-).
It's very reasonable to have a preference for one kind of syntax over the
other. And it's probably fine to make a choice between the two solely, or
primarily, on this basis. I just get amused by people who contend that
the relatively minor syntax differences are fundamental technical
discriminators between two architectures.
anyway, i hope i'm not coming off too argumentative, it's just that
these
are poor examples of using velocity. i wouldn't want people to get the
wrong idea. :)
Nah, we're just having a reasonable discussion, unlike some of the more
adamant Velocity advocates :-).
Actually, Ted's Struts book (Struts In Action) devotes an entire chapter
to using Velocity and Struts together,
Re: Struts logo
+1 I've always thought the logo could be a bit flashier. How would we pick the winner? A vote by the committers? David From: Emmanuel Boudrant [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Struts logo Date: Fri, 22 Nov 2002 22:30:53 +0100 (CET) Hi, That's not an important question but does the Struts logo was final ? ... if no, what about organize a Struts Logo Competition like other Jakarta project ;) -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:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
On Fri, 22 Nov 2002, David Graham wrote: Date: Fri, 22 Nov 2002 14:55:55 -0700 From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Velocity vs. JSP: objective tests? I've always found it amusing that people are worried about page authors totally screwing up the application by executing arbitrary code. Who are these rogue page authors you're hiring that will destroy your app? We can't pass anything but a value bean with read only properties to this idiot page designers or they'll screw us!. I'm not implying that this is your view Craig, I have heard architects use this argument before though. It is, in fact, not a big concern of mine. It's one of the arguments that Velocity advocates originally made, and is also one of things people like Jason Hunter like about Tea (which is now on SF at http://teatrove.sourceforge.net). See Jason's thoughts about Tea on his website http://www.servlets.com and the 2nd edition of Java Servlet Programming. The concern, as I understand it, is not so much about deliberately malicious page developers, but those that make errors that are not caught prior to production deployment, which result in things like stack traces shown to the end user. David Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
Matt said: See comments below... yeah, no offense intended to David Johnson, but that's a really poor way to use Velocity. it looks as though that method is intended to spit out some HTML hardcoded into whatever $macros is or some such thing. the HTML shouldn't come from the java, it should be in the template to begin with, or at least defined the global Velocimacro library. that way the code could just be: #showNavBar( true) anyway, i hope i'm not coming off too argumentative, it's just that these are poor examples of using velocity. i wouldn't want people to get the wrong idea. :) As I am a committer on the Roller project - I'm curious to know what a better way of implementing this would be. We do want Roller to be a best-practices examples - so any advice is appreciated! Velocimacros are what you want. you can create a specify a library template of velocimacros in your velocity.properties that would be available to all your templates. see http://jakarta.apache.org/velocity/user-guide.html#Velocimacros this provides some nice encapsulation to avoid both hard-coding html or xml or whatever and yet not have to copy-paste or retype the same stuff every time. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
Craig said: ... Sorry ... I was following an example from a published article (don't remember where) so I presume that it (at least) *used* to be correct :-0. yeah, it may have been right (or closer) once, but not since at least two years ago (when i started using velocity). ... * Velocity advocates used to argue that using Velocity was safer because it restricted what a page designer could do to calling getter methods. This was never a completely true argument (how do *you* know that the getter method of the beans you are calling doesn't mutate something?), but it's been pretty much eliminated by the fact that you can call arbitrary methods in Velocity. yes, it is possible to design badly even in Velocity, but perhaps we could agree it's at least harder in Velocity to do so. Harder != Impossible. yep, that's what i said. we agree then! :) ... There was an interesting article on onjava.com about a project to implement a simple blogger app that used both Struts and Velocity: http://www.onjava.com/pub/a/onjava/2002/04/17/wblogosj2ee.html I was particularly struck by the following snippet of Velocity code: $macros.showNavBar(true) which builds part of the UI by rendering the navigation bar. I don't know about you, but that looks an awful lot like a scriptlet equivalent: % macros.showNavBar(true); % to me :-). yeah, no offense intended to David Johnson, but that's a really poor way to use Velocity. it looks as though that method is intended to spit out some HTML hardcoded into whatever $macros is or some such thing. the HTML shouldn't come from the java, it should be in the template to begin with, or at least defined the global Velocimacro library. that way the code could just be: #showNavBar( true) Fine ... still looks like a scriptlet to me :-). looks can be deceiving! with a proper velocimacro, the HTML isn't hard-coded into java classes. that may not be important to some folks, but it is to me. i think it goes a long way toward *encouraging* good MVC separation. it's not just a matter of syntax, but of design philosophy as well. ... Actually, Ted's Struts book (Struts In Action) devotes an entire chapter to using Velocity and Struts together, including how VelocityViewServlet helps you out. It would make a pretty good starting point for people interested in learning how to combine them. yeah, i haven't gotten to see it, but i heard he talked about the Velocity+Struts stuff in it. i'm hoping it gets more people looking into and/or using that code. i think there's some good potential there, but progress has kinda plateaued lately. it could use some fresh users/contributers to prod things along. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
David Graham wrote: I've always found it amusing that people are worried about page authors totally screwing up the application by executing arbitrary code. Who are these rogue page authors you're hiring that will destroy your app? What if, for example, you have an e-Commerce catalog and you want to allow ordinary users to edit the catalog item page templates through a web interface. If you Do you really want ordinary catalog users to be able to execute arbitrary code from these page templates? I don't think so. Using JSP for the user-editable page templates is really not an option in this case. Wouldn't you agree? - Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
JSP wouldn't be an option anyways because ordinary users wouldn't understand it. The vast majority of situations are not like the one you describe. David From: Dave Johnson [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Velocity vs. JSP: objective tests? Date: Fri, 22 Nov 2002 17:53:28 -0500 David Graham wrote: I've always found it amusing that people are worried about page authors totally screwing up the application by executing arbitrary code. Who are these rogue page authors you're hiring that will destroy your app? What if, for example, you have an e-Commerce catalog and you want to allow ordinary users to edit the catalog item page templates through a web interface. If you Do you really want ordinary catalog users to be able to execute arbitrary code from these page templates? I don't think so. Using JSP for the user-editable page templates is really not an option in this case. Wouldn't you agree? - Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
David Graham wrote: JSP wouldn't be an option anyways because ordinary users wouldn't understand it. The vast majority of situations are not like the one you describe. You are correct. More imporantly, if you are choosing between JSP and Velocity as your Struts View technology then the scenario that I cited is irrelevant. - Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity vs. JSP: objective tests?
On Fri, 22 Nov 2002, Nathan Bubna wrote: [big snip] #showNavBar( true) Fine ... still looks like a scriptlet to me :-). looks can be deceiving! with a proper velocimacro, the HTML isn't hard-coded into java classes. that may not be important to some folks, but it is to me. i think it goes a long way toward *encouraging* good MVC separation. it's not just a matter of syntax, but of design philosophy as well. A similar feature is part of JSP 2.0, by the way. A page author can point at a chunk of JSP code (rather than Java) and create a reusable widget, optionally with parameters, which the JSP compiler essentially turns into a custom tag automatically. The page author using the widget invokes it just like any other custom tag. Among other things, this supports the kind of separation you suggest. Nathan Bubna [EMAIL PROTECTED] Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Roller-development] RE: Velocity vs. JSP: objective tests?
No offence taken, but I do have some comments, which are below... yeah, no offense intended to David Johnson, but that's a really poor way to use Velocity. it looks as though that method is intended to spit out some HTML hardcoded into whatever $macros is or some such thing. the HTML shouldn't come from the java, it should be in the template to begin with, or at least defined the global Velocimacro library. that way the code could just be: #showNavBar( true) anyway, i hope i'm not coming off too argumentative, it's just that these are poor examples of using velocity. i wouldn't want people to get the wrong idea. :) In the case of the NavBar, there was an existing JSP NavBar tag and I wanted to use that NavBar from Velocity. In general, I think you (whoever you are) are correct: the Velocity template (or a Velocity macro) should be responsible for creating the HTML based on the model objects that have been placed into the context. If we want to follow your advice in Roller development, we should stop adding HTML generation methods to our $macros object. Instead we should put the right objects into the Velocity context and let Velocity do the rendering, possibly by calling upon Velocity macros. It would also be an interesting experiment to see how people would approach this with JSP (and probably using Tiles for the standard layout stuff). I' not sure how you would do user-editable weblog page templates using JSP, that is why I did it using Velocity. I don't think you want users editing JSP templates, in fact you don't even want them to be able to access the request and response objects - it's just too dangerous. - Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Roller-development] RE: Velocity vs. JSP: objective tests?
Dave said: No offence taken, but I do have some comments, which are below... yeah, no offense intended to David Johnson, but that's a really poor way to use Velocity. it looks as though that method is intended to spit out some HTML hardcoded into whatever $macros is or some such thing. the HTML shouldn't come from the java, it should be in the template to begin with, or at least defined the global Velocimacro library. that way the code could just be: #showNavBar( true) anyway, i hope i'm not coming off too argumentative, it's just that these are poor examples of using velocity. i wouldn't want people to get the wrong idea. :) In the case of the NavBar, there was an existing JSP NavBar tag and I wanted to use that NavBar from Velocity. In general, I think you (whoever you are) are correct: the Velocity template (or a Velocity macro) should be responsible for creating the HTML based on the model objects that have been placed into the context. [snip] yeah, i had a feeling it was something like that. i can see that that is useful for initial development, but unless you have some real need to keep that HTML output always in sync with the NavBar tag, i think it would be best to move away from that as you continue to develop the product. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts logo
+1 from me. I'm not an artist by any stretch of the imagination, so I won't be entering any proposals, but I'll sure enjoy seeing the results. Neither am I, but here's a few http://www.open-tools.org/struts-atlanta/images/new-logos/ I prefer the last one, but we might have a few legal issues to tackle first. The only potential caveat would be that any selected submission would need to be publishable under the standard ASF license agreement (same as the code and the docs). -emmanuel Craig -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens? - Seymour Cray (1925-1996), father of supercomputing -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 14774] - Extra line in HTML when using tag html:javascript.
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=14774. 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=14774 Extra line in HTML when using tag html:javascript. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-11-23 05:28 --- This was fixed about 5 weeks ago. Download the latest nightly build. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts logo
LOL, that last one was great. Thanks, David From: James Mitchell [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: Struts logo Date: Fri, 22 Nov 2002 23:36:29 -0500 +1 from me. I'm not an artist by any stretch of the imagination, so I won't be entering any proposals, but I'll sure enjoy seeing the results. Neither am I, but here's a few http://www.open-tools.org/struts-atlanta/images/new-logos/ I prefer the last one, but we might have a few legal issues to tackle first. The only potential caveat would be that any selected submission would need to be publishable under the standard ASF license agreement (same as the code and the docs). -emmanuel Craig -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens? - Seymour Cray (1925-1996), father of supercomputing -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail -- 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/logic ForwardTag.java
rleland 2002/11/22 22:31:23
Modified:src/share/org/apache/struts/taglib/logic ForwardTag.java
Log:
Bug 13613 Make Forward Tag Module aware.
Reported and patched by
[EMAIL PROTECTED] (Jim Bonanno)
Thanks !
Revision ChangesPath
1.13 +10 -4
jakarta-struts/src/share/org/apache/struts/taglib/logic/ForwardTag.java
Index: ForwardTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/logic/ForwardTag.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ForwardTag.java 9 Nov 2002 16:30:02 - 1.12
+++ ForwardTag.java 23 Nov 2002 06:31:23 - 1.13
@@ -147,6 +147,12 @@
// Forward or redirect to the corresponding actual path
String path = forward.getPath();
+// support modules
+if (config != null) {
+path = config.getPrefix() + path;
+}
+
+
if (forward.getRedirect()) {
HttpServletRequest request =
(HttpServletRequest) pageContext.getRequest();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 13613] - Logic ForwardTag does not support sub apps
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=13613. 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=13613 Logic ForwardTag does not support sub apps [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-11-23 06:33 --- Fixed in 20021124 Nightly. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts logo
I agree but overall very original ;-}... -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 11:36 PM To: Struts Developers List Subject: RE: Struts logo +1 from me. I'm not an artist by any stretch of the imagination, so I won't be entering any proposals, but I'll sure enjoy seeing the results. Neither am I, but here's a few http://www.open-tools.org/struts-atlanta/images/new-logos/ I prefer the last one, but we might have a few legal issues to tackle first. The only potential caveat would be that any selected submission would need to be publishable under the standard ASF license agreement (same as the code and the docs). -emmanuel Craig -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens? - Seymour Cray (1925-1996), father of supercomputing -- 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]
