cvs commit: jakarta-struts/src/share/org/apache/struts/plugins DigestingPlugIn.java
dgraham 2003/08/06 21:01:41
Added: src/share/org/apache/struts/plugins DigestingPlugIn.java
Log:
Added DigestingPlugIn from PR# 18127.
Revision ChangesPath
1.1
jakarta-struts/src/share/org/apache/struts/plugins/DigestingPlugIn.java
Index: DigestingPlugIn.java
===
/*
* $Header$
* $Revision$
* $Date$
*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names The Jakarta Project, Struts, and Apache Software
*Foundation must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.struts.plugins;
import java.io.File;
import java.io.IOException;
import java.net.URL;
import javax.servlet.ServletException;
import org.apache.commons.digester.Digester;
import org.apache.commons.digester.RuleSet;
import org.apache.commons.digester.xmlrules.DigesterLoader;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.struts.action.ActionServlet;
import org.apache.struts.action.PlugIn;
import org.apache.struts.config.ModuleConfig;
import org.apache.struts.util.RequestUtils;
import org.xml.sax.SAXException;
/**
* pAn implementation of codePlugIn/code which
* can be configured to instantiate a graph of objects
* using the Commons Digester and place the root object
* of that graph into the Application context./p
*
* @author Joe Germuska
* @author David Graham
* @version $Revision$
* @see PlugIn
*/
public class DigestingPlugIn implements PlugIn {
/**
* Commons Logging instance.
*/
private static Log log = LogFactory.getLog(DigestingPlugIn.class);
protected static final String SOURCE_CLASSPATH = classpath;
protected static final String SOURCE_FILE = file;
protected static final String SOURCE_SERVLET = servlet;
protected String configPath = null;
protected String configSource = null;
protected String digesterPath = null;
protected String digesterSource = null;
protected String key = null;
protected ModuleConfig moduleConfig = null;
protected String ruleSets = null;
protected ActionServlet servlet = null;
protected boolean push = false;
/**
* Constructor for DigestingPlugIn.
*/
DO NOT REPLY [Bug 19420] - BaseHandlerTag should use its getter methods
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=19420. 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=19420 BaseHandlerTag should use its getter methods [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-07 00:52 --- In most cases the accessors were already being used but I cleaned up the remaining direct references. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22252] New: - Locale ignored on MessageResources.getMessage(String arg0)
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=22252. 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=22252 Locale ignored on MessageResources.getMessage(String arg0) Summary: Locale ignored on MessageResources.getMessage(String arg0) Product: Struts Version: 1.1 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Minor Priority: Other Component: Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] protected MessageResources messages = MessageResources.getMessageResources(SomeResource.properties); messages.getMessage(title); // delivers NO localized result but messages.getMessage(title, null); // works fine! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: When is the next release?
The users of struts can understand 1.2.1 w/o 1.2.0, most of use are also using tomcat as well and most of us skip releases. If it takes extra time for no other benefit than to keep things neet, it is probably not worth the effort. Edgar -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: Saturday, August 09, 2003 11:12 PM To: 'Struts Developers List' Subject: RE: When is the next release? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: August 9, 2003 8:57 PM To: Struts Developers List Subject: Re: When is the next release? That was my understanding as well -- we agreed to switch to the x.y.z style that Apache HTTPD and Tomcat are using, where you post the bits and then call for a vote on stability (alpha/beta/general availability). It's perfectly reasonable to have a series of general availability releases with new features in the 1.2.x series, as long as we continue to maintain backwards compatibility within it. Therefore the first release would be 1.2.1 and we'd keep going from there. I think it would be strange to go directly to a 1.2.1 release, which I suspect is why Ted was talking about a beta. Tomcat has a 4_1_0 tag in CVS, but I don't know if that was released as such. It's not my intention to reopen an old discussion, but I would like to confirm exactly what version this will be. Steve Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
This may be a good time to add an ActionContext interface instead of passing all these individual pieces. This would also slightly remove the dependence on Servlet to allow us more flexibility when we look at the portlet API. As an outside observer I would like to see something like this added. We've already added something like you describe to our application. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2003 9:47 AM To: Struts Developers List Subject: Re: ActionForwards, et al (was SuccessAction) --- Ted Husted [EMAIL PROTECTED] wrote: David Graham wrote: What I think we're seeing here is that we've outgrown our ActionForward declarations and need some new ones. I'm fine with adding a SuccessAction but would really like to see us discuss future possibilities in this area. This may not be what you meant, but I've been thinking that ActionForward could use a class extension point, same as ActionMapping. The idea would be to give ActionForward a type property for a Java class. If the property is specified, instead of just taking the path as it stands, the Controller would call a prepare method on the class, passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse. This may be a good time to add an ActionContext interface instead of passing all these individual pieces. This would also slightly remove the dependence on Servlet to allow us more flexibility when we look at the Portlet API. The prepare method would return a String that the Controller would use for the path. This allows the ActionForward to act as a Page Controller for the path. If the particular page referenced by the path needs any special chrome the Page Controller can set that up. Or, if the path needs to be adjusted for Locale or device (PDA, browser, et al), then the Page Controller could adjust the path before returning it. If it were a virtual page, like an dynamic image, merge file, or PDF, the Page class could also render the Response, rather than have the Action do it. Right now, the Action is doing double duty. It first acts as a Dispatcher that acquires business resources and selects the logical view. But, in real life, many pages often need special runtime resources of their own. So, the Action also serves as a Page Controller for the page it selects. Many of us consider that a mixing of concerns, and so we start to use some Actions as Dispatchers and others as Page Controllers. Tiles also fills this gap and is essentially a hybrid of a Compositive View and a Page Controller framework. I'm thinking that, architecturally, the ActionForward represents some resource available to the application, of any type, that can be reached by the application's protocol. In an http environment, it's the job of a Resource object to provide a URI that the Controller can use the reach the actual resource. (And, in another environment, perhaps the path would not be a URI.) The Action, in its purest form, represents a Dispatcher. It's the job of a Dispatcher to select which (logical) Resource will handle the response. When we talk about selecting between success, failure, or glockenspiel, we're talking about dispatching. But, in real life, we often can't just dispatch to a page. The page needs certain resources to render, often to fill UI controls like select lists. Ideally, I believe another class, specified by the ActionForward, should be responsible for setting up any chrome a particular page may need. It's the one that knows where the page is (via the path property), and so it's the one that should be privy to these details. What would start to happen here, I think, is that people will put into the new class the code that now encourages them to chain some Actions. By providing a separation of concern between choosing the Resource and preparing the context for the Resource, it becomes easier for people to Do The Right Thing. I've had similar composition problems and agree that a separation makes sense. Tiles Controllers can be used to setup page data but that doesn't always work (especially if you're not using Tiles :-) so I end up chaining actions. None of the action chaining is due to bus. logic as that's properly factored into a Service layer; it has to do purely with setting up page data. Tiles Controllers are one of the major reasons I use Tiles and I think it's appropriate to move that concept into the Struts core. David The gotcha is that, to do its job, the ActionForward type may also need to interact with the business layer. It doesn't seem right that the Page Controller should try to branch to another page, like an Action might, if there's an error. But the declarative exception handling might be able to step in here. -Ted. -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design -
Re: RE: SuccessAction (was RE: Addition of two new actions)
ÔÚ 2003-08-08 21:15:00 ÄúдµÀ£º I've created some patches to try this out and attached them to Bugzilla.of you ? Could you tell me ? Thanks~~ http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22267 Sorry about the multiple patch files, but WS Studio wouldn't play ball. I haven't touched Action...yet ;-) Steve -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: August 8, 2003 8:36 PM To: Struts Developers List Subject: RE: SuccessAction (was RE: Addition of two new actions) I thought the whole point was that there would be only one forward and the action would always forward to that forward? In that case, you could count on using the first one. Just thinking that if an anonymous/default ActionForward were allowed, then it could also be useful for other actions. In any case, it's better not to allow a situation where the behaviour is unspecified. You'd probably need to add a method such as getDefaultForward() to retrieve it. This part seems to be adding complexity to something which was meant to be very simple. I think it might actually be possible to reduce the visible complexity by doing that. e.g. action path=/myAction type=org.apache.struts.actions.SuccessAction forward path=/myPage.jsp/ /action SuccessAction may not now be best name, but let's stick with it for the moment. To be really radical, we could absorb the behaviour into Action, and have it check for a default ActionForward and use that, if found. That way there's no need for a SuccessAction at all. Then you could just do: action path=/myAction type=org.apache.struts.action.Action forward path=/myPage.jsp/ /action If Action actually does something useful, could we go crazy and default the type as well? action path=/myAction forward path=/myPage.jsp/ /action Now that's simple. Especially if you allow a global default forward... action path=/myAction/ Probably not quite so useful, but nicely minimal! Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] mqg - SOUVENIR --- . | Souvenir of China | | A Good Place for You | `-- http://www.souvenirchina.com -' mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22307] - Add encoding attribute to bean:include
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=22307. 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=22307 Add encoding attribute to bean:include [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Enhancement Summary|org.struts.bean.IncludeTag |Add encoding attribute to |encoding|bean:include - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ActionForwards, et al (was SuccessAction)
Ideally, I believe another class, specified by the ActionForward, should be responsible for setting up any chrome a particular page may need. It's the one that knows where the page is (via the path property), and so it's the one that should be privy to these details. Not sure if this comment belongs in the context of here, but I'll throw it out. We use Tiles and Tiles Controllers heavily, and one thing I dislike about forwarding to a TileDefinition is that I cannot then easily figure out which Action I'm forwarding to ( The path names a definition which is the same for each view in my case). I'm currently appending information via an extension to the ActionForward, this extra info is then used in my controller to prepare the appropriate data for that view. If there was some more transparent way to do this that would be good. I currently have one controller per definition, which may encompass several related views. What would start to happen here, I think, is that people will put into the new class the code that now encourages them to chain some Actions. By providing a separation of concern between choosing the Resource and preparing the context for the Resource, it becomes easier for people to Do The Right Thing. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, August 11, 2003 9:47 AM To: Struts Developers List Subject: Re: ActionForwards, et al (was SuccessAction) --- Ted Husted [EMAIL PROTECTED] wrote: David Graham wrote: What I think we're seeing here is that we've outgrown our ActionForward declarations and need some new ones. I'm fine with adding a SuccessAction but would really like to see us discuss future possibilities in this area. This may not be what you meant, but I've been thinking that ActionForward could use a class extension point, same as ActionMapping. The idea would be to give ActionForward a type property for a Java class. If the property is specified, instead of just taking the path as it stands, the Controller would call a prepare method on the class, passing it the ActionForward, ActionForm, HttpRequest, and HttpResponse. This may be a good time to add an ActionContext interface instead of passing all these individual pieces. This would also slightly remove the dependence on Servlet to allow us more flexibility when we look at the Portlet API. The prepare method would return a String that the Controller would use for the path. This allows the ActionForward to act as a Page Controller for the path. If the particular page referenced by the path needs any special chrome the Page Controller can set that up. Or, if the path needs to be adjusted for Locale or device (PDA, browser, et al), then the Page Controller could adjust the path before returning it. If it were a virtual page, like an dynamic image, merge file, or PDF, the Page class could also render the Response, rather than have the Action do it. Right now, the Action is doing double duty. It first acts as a Dispatcher that acquires business resources and selects the logical view. But, in real life, many pages often need special runtime resources of their own. So, the Action also serves as a Page Controller for the page it selects. Many of us consider that a mixing of concerns, and so we start to use some Actions as Dispatchers and others as Page Controllers. Tiles also fills this gap and is essentially a hybrid of a Compositive View and a Page Controller framework. I'm thinking that, architecturally, the ActionForward represents some resource available to the application, of any type, that can be reached by the application's protocol. In an http environment, it's the job of a Resource object to provide a URI that the Controller can use the reach the actual resource. (And, in another environment, perhaps the path would not be a URI.) The Action, in its purest form, represents a Dispatcher. It's the job of a Dispatcher to select which (logical) Resource will handle the response. When we talk about selecting between success, failure, or glockenspiel, we're talking about dispatching. But, in real life, we often can't just dispatch to a page. The page needs certain resources to render, often to fill UI controls like select lists. Ideally, I believe another class, specified by the ActionForward, should be responsible for setting up any chrome a particular page may need. It's the one that knows where the page is (via the path property), and so it's the one that should be privy to these details. What would start to happen here, I think, is that people will put into the new class the code that now encourages them to chain some Actions. By providing a separation of concern between choosing the Resource and preparing the context for the Resource, it becomes easier for people to Do The Right Thing. I've had similar composition problems and agree that a separation makes sense. Tiles Controllers can be
DO NOT REPLY [Bug 21614] - RequestUtils.getActionMappingName(String) should recognize anchor
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=21614. 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=21614 RequestUtils.getActionMappingName(String) should recognize anchor --- Additional Comments From [EMAIL PROTECTED] 2003-08-11 21:40 --- Created an attachment (id=7759) Adds code to remove a substring starting form a pound (#) sign to the end of an Action pathname. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22327] New: - Action attribute of link tags does not rewrite properly
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=22327. 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=22327 Action attribute of link tags does not rewrite properly Summary: Action attribute of link tags does not rewrite properly Product: Struts Version: 1.1 Final Platform: All OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Custom Tags AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When action paths contain periods, the action attribute appends the .do after the first period. so an action path of: /document.get with an html:link action=/document.get. will render a href=/ctx/module/document.do.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/doc/resources views.xml
mrdon 2003/08/11 16:38:33 Modified:doc/resources views.xml Log: Added Cocoon Plugin link and description Revision ChangesPath 1.5 +1 -0 jakarta-struts/doc/resources/views.xml Index: views.xml === RCS file: /home/cvs/jakarta-struts/doc/resources/views.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- views.xml 11 Aug 2003 23:33:19 - 1.4 +++ views.xml 11 Aug 2003 23:38:33 - 1.5 @@ -17,6 +17,7 @@ pa href=http://xsltgenerator.sourceforge.net/;bStruts XSLT Code Generator/b/a by Shengmeng Liu - An XSLT based code generator for Struts, completely based on the XSLT transformation and a set of stylesheet files. Ideally, users can customize the stylesheet for each type of Struts files to have templates of their own without having to access the source code and recompile it./p pa href=http://www.javaworld.com/javaworld/jw-02-2002/jw-0201-strutsxslt.html;bBoost Struts with XSLT and XML/b/a By Julien Mercay and Gilbert Bouzeid./p pa href=http://jakarta.apache.org/velocity/tools/struts/;bVelocityStruts/b/a by the a href=http://jakarta.apache.org/velocity;Velocity/a Team. The VelocityStruts sub-project of a href=http://jakarta.apache.org/velocity/tools;Velocity Tools/a integrates Velocity with Struts and enables the use of velocity templates interchangeably with JSP pages for the view layer./p +pa href=http://struts.sf.net;bCocoon Plugin/b/a by Don Brown. Integrates a href=http://cocoon.apache.org;Apache Cocoon/a into the Struts 1.1+ framework. Struts forwards can be passed to Cocoon to be rendered in Cocoon XML pipelines. Works alongside traditional Struts forwards./p /section /chapter/body/document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions)
Internationalisation doesn't/can't apply to the naming of classes. We'd have to rewrite the whole framework for each language. Ted raised the issue in regard to naming of the action forward, but also addressed that point himself. Steve -Original Message- From: Peter A. Pilgrim [mailto:[EMAIL PROTECTED] Sent: August 9, 2003 3:13 AM To: Struts Developers List Subject: Re: Parameter/Mapping/ConfigDispatchAction (Was RE: Addition of two new actions) Steve Raeburn wrote: I *think* we agreed to add this action. Pick a name. [ ] ParameterDispatchAction [ ] MappingDispatchAction [ ] ConfigDispatchAction Steve What happens if English is not your mother language. Are you suggesting we have? ErfolgreichAction -- German ExitosAction -- Spanish If we have Global.SUCCESS_FORWARD and Global.FAILURE_FORWARD to represent common ActionForward names it might help. Ted Husted suggests such naming in his book, but if program your variables with name that are non-english then you may not agree this. -- Peter Pilgrim __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22086] - update note on VelocityStruts in resources doc
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=22086. 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=22086 update note on VelocityStruts in resources doc [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-08-12 00:21 --- I updated the link and description before I noticed this bug report. Let me know if you'd rather use the description in the patch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html ELHtmlTag.java
dmkarr 2003/08/09 17:50:47 Modified:contrib/struts-el/src/share/org/apache/strutsel/taglib/html ELHtmlTag.java Log: Reverting fix for compile errors. Revision ChangesPath 1.9 +7 -7 jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELHtmlTag.java Index: ELHtmlTag.java === RCS file: /home/cvs/jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html/ELHtmlTag.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- ELHtmlTag.java9 Aug 2003 19:29:30 - 1.8 +++ ELHtmlTag.java10 Aug 2003 00:50:47 - 1.9 @@ -158,9 +158,9 @@ Boolean bool= null; String string = null; -if ((string = EvalHelper.evalString(lang, getLangExpr(), -this, pageContext)) != null) -setLangExpr(string); +if ((bool = EvalHelper.evalBoolean(lang, getLangExpr(), + this, pageContext)) != null) +setLang(bool.booleanValue()); if ((bool = EvalHelper.evalBoolean(locale, getLocaleExpr(), this, pageContext)) != null) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Decomposing RequestProcessor -- Some Code To Play With
Hey guys, this is exactly what pageflow does, though it does more as well. Oh well Im working on a white paper which describes the functionality. How would I go about getting something into the contrib folder? - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 11, 2003 12:23 AM Subject: Decomposing RequestProcessor -- Some Code To Play With During the Decomposing RequestProcessor thread a while back, I hinted that I'd been working on some code to propose for this purpose, but had never had time to polish it enough to check in. Well, I actually took a bunch of time this weekend for precisely that purpose, and have checked in two chunks of code for your viewing and toying pleasure: * A new jakarta-commons/sandbox package called chain that implements the GoF Chain of Responsibility pattern, in a way that lets you compose arbitrarily complex processing chains out of very simple classes, in a variety of different contexts. If you're familiar with Cocoon, think of the site map pattern but without the requirement that every dynamic step be an XSLT transformation. If you're familiar with Axis, think of the way you can compose Handler chains, but without the restriction that it is only useful in implementing a web service. Nightly builds of this package should start showing up tonight at: http://jakarta.apache.org/builds/jakarta-commons/nightly/commons-chain/ * A new contrib package in the Struts workspace called struts-chain that is the beginnings of a decomposition of the RequestProcessor processing pipeline, but allows the overall chain to be customzied in much more powerful manners than the way that subclassing RequestProcessor supports. You'll need to grab the CVS source to play with this one. None of the code actually works yet -- it is very definitely a work in progress -- but I *think* we'll be able to end up with something that can be added on to a Struts 1.1 distro. I won't personally have huge amounts of time to work on this over the next few months, but I will definitely participate in discussions and improvements to this code. If it all works out, I'm going to propose something like this as a foundational architecture for a Struts 2.x series that will leverage this design pattern to support extreme customization. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
