Re: [RESULT][VOTE] Struts as an Apache Top Level Project
Sorry, I just moved from Hawaii to California so I haven't been following struts-dev like I should. About the TLP vote: +0 - no strong feelings one way or another Don - Original Message - From: Martin Cooper [EMAIL PROTECTED] Date: Thu, 11 Mar 2004 21:47:05 -0800 (PST) To: Struts Developers List [EMAIL PROTECTED] Subject: [RESULT][VOTE] Struts as an Apache Top Level Project The response to this vote has been unanimous, with all proposed PMC members responding except for two: Arron Bates and Don Brown. I have attempted to ping those two directly, but have not yet heard back. The next board meeting is March 17th, which is next Wednesday. I propose to submit our resolution this weekend, for consideration at that meeting. In the absence of responses from Arron and Don before then, I will remove their names from both lists. They will, of course, be welcome to join the PMC at a later time. If anyone has any objections to the above plan, please speak up now. -- Martin Cooper On Sat, 6 Mar 2004, Martin Cooper wrote: Following up on a brief thread on this list in December [1], Craig, Ted and I have put together a draft resolution to the board of directors [2], along with a cover letter [3], that would promote Struts to an Apache top-level project (TLP). The main reasons for moving to a TLP are described on the wiki [4]. In Craig's words, The short answer, though, is we will be in charge of our own releases (currently, the Jakarta PMC is the only body legally recognized to vote on releases of *any* software under Jakarta). In practice, we can really just continue doing what we've always done. As most of you are no doubt aware, several Jakarta sub-projects have already made the transition to TLPs, including Ant, Avalon, Gump, James, Log4J, Maven, OJB, and Torque. Most Jakarta PMC members seem to be in favour of the migrations, largely because a single PMC cannot possibly oversee a code base the size of all of Jakarta. If you're OK with Struts being a top-level Apache project, please respond to this thread with either a +1 or +0. Otherwise, please reply with your concerns. When we previously discussed this, it did not seem like anyone was opposed to the idea, but if anyone is, now is the time to speak up. The resolution as drafted lists the Struts Committers who could reasonably be considered active at this time. Of course, we should not put anyone on the PMC without their buy-in, so the final resolution would only list the Committers who responded to the Vote with a +1 or +0. The draft resolution also leaves the name of the Vice President blank. Craig seems like the logical candidate, and is willing to act in this capacity, but we wanted the VP selection to be a community decision. So, please also respond with your nomination for Vice President, Apache Struts. Here's my +1 on the resolution as drafted, and my +1 for Craig as Vice President. -- Martin Cooper [1] http://nagoya.apache.org/eyebrowse/SearchList?listId=[EMAIL PROTECTED]searchText=%22Why+you+*want*+to+be+on+the+PMC%22defaultField=subjectSearch=Search [2] http://www.apache.org/~martinc/struts/tlp/resolution.html [3] http://www.apache.org/~martinc/struts/tlp/cover.html [4] http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges - 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] -- ___ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts Jericho DTD
I've been looking at the current proposal for Strut's 2.0 config. I think
it's a little too complex and the extends concept could be simplified
while gaining the same advantages as breaking your app into modules.
The struts config has many of a single element type of mapping. Mappings
would have a single attribute of URI and would run under the same rules as
the Servlet Filter Mapping.
mapping uri=/*
action execute=#{applicationController.validateLogin} /
catch exception=com.mckesson.smo.AuthorizationException /
form id=C /
/mapping
mapping uri=/ordering/*
bean id=orderController class=com.mckesson.smo.OrderController
scope=session
property name=application
value#{applicationController}/value
/property
/bean
action execute=#{orderController.validateUser} /
catch exception=com.mckesson.smo.AuthorizationException /
/mapping
mapping uri=/ordering/startOrder.jspx
action execute=#{orderController.startOrder} /
/mapping
Mappings would be fired like filters and actions would/could be chained.
Child elements of the mapping element could be overridden then based on the
requested URI.
In the example above, the /ordering/* mapping would override the catch
from the /* mapping. Also, actions would be executed in the order least
specific to most specific URI mapping.
ActionForwards could also be overridden also in this same manor to allow
generic mappings to look for a badAuthorization forward, but it can be
overridden in a more specific mapping.
The bean element would allow you to scope beans within
request|session|application, but also take care of cleaning up the beans
when they leave one of those mappings. This could help with wizard type
flows where if the bean was of XXListenerType, it could receive create and
destroy events and enforce users to stick within a flow.
Just some ideas... I've been working on developing a mock version of this
between projects at work.
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 27632] New: - Message-resource for multiple modules
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27632. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27632 Message-resource for multiple modules Summary: Message-resource for multiple modules Product: Struts Version: 1.1 Final Platform: PC OS/Version: Windows XP Status: NEW Severity: Minor Priority: Other Component: Web Site AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Here is the case: One webapp with many modules, and each module has it's own struts-config- modulename.xml file, and it's own set of properties files. And a default struts-config.xml file for the whole webapp. Supposely, each module's properties files are config as message-resources key=errors parameter=xxx.module1.ErrorsResources/ message-resources key=messages parameter=xxx.module1.MessagesResources/ ... And when use in the application, bean:message bundle=errors key=some.key/ However, that doesn't works, got an exception mentioned that the key can not be found with errors bundle when the bean:message is rendered. But, when I place the same configuration in the default struts-config.xml file, it works. The message key can be found with the errors bundle. I assume this might be a bug, since each module can have it's own set of message-resources. However, I do another test on it by config each module with only one message- resouce, and they are configed as the default with out a key value. And that seems to work. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] Struts as an Apache Top Level Project
On Fri, 12 Mar 2004, Don Brown wrote: Sorry, I just moved from Hawaii to California so I haven't been following struts-dev like I should. Welcome to California! (Did you bring the weather with you? Is that why it's so nice right now? ;) About the TLP vote: +0 - no strong feelings one way or another Excellent. Now I don't have to modify the resolution at all. ;-) -- Martin Cooper Don - Original Message - From: Martin Cooper [EMAIL PROTECTED] Date: Thu, 11 Mar 2004 21:47:05 -0800 (PST) To: Struts Developers List [EMAIL PROTECTED] Subject: [RESULT][VOTE] Struts as an Apache Top Level Project The response to this vote has been unanimous, with all proposed PMC members responding except for two: Arron Bates and Don Brown. I have attempted to ping those two directly, but have not yet heard back. The next board meeting is March 17th, which is next Wednesday. I propose to submit our resolution this weekend, for consideration at that meeting. In the absence of responses from Arron and Don before then, I will remove their names from both lists. They will, of course, be welcome to join the PMC at a later time. If anyone has any objections to the above plan, please speak up now. -- Martin Cooper On Sat, 6 Mar 2004, Martin Cooper wrote: Following up on a brief thread on this list in December [1], Craig, Ted and I have put together a draft resolution to the board of directors [2], along with a cover letter [3], that would promote Struts to an Apache top-level project (TLP). The main reasons for moving to a TLP are described on the wiki [4]. In Craig's words, The short answer, though, is we will be in charge of our own releases (currently, the Jakarta PMC is the only body legally recognized to vote on releases of *any* software under Jakarta). In practice, we can really just continue doing what we've always done. As most of you are no doubt aware, several Jakarta sub-projects have already made the transition to TLPs, including Ant, Avalon, Gump, James, Log4J, Maven, OJB, and Torque. Most Jakarta PMC members seem to be in favour of the migrations, largely because a single PMC cannot possibly oversee a code base the size of all of Jakarta. If you're OK with Struts being a top-level Apache project, please respond to this thread with either a +1 or +0. Otherwise, please reply with your concerns. When we previously discussed this, it did not seem like anyone was opposed to the idea, but if anyone is, now is the time to speak up. The resolution as drafted lists the Struts Committers who could reasonably be considered active at this time. Of course, we should not put anyone on the PMC without their buy-in, so the final resolution would only list the Committers who responded to the Vote with a +1 or +0. The draft resolution also leaves the name of the Vice President blank. Craig seems like the logical candidate, and is willing to act in this capacity, but we wanted the VP selection to be a community decision. So, please also respond with your nomination for Vice President, Apache Struts. Here's my +1 on the resolution as drafted, and my +1 for Craig as Vice President. -- Martin Cooper [1] http://nagoya.apache.org/eyebrowse/SearchList?listId=[EMAIL PROTECTED]searchText=%22Why+you+*want*+to+be+on+the+PMC%22defaultField=subjectSearch=Search [2] http://www.apache.org/~martinc/struts/tlp/resolution.html [3] http://www.apache.org/~martinc/struts/tlp/cover.html [4] http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
Remember this ol' thread? http://thread.gmane.org/gmane.comp.jakarta.struts.devel/15486 Just thought I'd check in and see what folks were thinking about the view controller thing. Seems like there are a few enthusiastic folks on struts-dev now who weren't around for the last round of this discussion, or who have started speaking up more. The way I see it, the problem may be as much how to configure as how to implement. Struts-config files are already kind of complicated. There's also a question about how much more to pile on the poor RequestProcessor when the Chain ComposableRequestProcessor seems pretty close to prime-time. However, assuming we'd want to put this in the original RequestProcessor rather than wait for struts-chain to reach full maturity, here's some off-the-cuff ideas for you to shoot down Create a new interface, Renderer, strongly modeled off of Action. It would have one method: public ForwardConfig execute(ForwardConfig config, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception; ForwardConfig could have a form or formName property (since 'name' is already taken), and using that, the output form would be looked up more or less the way forms are now, taking advantage of some recent refactorings so that you no longer require an ActionMapping to get a form. This would give the Renderer something it could pre-populate using whatever logic and system information it needed, should it care to. The renderer could return the same ForwardConfig which was passed to it, or it could create a new one: for example, the new one might rewrite the path to include localization information (as described in the post mentioned above.) I'd want to provide a base DispatchRenderer implementation which works like MappingDispatchAction, so i'd probably want to add a 'parameter' property to ForwardConfig. I don't expect everyone to use it, but I really prefer having less classes with more behavior. It seems like it might be slightly disruptive to add properties to ForwardConfig since people may have already extended it for their own purposes. How do people rate that risk? Does the Renderer need the ability to look up global forwards? Is now a good time to coin a StrutsContext class that encapsulates the various arguments to execute? I've always kind of wanted this for Action too. I've frequently thought it would be a nice thing. This seems to get a little blurry when looking forward to a more chain-oriented Struts, where there's already a Context object floating through, but it seems worth discussing if we're making a new interface. Like I said, this is just something to shoot down... so fire away! Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/src/example/org/apache/struts/webapp/example LogonAction.java
husted 2004/03/12 15:49:29
Modified:src/example/org/apache/struts/webapp/example
LogonAction.java
Log:
Change methods from protected to private (it's a final class)
Revision ChangesPath
1.24 +8 -8
jakarta-struts/src/example/org/apache/struts/webapp/example/LogonAction.java
Index: LogonAction.java
===
RCS file:
/home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/LogonAction.java,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -r1.23 -r1.24
--- LogonAction.java 12 Mar 2004 02:43:29 - 1.23
+++ LogonAction.java 12 Mar 2004 23:49:29 - 1.24
@@ -40,12 +40,12 @@
/**
* Name of username field [username].
*/
-private static String USERNAME = username;
+static String USERNAME = username;
/**
* Name of password field [password].
*/
-private static String PASSWORD = password;
+static String PASSWORD = password;
// -- Protected Methods
@@ -62,7 +62,7 @@
* @throws ExpiredPasswordException to be handled by Struts exception
* processor via the action-mapping
*/
-protected User getUser(UserDatabase database, String username,
+User getUser(UserDatabase database, String username,
String password, ActionMessages errors) throws
ExpiredPasswordException {
User user = null;
@@ -95,7 +95,7 @@
* @param request The request we are processing
* @param user The user object returned from the database
*/
-protected void SaveUser(HttpServletRequest request, User user) {
+void SaveUser(HttpServletRequest request, User user) {
HttpSession session = request.getSession();
session.setAttribute(Constants.USER_KEY, user);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/example tour.html
husted 2004/03/12 15:50:09
Modified:web/example tour.html
Log:
Change methods from protected to private (it's a final class)
Revision ChangesPath
1.9 +4 -4 jakarta-struts/web/example/tour.html
Index: tour.html
===
RCS file: /home/cvs/jakarta-struts/web/example/tour.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- tour.html 12 Mar 2004 05:19:45 - 1.8
+++ tour.html 12 Mar 2004 23:50:09 - 1.9
@@ -461,9 +461,9 @@
private static String USERNAME = username;
private static String PASSWORD = password;
-protected User getUser(UserDatabase database, String username,
- String password, ActionMessages errors)
- throws ExpiredPasswordException {
+User getUser(UserDatabase database, String username,
+ String password, ActionMessages errors)
+ throws ExpiredPasswordException {
User user = null;
if (database == null){
@@ -487,7 +487,7 @@
}
-protected void SaveUser(HttpServletRequest request, User user) {
+void SaveUser(HttpServletRequest request, User user) {
HttpSession session = request.getSession();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/web/example mainMenu.jsp tour.html
husted 2004/03/12 21:22:51 Modified:web/example mainMenu.jsp tour.html Log: Refine MainMenu and CheckLogon Revision ChangesPath 1.18 +4 -10 jakarta-struts/web/example/mainMenu.jsp Index: mainMenu.jsp === RCS file: /home/cvs/jakarta-struts/web/example/mainMenu.jsp,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- mainMenu.jsp 12 Mar 2004 05:19:45 - 1.17 +++ mainMenu.jsp 13 Mar 2004 05:22:51 - 1.18 @@ -3,21 +3,15 @@ %@ taglib uri=/tags/struts-bean prefix=bean % %@ taglib uri=/tags/struts-html prefix=html % app:checkLogon/ -jsp:useBean id=user scope=session type=org.apache.struts.webapp.example.User/ - -html:html +html head titlebean:message key=mainMenu.title//title -html:base/ +link rel=stylesheet type=text/css href=base.css / /head -body bgcolor=white - -h3bean:message key=mainMenu.heading/ -jsp:getProperty name=user property=username//h3 +h3bean:message key=mainMenu.heading/ bean:write name=user property=fullName //h3 ul lihtml:link action=/EditRegistration?action=Editbean:message key=mainMenu.registration//html:link/li lihtml:link forward=logoffbean:message key=mainMenu.logoff//html:link/li /ul - /body -/html:html +/html 1.10 +118 -46 jakarta-struts/web/example/tour.html Index: tour.html === RCS file: /home/cvs/jakarta-struts/web/example/tour.html,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- tour.html 12 Mar 2004 23:50:09 - 1.9 +++ tour.html 13 Mar 2004 05:22:51 - 1.10 @@ -110,33 +110,33 @@ pUnfortunately, actions cannot be specified as a welcome page. Since there can be a list of pages, the web server looks for each page on the list before selecting one. The web server doesn't see actions as pages and will never select one as a welcome page. So, in the case of a welcome page, how do we follow the Struts best practice of navigating through actions rather than pages?/p -pOne solution is to use a server page to bootstrap a Struts action. A Java web application recognizes the idea of forwarding from one page to another page (or action). We can register the usual index.jsp as the welcome page and have it forward to a welcome action. Here's the MailReader's index.jsp:/p +pOne solution is to use a server page to bootstrap a Struts action. A Java web application recognizes the idea of forwarding from one page to another page (or action). We can register the usual index.jsp as the welcome page and have it forward to a Welcome action. Here's the MailReader's index.jsp:/p hr / pre codelt;%@ taglib uri=/tags/struts-logic prefix=logic %gt; -lt;logic:redirect action=/welcome/gt;/code +lt;logic:redirect action=/Welcome/gt;/code /pre hr / -pAt the top of the page, we import the struts-logic JSP tag library. (Again, see the a href=http://jakarta.apache.org/struts/userGuide/preface.html;Preface to the Struts User Guide/a for more about the technologies underlying Struts.) The page itself consists of a single tag that redirects to the welcome action. The tag inserts the actual web address for the redirect when the page is rendered. But, where does the tag find the actual address to insert?/p +pAt the top of the page, we import the struts-logic JSP tag library. (Again, see the a href=http://jakarta.apache.org/struts/userGuide/preface.html;Preface to the Struts User Guide/a for more about the technologies underlying Struts.) The page itself consists of a single tag that redirects to the Welcome action. The tag inserts the actual web address for the redirect when the page is rendered. But, where does the tag find the actual address to insert?/p pThe list of actions, along with other Struts components, are registered through one or more Struts configuration files. The configuration files are written as XML documents and processed when the application starts. If we just wanted to forward to the welcome page, we could use a configuration element like this:/p hr / pre codelt;!-- Display welcome page --gt; -lt;action path=/welcome forward=/welcome.jsp /gt;/code +lt;action path=/Welcome forward=/welcome.jsp /gt;/code /pre hr / -pIf someone asked for the welcome action (/Welcome.do), the welcome.jsp page would be displayed in return./p +pIf someone asked for the Welcome action (/Welcome.do), the welcome.jsp page would be displayed in return./p h4a name=WelcomeAction.java id=WelcomeAction.javaWelcomeAction.java/a/h4 -pBut if we peek at the configuration file for the MailReader, we find a slightly more complicated XML element for the welcome action:/p +pBut if
cvs commit: jakarta-struts/src/example/org/apache/struts/webapp/example CheckLogonTag.java
husted 2004/03/12 21:23:39
Modified:src/example/org/apache/struts/webapp/example
CheckLogonTag.java
Log:
Refine MainMenu and CheckLogon
Revision ChangesPath
1.11 +23 -109
jakarta-struts/src/example/org/apache/struts/webapp/example/CheckLogonTag.java
Index: CheckLogonTag.java
===
RCS file:
/home/cvs/jakarta-struts/src/example/org/apache/struts/webapp/example/CheckLogonTag.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- CheckLogonTag.java13 Jan 2004 12:48:44 - 1.10
+++ CheckLogonTag.java13 Mar 2004 05:23:39 - 1.11
@@ -3,63 +3,20 @@
* $Revision$
* $Date$
*
- *
- *
- * The Apache Software License, Version 1.1
- *
- * Copyright (c) 1999-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 acknowledgement:
- * 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 name, without prior written
- *permission of the Apache Software Foundation.
- *
- * 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/.
+ * Copyright 2000-2004 Apache Software Foundation
*
+ * Licensed under the Apache License, Version 2.0 (the License);
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
*/
-
-
package org.apache.struts.webapp.example;
@@ -78,7 +35,6 @@
*
* @version $Revision$ $Date$
*/
-
public final class CheckLogonTag extends TagSupport {
@@ -92,56 +48,15 @@
/**
- * The page to which we should forward for the user to log on.
- */
-private String page = /logon.jsp;
-
-
-// --- Properties
-
-
-/**
- * Return the bean name.
- */
-public String getName() {
-
-return (this.name);
-
-}
-
-
-/**
- * Set the bean name.
- *
- * @param name The new bean name
+ * Path to use if a login is needed.
*/
-
Re: Reviving PageController (ViewController?) discussion?
--- Joe Germuska [EMAIL PROTECTED] wrote: ForwardConfig could have a form or formName property (since 'name' is already taken), and using that, the output form would be looked up more or less the way forms are now, taking advantage of some recent refactorings so that you no longer require an ActionMapping to get a form. This would give the Renderer something it could pre-populate using whatever logic and system information it needed, should it care to. The renderer could return the same ForwardConfig which was passed to it, or it could create a new one: for example, the new one might rewrite the path to include localization information (as described in the post mentioned above.) I'd be concerned about associating a form with a ForwardConfig. It's possible that the resulting view could contain more than one form needing prepopulation, and we don't want to limit the entire response chain to only prepopulate one of them, or at least imply that that's the limit. Following the use case you mentioned on the user list, where the action accepted the search keys and displays search results, the resulting view could include both the search result in a form for editing, and a form to allow the user to run another search (abandoning the current record). I personally have come across this scenario multiple times in multiple web apps I've been involved in. In such a case, (A) do we facilitate it by letting the function return another ForwardConfig which is associated with another form? Or (B) should the method just use the new createActionForm to create new forms and store them in the right scope? (A) If we use another ForwardConfig, we could reuse the one used by the original search form. It could be declared as a global forward which could be reused in all pages needing that form. Sure sounds like Tiles. This echoes the intentions mentioned in earlier threads, which is to provide this functionality to the core. This requires chaining a ForwardConfig for each form a view will need. (B) If we use createActionForm with an additional RequestUtils (ResponseUtils? oops, deprecated.) method to set a form. RequestUtils creates the blank form, the PageController populates it, and a RequestUtils method sets the form in the proper scope using the proper attribute name. Either way, it's looking like it might make sense to move the scope setting to the form definition, or at least allow a default setting there which will be honored if an action mapping doesn't specify a form scope. (Could be a topic for another thread) Could we instead define the forms as children of ForwardConfig? This seems to make more sense and doesn't imply that a view is limited to one form. form-beans form name=form1 type=o.a.s.a.DynaActionForm renderer=com.corp.Renderer1 form-property .../ /form form name=form2 type=com.corp.MyActionForm renderer=com.corp.Renderer2/ /form-beans action ... forward name=view1 form name=form1/ /forward forward name=view2 form name=form1/ form name=form2/ /forward forward name=view3 type=com.corp.PageController1/ /action The PageController would then concentrate on non-form data needed by the view. Also, maybe we can call the Renderer's method render. Like I said, this is just something to shoot down... so fire away! Joe Line this up among those to shoot down. Hubert __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URL validation - anyone using it?
From: Adam Hardy I provide URL validation on a page which saves links for users. I put together the latest build of commons-validator (1.1.2) and struts (1.2) to see what the URL validation is like. The class for server-side validation is in place, but the javascript doesn't exist. It works very strictly, too strictly for me. Most users will want to save links such as http://www.google.com http://jakarta.apache.org/ http://marc.theaimsgroup.com/?l=struts-userm=105511005106573w=2 This is definately a bug and they should have passed, I haven't run the unit tests against it in some time do they still pass ? My guess is that it might not be expecting the '/' after the domain name. This would probably only require a small tweak to the regular expression thats used. I would apply any patches that were submitted -Rob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
