Re: JSF vs. Struts
I personally think all this exploration is a Very Good Thing(tm). There are a vast number of different ideas out there as to how a modern application framework should be built. Mistakes have been made over the years, lessons have been learned, but we don't all agree on what the mistakes were or what the lessons are! If that sounds bad to anyone, it isn't. It's quite the opposite and is the only way healthy debate and ultimately progress is made. At some point we're going to have to all weed out the options that don't quite measure up, and that will happen via simple market forces (the market in this case being mostly developer mind share), but I don't think that time is now, so the more experimentation, the better. I for one am not willing to declare one thing better than another... I regret having done that in the past prematurely, and certainly not in a manner I'm especially proud of. So, I'm certainly not going to make the same mistake twice. I'm still not sold on JSF, that much has not changed. I do however think there is some decent ideas underpinning it, which is also the case for many of the other frameworks and approaches out there, so declaring JSF or anything else for that matter a failure now is probably not fair either. I do think Jack's point about JSF being around for a while and not really setting the world on fire is fair, although that doesn't mean it has failed, just that it's going a little slower than hoped. My take on JSF is simply this: we'll see. I'm not sold yet, but I'm not willing to say I never will be. As for Shale, I'm not sure I understand why Rod or anyone says that Struts and JSF are not compatible... if the thinking is that the result will be quite a bit different from Struts as we know it today, then I suppose he might be right. That to me doesn't make them incompatible though. From what I have seen of JSF, and what I know of Struts, I can conceive of ways they could be fit together. I haven't had a chance to get into Shale yet, but I have no doubt many of those ideas, and many more I haven't thought of, are present. Why they are incompatible I just don't get, and I don't care who is making the claim, no matter how well-respected they are, I need to see some real, concrete examples before I'm convinced. Struts Ti looks pretty interesting... many of the ideas that were described here a few days ago were quite good in my mind. Should it be the future of Struts? I don't know yet, and I'm not even sure those developing it would be willing to say that at this juncture. It's another possible path, another exploration of possibilities, and that's good. One thing is for sure: most of us look back on the way we developed applications just five years ago and wonder why we ever did things that way. I have absolutely no doubt we'll be doing the same thing in another five years. I too would like to see less hype sometimes, but promoting ones' ideas is human nature. If you think you have a compelling answer, or even the One True Answer, you tell people about it and try and convince them. That's hype. It may not always be helpful, but it's perfectly natural :) Frank Dakota Jack wrote: I have to agree personally with Rod Johnson J2EE without EJBs, Spring framework architect, etc., when he says that Shale is merely a stopgap and that Struts as we know it is simply incompatible with JSF. That seems fairly obvious and I find it hard to believe that anyone familiar with the issues would think any differently. I personally would not hire anyone would thought differently, whether they like JSF or not. JSF is not new. JSF has been around forever, so it cannot be the cutting edge. If it is cutting, it is the cutting middle and almost the cutting tailend. The JSF idea has been around even longer with all sorts of frameworks which I personally think do it better. Indeed, I think it fair to say that one of the main architects of the JSF framework has said as much but has to feed his family. Certainly, if you like JSF, knock yourself out. Love it to death. I don't care. I only care about giving people that ask a fair evaluation of the product without the hype. On 8/10/05, Don Brown [EMAIL PROTECTED] wrote: Quick correction: Struts is _not_ forking in any sense of the word. Struts Ti is a sandbox project several of us are working on as an exploration of a simplified framework more like Ruby on Rails than JSF. It has not been accepted as a Struts subproject, just as Shale has not been accepted as Struts 2.0. The Struts project is currently in, what I would call, a state of exploration. In addition to Shale and Ti, there are other projects like Struts Overdrive, Struts Flow, etc., which are also exploring different aspects of web development. Of course, there will be Struts classic still for a long time to come which will continue to forego active development. I think Struts is realizing there is no one
Re: Struts website
Thanks for all the feedback and suggestions for the new site. Here's a second draft, incorporating as many of the suggestions as I could get to: http://svn.apache.org/builds/struts/maven/trunk/site-test/index.html - Navigation to subprojects is now consolidated near the top of the menu. - If a subproject has a directory on the existing site, (bsf, flow, shale,) the link goes to that documentation. - If there is no existing documentation (sandbox, etc.) then the link goes to the Maven-generated page. - The 'Overview' at the top of the Projects menu lists all of the Maven-generated pages, so they are all accessible. - The subprojects are directly under the root of the website (not under a directory called 'multiproject' any longer.) I have not yet had time to look at the taglib documentation so that's still missing. I'll do something to get the JavaDoc back into the 'Documentation' menu-- probably just a page that links to the Javadoc for each subproject. (Maven puts the links under Project Reports - JavaDoc for each subproject.) Ted wrote: * The Download links could point to anchors on the Acquiring page, to provide a single gateway. I changed the download links to point to the Acquiring page. The anchors, however, are a problem. Maven links to http://jakarta.apache.org/site/jakarta-site2.html as the accepted structure for the xml docs. And that includes neither the 'href' attribute that we're using to render anchors, nor the chapter tag that appears in the userGuide docs. The XSLT is using the 'name' attribute as both the text for the section headers _and_ the anchor name, and is ignoring the 'href' attribute entirely. The chapter tags are also ignored. I changed them to empty section tags to get the text to appear. Unless chapter is important for some reason I'm not aware of, (docbook?) those can probably be changed to section/subsection tags. Getting the anchors to work like they used to is probably going to require modifying the XSL stylesheet (.maven\cache\maven-xdoc-plugin-1.9.1\plugin-resources\site.jsl) and setting a property to tell Maven to use our stylesheet. I'm keeping notes on the site conversion here for now: http://wiki.wsmoak.net/cgi-bin/wiki.pl?MavenMultiProjectSite I will post a site conversion plan on the Struts Wiki tonight. I'm planning to do the initial copy from core/docs to build/xdocs in the repository no earlier than Friday night. Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JSF vs. Struts
FYI http://jroller.com/page/dgeary -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Thursday, August 11, 2005 8:44 AM To: Struts Developers List Subject: Re: JSF vs. Struts I personally think all this exploration is a Very Good Thing(tm). There are a vast number of different ideas out there as to how a modern application framework should be built. Mistakes have been made over the years, lessons have been learned, but we don't all agree on what the mistakes were or what the lessons are! If that sounds bad to anyone, it isn't. It's quite the opposite and is the only way healthy debate and ultimately progress is made. At some point we're going to have to all weed out the options that don't quite measure up, and that will happen via simple market forces (the market in this case being mostly developer mind share), but I don't think that time is now, so the more experimentation, the better. I for one am not willing to declare one thing better than another... I regret having done that in the past prematurely, and certainly not in a manner I'm especially proud of. So, I'm certainly not going to make the same mistake twice. I'm still not sold on JSF, that much has not changed. I do however think there is some decent ideas underpinning it, which is also the case for many of the other frameworks and approaches out there, so declaring JSF or anything else for that matter a failure now is probably not fair either. I do think Jack's point about JSF being around for a while and not really setting the world on fire is fair, although that doesn't mean it has failed, just that it's going a little slower than hoped. My take on JSF is simply this: we'll see. I'm not sold yet, but I'm not willing to say I never will be. As for Shale, I'm not sure I understand why Rod or anyone says that Struts and JSF are not compatible... if the thinking is that the result will be quite a bit different from Struts as we know it today, then I suppose he might be right. That to me doesn't make them incompatible though. From what I have seen of JSF, and what I know of Struts, I can conceive of ways they could be fit together. I haven't had a chance to get into Shale yet, but I have no doubt many of those ideas, and many more I haven't thought of, are present. Why they are incompatible I just don't get, and I don't care who is making the claim, no matter how well-respected they are, I need to see some real, concrete examples before I'm convinced. Struts Ti looks pretty interesting... many of the ideas that were described here a few days ago were quite good in my mind. Should it be the future of Struts? I don't know yet, and I'm not even sure those developing it would be willing to say that at this juncture. It's another possible path, another exploration of possibilities, and that's good. One thing is for sure: most of us look back on the way we developed applications just five years ago and wonder why we ever did things that way. I have absolutely no doubt we'll be doing the same thing in another five years. I too would like to see less hype sometimes, but promoting ones' ideas is human nature. If you think you have a compelling answer, or even the One True Answer, you tell people about it and try and convince them. That's hype. It may not always be helpful, but it's perfectly natural :) Frank Dakota Jack wrote: I have to agree personally with Rod Johnson J2EE without EJBs, Spring framework architect, etc., when he says that Shale is merely a stopgap and that Struts as we know it is simply incompatible with JSF. That seems fairly obvious and I find it hard to believe that anyone familiar with the issues would think any differently. I personally would not hire anyone would thought differently, whether they like JSF or not. JSF is not new. JSF has been around forever, so it cannot be the cutting edge. If it is cutting, it is the cutting middle and almost the cutting tailend. The JSF idea has been around even longer with all sorts of frameworks which I personally think do it better. Indeed, I think it fair to say that one of the main architects of the JSF framework has said as much but has to feed his family. Certainly, if you like JSF, knock yourself out. Love it to death. I don't care. I only care about giving people that ask a fair evaluation of the product without the hype. On 8/10/05, Don Brown [EMAIL PROTECTED] wrote: Quick correction: Struts is _not_ forking in any sense of the word. Struts Ti is a sandbox project several of us are working on as an exploration of a simplified framework more like Ruby on Rails than JSF. It has not been accepted as a Struts subproject, just as Shale has not been accepted as Struts 2.0. The Struts project is
Re: JSF vs. Struts
I think that most everyone would agree that exploration is a very good thing. At least I have not run into the people who take the opposite stand. Unfortunately, I think there is a definite disconnect between market forces and what is the best product. This is particularly true with the computer industry, in my experience. Market forces include hype, and if you want the industry to do well, you are certainly obligated to meet hype with hype. The next email in this thread references an individual's thoughts on JSF versus other options. This reference leaves out stuff that is more than relevant. That is how it works. JSF is struggling, so they are playing hardball at the top. I think that is okay. I can play in that ballpark. I wish so many people were not toadies though and would participate instead of choosing a leader for themselves. However, exploration is great. Wonnderful, wonnderful! I don't think that there is that much to computer programming. It really is not rocket science. And, I don't think the advances have been that great in the last five years, except in the market place. I have used at least five different frameworks equal to or better than Struts and certainly better than JSF before five years ago. I think we do not see often how much there is out there in companies that do not use open source. On 8/10/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: I personally think all this exploration is a Very Good Thing(tm). There are a vast number of different ideas out there as to how a modern application framework should be built. Mistakes have been made over the years, lessons have been learned, but we don't all agree on what the mistakes were or what the lessons are! If that sounds bad to anyone, it isn't. It's quite the opposite and is the only way healthy debate and ultimately progress is made. At some point we're going to have to all weed out the options that don't quite measure up, and that will happen via simple market forces (the market in this case being mostly developer mind share), but I don't think that time is now, so the more experimentation, the better. I for one am not willing to declare one thing better than another... I regret having done that in the past prematurely, and certainly not in a manner I'm especially proud of. So, I'm certainly not going to make the same mistake twice. I'm still not sold on JSF, that much has not changed. I do however think there is some decent ideas underpinning it, which is also the case for many of the other frameworks and approaches out there, so declaring JSF or anything else for that matter a failure now is probably not fair either. I do think Jack's point about JSF being around for a while and not really setting the world on fire is fair, although that doesn't mean it has failed, just that it's going a little slower than hoped. My take on JSF is simply this: we'll see. I'm not sold yet, but I'm not willing to say I never will be. As for Shale, I'm not sure I understand why Rod or anyone says that Struts and JSF are not compatible... if the thinking is that the result will be quite a bit different from Struts as we know it today, then I suppose he might be right. That to me doesn't make them incompatible though. From what I have seen of JSF, and what I know of Struts, I can conceive of ways they could be fit together. I haven't had a chance to get into Shale yet, but I have no doubt many of those ideas, and many more I haven't thought of, are present. Why they are incompatible I just don't get, and I don't care who is making the claim, no matter how well-respected they are, I need to see some real, concrete examples before I'm convinced. Struts Ti looks pretty interesting... many of the ideas that were described here a few days ago were quite good in my mind. Should it be the future of Struts? I don't know yet, and I'm not even sure those developing it would be willing to say that at this juncture. It's another possible path, another exploration of possibilities, and that's good. One thing is for sure: most of us look back on the way we developed applications just five years ago and wonder why we ever did things that way. I have absolutely no doubt we'll be doing the same thing in another five years. I too would like to see less hype sometimes, but promoting ones' ideas is human nature. If you think you have a compelling answer, or even the One True Answer, you tell people about it and try and convince them. That's hype. It may not always be helpful, but it's perfectly natural :) Frank Dakota Jack wrote: I have to agree personally with Rod Johnson J2EE without EJBs, Spring framework architect, etc., when he says that Shale is merely a stopgap and that Struts as we know it is simply incompatible with JSF. That seems fairly obvious and I find it hard to believe that anyone familiar with the issues would think any differently. I
Re: Struts website
Very nice! The only thing I noticed is could the author, see also, etc. metadata for a document be placed at the bottom instead of the top? Now that we are rendering that, I'll need to go clean it up :) Thanks again! Don Wendy Smoak wrote: Thanks for all the feedback and suggestions for the new site. Here's a second draft, incorporating as many of the suggestions as I could get to: http://svn.apache.org/builds/struts/maven/trunk/site-test/index.html - Navigation to subprojects is now consolidated near the top of the menu. - If a subproject has a directory on the existing site, (bsf, flow, shale,) the link goes to that documentation. - If there is no existing documentation (sandbox, etc.) then the link goes to the Maven-generated page. - The 'Overview' at the top of the Projects menu lists all of the Maven-generated pages, so they are all accessible. - The subprojects are directly under the root of the website (not under a directory called 'multiproject' any longer.) I have not yet had time to look at the taglib documentation so that's still missing. I'll do something to get the JavaDoc back into the 'Documentation' menu-- probably just a page that links to the Javadoc for each subproject. (Maven puts the links under Project Reports - JavaDoc for each subproject.) Ted wrote: * The Download links could point to anchors on the Acquiring page, to provide a single gateway. I changed the download links to point to the Acquiring page. The anchors, however, are a problem. Maven links to http://jakarta.apache.org/site/jakarta-site2.html as the accepted structure for the xml docs. And that includes neither the 'href' attribute that we're using to render anchors, nor the chapter tag that appears in the userGuide docs. The XSLT is using the 'name' attribute as both the text for the section headers _and_ the anchor name, and is ignoring the 'href' attribute entirely. The chapter tags are also ignored. I changed them to empty section tags to get the text to appear. Unless chapter is important for some reason I'm not aware of, (docbook?) those can probably be changed to section/subsection tags. Getting the anchors to work like they used to is probably going to require modifying the XSL stylesheet (.maven\cache\maven-xdoc-plugin-1.9.1\plugin-resources\site.jsl) and setting a property to tell Maven to use our stylesheet. I'm keeping notes on the site conversion here for now: http://wiki.wsmoak.net/cgi-bin/wiki.pl?MavenMultiProjectSite I will post a site conversion plan on the Struts Wiki tonight. I'm planning to do the initial copy from core/docs to build/xdocs in the repository no earlier than Friday night. Thanks, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts website
Excellent work, Wendy. I know you've done a great deal of work on this and we all appreciate it. Even if you are using Maven. david Le 05-08-11 à 07:25, Wendy Smoak a écrit : Thanks for all the feedback and suggestions for the new site. Here's a second draft, incorporating as many of the suggestions as I could get to: http://svn.apache.org/builds/struts/maven/trunk/site-test/index.html - Navigation to subprojects is now consolidated near the top of the menu. - If a subproject has a directory on the existing site, (bsf, flow, shale,) the link goes to that documentation. - If there is no existing documentation (sandbox, etc.) then the link goes to the Maven-generated page. - The 'Overview' at the top of the Projects menu lists all of the Maven-generated pages, so they are all accessible. - The subprojects are directly under the root of the website (not under a directory called 'multiproject' any longer.) I have not yet had time to look at the taglib documentation so that's still missing. I'll do something to get the JavaDoc back into the 'Documentation' menu-- probably just a page that links to the Javadoc for each subproject. (Maven puts the links under Project Reports - JavaDoc for each subproject.) Ted wrote: * The Download links could point to anchors on the Acquiring page, to provide a single gateway. I changed the download links to point to the Acquiring page. The anchors, however, are a problem. Maven links to http://jakarta.apache.org/site/jakarta-site2.html as the accepted structure for the xml docs. And that includes neither the 'href' attribute that we're using to render anchors, nor the chapter tag that appears in the userGuide docs. The XSLT is using the 'name' attribute as both the text for the section headers _and_ the anchor name, and is ignoring the 'href' attribute entirely. The chapter tags are also ignored. I changed them to empty section tags to get the text to appear. Unless chapter is important for some reason I'm not aware of, (docbook?) those can probably be changed to section/subsection tags. Getting the anchors to work like they used to is probably going to require modifying the XSL stylesheet (.maven\cache\maven-xdoc-plugin-1.9.1\plugin-resources\site.jsl) and setting a property to tell Maven to use our stylesheet. I'm keeping notes on the site conversion here for now: http://wiki.wsmoak.net/cgi-bin/wiki.pl?MavenMultiProjectSite I will post a site conversion plan on the Struts Wiki tonight. I'm planning to do the initial copy from core/docs to build/xdocs in the repository no earlier than Friday night. Thanks, -- Wendy - 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: struts-faces won't compile
On 8/11/05, Michael Rasmussen [EMAIL PROTECTED] wrote: Craig, I know this issue came up about a year ago that struts-faces wouldn't compile against the latest version of Struts (I think it was a validator issue). It makes sense to me that it should always work with the latest version of Struts. I think it would serve the project well to cut a *.0 release of struts-faces and give it a 1.1-1.2.x compatability...after that put it into maintenence mode. Then cut a new *.0 release that brings struts-faces up to date with struts core... I haven't been following faces too closely lately...has it gone to 1.x yet? If so, maybe this Struts dependency change to 1.2.x should denote a v 2.0? I totally understand that the target audience for struts-faces is the developer trying to migrate a struts app off of struts to jsf. I have a hard time (and sort of balked at struts-faces because of it) commiting to a path that may force me to run my app on struts 1.2.x and 1.3 in paralell if I decide later that JSF just won't get it done for me. Basically I just mean that I am forced to limit my options if I use struts-faces, and I thought the spirit of the library was to increase my options. The Maven-generated build script has been getting tweaked lately, and does indeed impose a Struts 1.2 dependency. I'll have to take a look at that -- but there seem to have been some incompatible changes in the underlying utility classes that is going to make supporting both 1.1 and 1.2 interesting -- let alone supporting 1.3 as well. NB - the nightly builds are compiled against 1.2.6 at the moment. http://cvs.apache.org/builds/struts/nightly/struts-faces/ My $0.02 Michael Craig On 8/8/05, Craig McClanahan [EMAIL PROTECTED] wrote: On 8/8/05, Wendy Smoak [EMAIL PROTECTED] wrote: From: Craig McClanahan [EMAIL PROTECTED] Maybe the Maven mavens can figure out a way to share the build infrastructure without sharing the dependency information? Not a problem... just change the dependency in project.xml. Looks like it needs at least 1.2.2 to compile. (It won't compile against Struts 1.1. Should it?) Given that Struts changed incompatibly, I'm ok with 1.2.x as a restriction. But doesn't that mean we still need an independent project.xml file instead of a shared one? If it makes sense, we can remove the extendbuild/project.xml/extend from project.xml, and that will make the build stand on its own. That seems more appropriate for Tiles than Struts-Faces, though. Yep ... but without disrupting all the subprojects that *do* want to share dependencies. Maybe another opportunity to use SVN externals creatively. Thanks, Wendy 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]
svn commit: r231510 - /struts/flow/trunk/src/java/org/apache/struts/flow/sugar/ScriptableList.java
Author: mrdon
Date: Thu Aug 11 13:37:20 2005
New Revision: 231510
URL: http://svn.apache.org/viewcvs?rev=231510view=rev
Log:
Adding code to grow list as needed to better mimic javascript behavior
PR: 36039
Modified:
struts/flow/trunk/src/java/org/apache/struts/flow/sugar/ScriptableList.java
Modified:
struts/flow/trunk/src/java/org/apache/struts/flow/sugar/ScriptableList.java
URL:
http://svn.apache.org/viewcvs/struts/flow/trunk/src/java/org/apache/struts/flow/sugar/ScriptableList.java?rev=231510r1=231509r2=231510view=diff
==
--- struts/flow/trunk/src/java/org/apache/struts/flow/sugar/ScriptableList.java
(original)
+++ struts/flow/trunk/src/java/org/apache/struts/flow/sugar/ScriptableList.java
Thu Aug 11 13:37:20 2005
@@ -1,12 +1,12 @@
/*
* Copyright 1999-2004 The 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.
@@ -20,63 +20,87 @@
import java.util.*;
import java.io.Serializable;
-/**
- * Wrap a java.util.List for JavaScript.
- */
+/** Wrap a java.util.List for JavaScript. */
public class ScriptableList extends JavaObjectWrapper implements Scriptable,
Wrapper, Serializable {
private List list;
+
public ScriptableList() {
this.list = list;
}
+
public ScriptableList(List list) {
this.list = list;
this.javaObject = javaObject;
}
-
+
+
public ScriptableList(Scriptable scope, Object javaObject, Class
staticType, Map funcs) {
super(scope, javaObject, staticType, funcs);
if (javaObject instanceof List) {
-this.list = (List)javaObject;
+this.list = (List) javaObject;
} else {
-throw new IllegalArgumentException(Passed object +javaObject+
is not an instance of List);
+throw new IllegalArgumentException(Passed object + javaObject +
is not an instance of List);
}
}
+
public String getClassName() {
return staticType.toString();
}
+
public boolean has(int index, Scriptable start) {
-return (list.get(index) != null);
+// We catch the ArrayIndexOutOfBoundsException because the parser is
probably trying to retrieve
+// the value first(reading the statement left to right) then assign
the value to that index...
+// or something like that.
+try {
+return (list.get(index) != null);
+} catch (ArrayIndexOutOfBoundsException e) {
+return false;
+}
}
+
public Object get(int index, Scriptable start) {
return list.get(index);
}
+
public void put(int index, Scriptable start, Object value) {
-list.add(index, value);
+int max = index + 1;
+if (max list.size()) {
+for (int i = list.size(); i index; i++) {
+list.add(i, null);
+}
+list.add(index, value);
+} else {
+list.set(index, value);
+}
}
+
public void delete(int index) {
list.remove(index);
}
+
public Object[] getIds() {
-
+
//TODO: optimize this :)
Integer[] ids = new Integer[list.size()];
-for (int x=0; xids.length; x++) {
+for (int x = 0; x ids.length; x++) {
ids[x] = new Integer(x);
}
return ids;
}
+
public Object unwrap() {
return this.list;
}
}
+
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36039] - Implement a more javascript feel for the ScriptableList
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=36039. 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=36039 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-08-11 22:37 --- Fixed in changeset [231510]. Thanks for the patch! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36152] New: - action field is blank in using html:form
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=36152. 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=36152 Summary: action field is blank in using html:form Product: Struts Version: 1.2.4 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Unknown AssignedTo: dev@struts.apache.org ReportedBy: [EMAIL PROTECTED] I'm using tomcat 5.0.28 and sun's 1.4.2_07 jdk. When using an html:form my generated html occasionally leaves the action field blank. jsp source: html:form action=foo.do ... Sometimes my html source ends up like this: form name=fooform method=post action= ... Whereas it should look like this: form name=fooform method=post action=/webapp/foo.do ... from my struts config: form bean: form-bean name=fooform type=com.foo.FooForm/ action mapping: action path=/foo type=com.foo.FooAction scope=request name=fooform input=foo.jsp forward name=success path=/foodone.jsp redirect=true/ forward name=failure path=/foo.jsp redirect=false/ /action This code works fine for a few days, and then I start getting the blank action. After that, I need to restart Tomcat. It is possible that this bug exists in Tomcat. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsUpgradeNotes124to127 by NiallPemberton
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by NiallPemberton: http://wiki.apache.org/struts/StrutsUpgradeNotes124to127 -- It has been reported in [http://issues.apache.org/bugzilla/show_bug.cgi?id=35127 Bug 35127] and a fix applied to the nightly build. + == Bug 35833 - html:messages Tag Issue == + + Struts 1.2.7 added ''non-resource'' ActionMessage(s) and support for multiple bundles in Validator. However the html:messages tag only shows the first ''non-resource'' ActionMessage. This also affects the Validator's mutlitple bundle support which is implemented using ''non-resource'' ActionMessage(s). + + The html:errrors tag is not affected by this issue and can be used as an alternative to html:messages. + + See [http://issues.apache.org/bugzilla/show_bug.cgi?id=35833 Bug 35833] + CategoryHomepage StrutsUpgrade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: struts-faces won't compile
From: Craig McClanahan [EMAIL PROTECTED] +import org.apache.struts.util.ModuleUtils; -RequestUtils.selectModule(request, servletContext); +ModuleUtils.getInstance().selectModule(request,servletContext); Conceptually that fix makes sense in that it solves the compilation problem ... but I don't believe that struts-faces should inherit a dependency on 1.3.x. I don't see how switching from a deprecated method call to the replacement causes a dependency on 1.3.x. That change still compiles under 1.2.2. Today it works (runtime) on 1.1 and 1.2, and it would be pretty pointless to throw away the vast majority of the potential target market. Does it really still work on 1.1? It won't compile against 1.1 due to the use of org.apache.struts.taglib.TagUtils and org.apache.struts.util.ModuleUtils, which must not have existed then. I think Struts-Faces (if it's going to be built with Maven :-) needs its own set of dependencies, independent of whatever Struts Core is using. It was inheriting from the Struts Common Build, not from Struts Core. The incorrect dependency on struts-core-1.3.0-dev was actually *in* the struts-faces build file and has been corrected to struts-1.2.2. (You said you're using 1.2.6 for the Ant build, but that one isn't on ibiblio. Can we agree on 1.2.7 by any chance?) James, can you comment on how you'd like to see this handled? The website builds just fine whether or not the extend tag is there (so I'm happy either way). But there are things in the common build file that are *not* common to all subprojects. Maven is smart enough to allow sub-projects to override dependencies by specifying a different version number, (servletapi-2.2 instead of servletapi-2.3, for example.) But by extending the common build, Struts Faces picks up dependencies on antlr, commons-chain, commons-digester, commons-fileupload and oro, none of which it really needs. I don't see a way to override a dependency coming from the common build with nothing. Thanks, -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
breadcrumb
How to implement dynamin breadcrumb in struts? -sidd __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsShortTermPlans by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsShortTermPlans -- * Apply patches from problem tickets as they arise + Wendy Smoak + * StrutsWebsiteConversion - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsWebsiteConversion by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/StrutsWebsiteConversion New page: === Goal === Integrate the existing Struts website into the Maven-generated multi-project website. === Draft Site === http://svn.apache.org/builds/struts/maven/trunk/site-test/index.html === Discussion Thread === http://www.mail-archive.com/dev%40struts.apache.org/msg10723.html === Timeline === * Initial copy from core/doc to build/xdocs on Saturday, August 13, 2005 === Initial Conversion Plan === * Copy everything from /struts/current/core/doc/ to /struts/current/build/xdocs/ * Add a README file to /current/core/doc/ requesting no further changes * Rename the project.xml files (which contain the menus) to navigation.xml * Change links in all navigation.xml files under 'build' to be relative to the root directory * Add the missing body tags to navigation.xml files * Add navigation.xml files to xdocs under each subproject * Change the chapter tags to section and section to subsection in the userGuide * Add a href=#anchorName tags near the section tags that use an href attribute * Remove the search section from userGuide/index.xml and faqs/index.xml * Fix links to Taglib Package Descriptions (JavaDoc) in the User Guide === Post-Conversion To Do List === * Generate TLD documentation and fix links to Taglib API References in the User Guide * Maven Taglib Plugin: http://maven-taglib.sourceforge.net/ * Move relevant documentation down to the sub-project level * Dashboard for aggregated reports: http://maven.apache.org/reference/plugins/dashboard/ * Remove files from core/doc/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts website
One remaining concern about the website conversion: If I copy the files into build/xdocs, what happens when someone checks out struts/current and gets the 'build' directory within every subproject? I have a feeling it's going to retrieve all that documentation a dozen times, once for each subproject, but maybe Subversion clients are smarter than that. Otherwise, can subversion be configured to exclude the 'xdocs' directory? Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts website
From: Wendy Smoak [EMAIL PROTECTED] One remaining concern about the website conversion: If I copy the files into build/xdocs, what happens when someone checks out struts/current and gets the 'build' directory within every subproject? I have a feeling it's going to retrieve all that documentation a dozen times, once for each subproject, but maybe Subversion clients are smarter than that. Otherwise, can subversion be configured to exclude the 'xdocs' directory? (I'm really not talking to myself-- James IM'd right after I posted the message above to confirm that this is a legitimate issue.) When I asked a question recently on maven-user, they suggested having a separate sub-project for the website. That didn't initially work for me because if you run 'maven multiproject:site' from /struts/current/build, it sees the 'website' directory as just another sub-project and puts the documentation under struts.apache.org/website-- breaking every link into the Struts site. However, having a separate sub-project for the website and building the site _from there_ works. I now have struts/current/site containing the 'xdocs' directory with all of the xml (and other) files from the existing site, and executing 'maven multiproject:site' from struts/current/site does the right thing. Having a separate sub-project for the site also helps with the goal of clearly separating the website from the project documentation. Are there any objections to having 'site' or 'website' as a new sub-project? Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
