Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
David Graham wrote:
--- Vic Cekvenich [EMAIL PROTECTED] wrote:
And even a simple DAO interface, to be used optionaly be people, so
they can go back and forth from iBatis to Hibreante or what ever.
I started the Mapper project in the commons for this exact reason. It
doesn't belong in Struts.
http://jakarta.apache.org/commons/sandbox/mapper/
David
I like the goal.
Thanks for the link, I looked at it but my idea was more of a utra
simple CRUD DAO interface, taking Collections or XML as arguments. ..
following the Sun DAO patern (what most people do) but simpler.
ex:
public interface OptionalDAO {
Document retrieveAsXML(Map arg); // so people can implement a DAO that
executes a retrieve any way they please.
List retrieveAsList(Map arg);
boolean saveXML(Document arg); // so people can implement a DAO that
saves any way they please.
boolean saveList(List arg);
void beginTran() ;
void endTran();
along those lines.
.V
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
-Original Message- From: Sgarlata Matt [mailto:[EMAIL PROTECTED] Sent: 17 December 2003 22:11 To: Struts Developers List Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) - Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Wednesday, December 17, 2003 5:04 PM Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) So then, with specific frameworks, I don't understand how Pico's orientation towards constructors works in an environment where beans need to be dynamically instantiated, but perhaps I just haven't thought about it hard enough. Avalon seems too heavy, which leaves us (or me at least) with Spring and HiveMind. I haven't developed with either but so far the docs for Spring give me a warm fuzzy feeling while the HiveMind docs kind of scare me. I agree with your assessment of frameworks 100%. However, Spring is under an LGPL license, so Struts can't use Spring unless either Struts switches to LGPL or Spring switches to ASF, right? It would be kind of silly for Struts to stay under ASF in this case, since the Spring license would force the undesirable LGPL clauses on any projects that were based on Struts. Am I right? Matt What kind of Spring Framework classes would you want to use in Struts 2.0? The BeanWrapper and the BeanFactory are interesting ideas. An example of configuring commons DBCP is given http://www.springframework.org/docs/lightweight_container.html I am not convince however of the requirement for BeanFactory. I can understand if you need to have massive XML configuration and need to dynamic generate Beans (objects) at run-time. It is great but other than that I can really view to the advantage inverse of control there that Struts or Commons BeanUtils combine Digester could not do itself. Struts is great because it concentrates on doing one thing well MVC. I wouldn't want it to branch out go into a generic framework space e.g Avalon, Expresso, Keel, Spring, Pico etc. The major design difficulties are abstract away the request and response objects from the controller actions, and also configuration of any other front-end objects you need along the way. To a certain extent Commons Chain and its context leads the way regarding the former. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbs.co.uk/CBFM http://www.rbsmarkets.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
David Graham wrote: --- Vic Cekvenich [EMAIL PROTECTED] wrote: And even a simple DAO interface, to be used optionaly be people, so they can go back and forth from iBatis to Hibreante or what ever. I started the Mapper project in the commons for this exact reason. It doesn't belong in Struts. +1 Struts should remain a BYOM (Bring Your Own Model) framework. As soon as we include *anything* along these lines, people perceive it as the preferred way of doing things. (Look at what happened with GenericDataSource). Certainly, we can include more HOWTOs in the documentation about hooking Struts up with various business and persistence layers. But the classes for doing this should not live under the Struts brand.. http://jakarta.apache.org/commons/sandbox/mapper/ David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: 17 December 2003 23:00 To: Struts Developers List Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) ==== A sort of meta-question: When is Struts no longer Struts? I mean, how much change can we introduce in Struts 2.0 before it becomes so different that it's really a different framework? Do we need to decide on what Struts is, and is not, before we go too far down the path of Struts 2.0? Or do we let whatever falls out just fall out and deal with it later? Legally, I'd say that Strut is whatever the Struts Community says it is. It's a brand that belongs to the ASF, which we manage on the Foundation's behalf. Technically, I'd say that Struts (or any framework) is an aggregation of its components. In Struts 1.0, we had mainly Form, Forward, Mapping, Action, and Messaging components. In Struts 1.1, we added Exception, Validation, Composite (or Tile), and PlugIn components. So long as Struts 2.x retains the same hallmark components in a recognizable form, I'd say it's still Struts. :) Overall, it's my feeling that Struts does all the right things, it's just that we don't do them in all the right places. :) Being able to extend elements is one example. Encapsulating paths is another. My own goal for Struts 2.x is to consistently apply all our best practices and eliminate inconsistent and legacy practices. We've got a good thing here; we just need to make it even better. :) In terms of new functionality, the three biggest fish I'd like to fry are Workflow, SSL, and Unit Testing. Towards that end, I'd like to consider integrating LivingLogic's Workflow, ssl-ext, and Struts TestCase into the Struts 2.x development stream. We may also want to consider adding these as standard options to Struts 1.x, so as to blaze a trail. Integrating StrutsTestCase would help with the Unit tests, although it will have to be heavily modified in parallel to keep up with changes in development. Although it's not evident from the Jericho DTD, the intention is to use a Context object in the signatures, perhaps the Commons Chain Context, so as to encapsulate Servlet/Portlet dependencies. So you no longer going to pass in request and response objects around, but instead have a context instead. Maybe it would be a little inconvenient for every Action to call ``context.getRequest()'' all the time. Perhaps we can keep them please. I dont mind losing the form bean. I could live with ``context.getForm()'', because for some environments you dont need to buffer a user's input. e.g. web services, or even a flat file. public ActionForward someStateAction( org.apache.commons.chain.Context context, some.generic.request request, some.generic.response response ); And for those of us who have subclassed Action, and ActionForm to create our own super frameworks, this will be very interesting and involved work to say the least/. -Ted. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbs.co.uk/CBFM http://www.rbsmarkets.com
Ideia
We could use those suggested action-forward parameters to configure the Tiles Framework. Instead of creating one definition for each page, the forward mappping parameter could be used to configure the definition parameters. Creating one definition of each target is hard work (this is true when using extension too), because most of pages of a module works on the same page layout. If this can't be done, we could use the last word of the definition name to denote the value of a 'special' parameter, such as body. For example: .common.client.showClient.jsp - could configure the 'body' property of the '.common.client' definition. Stutz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-jericho/src/conf struts-jericho-config_2_0.dtd
husted 2003/12/18 05:20:25
Modified:contrib/struts-jericho/src/conf
struts-jericho-config_2_0.dtd
Log:
Add attribute for ssl-ext support.
Revision ChangesPath
1.2 +10 -1
jakarta-struts/contrib/struts-jericho/src/conf/struts-jericho-config_2_0.dtd
Index: struts-jericho-config_2_0.dtd
===
RCS file:
/home/cvs/jakarta-struts/contrib/struts-jericho/src/conf/struts-jericho-config_2_0.dtd,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- struts-jericho-config_2_0.dtd 17 Dec 2003 20:50:35 - 1.1
+++ struts-jericho-config_2_0.dtd 18 Dec 2003 13:20:25 - 1.2
@@ -285,6 +285,11 @@
relative to application root rather than the current module.
[false]
+ merge Set to true if the resource path should be scanned for
replacement
+ parameters {[scope:]xyz}. Replacement parameters must begin
+ with a letter. If a scope is not specified, all scopes are
+ checked in turn (request, session, application).
+
redirectSet to true if a redirect instruction should be issued to
the user-agent so that a new request is issued for this
Location's resource. If true, RequestDispatcher.Redirect is
@@ -299,6 +304,7 @@
!ATTLIST locationresource %RequestPath; #REQUIRED
!ATTLIST locationmappingRef %Boolean; #IMPLIED
!ATTLIST locationappRelative%Boolean; #IMPLIED
+!ATTLIST locationmerge %Boolean; #IMPLIED
!ATTLIST locationredirect %Boolean; #IMPLIED
@@ -558,6 +564,8 @@
module.
[false]
+ secure whether to force secure access to this mapping (via SSL).
+
roles Comma-delimited list of security role names that are allowed
access to this Mapping object.
@@ -604,6 +612,7 @@
!ATTLIST mapping matches%RequestPath; #REQUIRED
!ATTLIST mapping processor CDATA #IMPLIED
!ATTLIST mapping default%Boolean; #IMPLIED
+!ATTLIST mapping secure %Boolean; #IMPLIED
!ATTLIST mapping roles CDATA #IMPLIED
!ATTLIST mapping parameter CDATA #IMPLIED
!ATTLIST mapping attribute %PropName; #IMPLIED
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-jericho README.txt
husted 2003/12/18 05:21:13 Modified:contrib/struts-jericho README.txt Log: Clarificatioins and additional items for consideration. Revision ChangesPath 1.3 +1 -1 jakarta-struts/contrib/struts-jericho/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-struts/contrib/struts-jericho/README.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- README.txt18 Dec 2003 13:19:59 - 1.2 +++ README.txt18 Dec 2003 13:21:13 - 1.3 @@ -54,6 +54,6 @@ * Integrate Tiles definitions into core configuration. -* Adopt Struts Menu as an standard option, like Validator and Tiles. +* Adopt Struts Workflow and Struts Menu as standard options, like Validator and Tiles. ### - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-jericho README.txt
husted 2003/12/18 05:22:59 Modified:contrib/struts-jericho README.txt Log: Clarificatioins and additional items for consideration. Revision ChangesPath 1.4 +2 -2 jakarta-struts/contrib/struts-jericho/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-struts/contrib/struts-jericho/README.txt,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- README.txt18 Dec 2003 13:21:13 - 1.3 +++ README.txt18 Dec 2003 13:22:59 - 1.4 @@ -42,7 +42,7 @@ -Also under consideration- -* Services_framework. Utilize Sprint IoC, HiveMind, Avalon, orPico, et cetera, to configure services. +* Services framework. Utilize Spring IoC, HiveMind, Avalon, orPico, et cetera, to configure services. * Configuration testing. Integrate utility of Struts TestCase, ideally configured from an XML configuration (a la Canoo Webtest). @@ -50,7 +50,7 @@ * Utilize protocols in resource paths. An mapped path would look like mapping://foo or a tiles forward would be tiles://tilesdef This would make it easy to plug in handlers to support different presentation engines. If no protocol is specified, the path is handled as usual. -* Merge form-bean and validator-form configurations. A single element would allow everything Struts knowns about a form to be configured in one place. +* Combine form-bean and validator-form configurations. A single element would allow everything Struts knowns about a form to be configured in one place. * Integrate Tiles definitions into core configuration. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
The BeanWrapper and the BeanFactory are interesting ideas. An example of configuring commons DBCP is given http://www.springframework.org/docs/lightweight_container.html I am not convince however of the requirement for BeanFactory. I can understand if you need to have massive XML configuration and need to dynamic generate Beans (objects) at run-time. It is great but other than that I can really view to the advantage inverse of control there that Struts or Commons BeanUtils combine Digester could not do itself. I like this for beans: www.joda.org Wow! It would get rid of a lot of questions on the user list. (This man wanted to go ASF) Struts is great because it concentrates on doing one thing well MVC. I wouldn't want it to branch out go into a generic framework space e.g Avalon, Expresso, Keel, Spring, Pico etc. But maybe build Struts on top of Pico or similar (http://oscar-osgi.sourceforge.net) or hivemind or... See if we pick high level light interfaces and use generic jars like now, it could be done quick like, and fund, since code would be done at a bit higher level. (And maybe WebWork or Spring or implement our MVC high level light interface.) .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
In terms of new functionality, the three biggest fish I'd like to fry are Workflow, SSL, and Unit Testing. Towards that end, I'd like to consider integrating LivingLogic's Workflow, ssl-ext, and Struts TestCase into the Struts 2.x development stream. We may also want to consider adding these as standard options to Struts 1.x, so as to blaze a trail. I aqgree that DAO should be outside of Sturts. I do not think Workflow should be inside. Becuase I do not think it is a good practice. It may be needed by some people... as a plug in. Integrating StrutsTestCase would help with the Unit tests, although it will have to be heavily modified in parallel to keep up with changes in development. I also do not think testing should be insdide. There are many that look into JVM, into container's JSP, etc. and people should inovate. I use OpenSTA, becuase I want to see what happens under load. However... Monitoring and Managing the application while runing in production maybe should be included. Ex: Jamon. I used it, and it's great. I works similar to log4j. Or at least it should be documented. In days of ClientServer, 3 tier ment: Data Layer, Presentation Layer and Managment Layer. So you no longer going to pass in request and response objects around, but instead have a context instead. Maybe it would be a little inconvenient for every Action to call ``context.getRequest()'' all the time. Perhaps we can keep them please. I dont mind losing the form bean. I could live with ``context.getForm()'', because for some environments you dont need to buffer a user's input. e.g. web services, or even a flat file. public ActionForward someStateAction( org.apache.commons.chain.Context context, some.generic.request request, some.generic.response response ); Why not just KISS and public ActionForward someStateAction( org.apache.commons.chain.Context context ); It can *all* go into context(or a Map!!!), else we have the tilesAction execute signature. I can allways do a map.get(request) This would work for SOAP or other protocols. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-jericho README.txt
husted 2003/12/18 06:10:07 Modified:contrib/struts-jericho README.txt Log: Clarifications and additional items for consideration. Revision ChangesPath 1.5 +2 -0 jakarta-struts/contrib/struts-jericho/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-struts/contrib/struts-jericho/README.txt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- README.txt18 Dec 2003 13:22:59 - 1.4 +++ README.txt18 Dec 2003 14:10:07 - 1.5 @@ -56,4 +56,6 @@ * Adopt Struts Workflow and Struts Menu as standard options, like Validator and Tiles. +* Utilize JodaBeans http://www.joda.org/ as a foundation class for core components. + ### - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
public ActionForward someStateAction( org.apache.commons.chain.Context context ); It can *all* go into context(or a Map!!!), else we have the tilesAction execute signature. I can allways do a map.get(request) This would work for SOAP or other protocols. I was going to add: This lets people store and pass additional info. Else they start putting properties in action (not thread safe). Maybe Struts 2.0 should have an action implemenation that gets instaciated every user session (it should not be used but... it exposes the issue). .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
-Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich In terms of new functionality, the three biggest fish I'd like to fry are Workflow, SSL, and Unit Testing. Towards that end, I'd like to consider integrating LivingLogic's Workflow, ssl-ext, and Struts TestCase into the Struts 2.x development stream. We may also want to consider adding these as standard options to Struts 1.x, so as to blaze a trail. I aqgree that DAO should be outside of Sturts. I do not think Workflow should be inside. Becuase I do not think it is a good practice. It may be needed by some people... as a plug in. Struts greatest strength up to now is its agnostic data model feel. You need to supply the Model architecture, so I agree there. It has also been historically a weakness where users have been a little confused by form bean and data transfer objects. Ie the various ways of streaming information back and forth the tier. Integrating StrutsTestCase would help with the Unit tests, although it will have to be heavily modified in parallel to keep up with changes in development. I also do not think testing should be insdide. There are many that look into JVM, into container's JSP, etc. and people should inovate. I use OpenSTA, becuase I want to see what happens under load. Au contraire. I think it would be benefit the framework if there was a standard Strut's unit test part available out-of-the-box. It would aid developer's writing containerless unit tests, otherwise it is down the road with Cactus. Nope. Strike that StrutsTestCase does support Cactus. Whatever the framework should have unit test of its own delivered whether it is Struts Test Case or self-amogrified hand crafted ``junit.framework.TestCase'' subclass. However... Monitoring and Managing the application while runing in production maybe should be included. Ex: Jamon. I used it, and it's great. I works similar to log4j. Or at least it should be documented. In days of ClientServer, 3 tier ment: Data Layer, Presentation Layer and Managment Layer. You could add this feature on with JMX and MBean and write a ``ComposableRequestProcessor'' , I mean special Command to monitor the processor flow. Perhaps you can write an instrumented `org.apache.commons.chain.Chain implementation' that is JMX compatible. So you no longer going to pass in request and response objects around, but instead have a context instead. Maybe it would be a little inconvenient for every Action to call ``context.getRequest()'' all the time. Perhaps we can keep them please. I dont mind losing the form bean. I could live with ``context.getForm()'', because for some environments you dont need to buffer a user's input. e.g. web services, or even a flat file. public ActionForward someStateAction( org.apache.commons.chain.Context context, some.generic.request request, some.generic.response response ); Why not just KISS and public ActionForward someStateAction( org.apache.commons.chain.Context context ); It can *all* go into context(or a Map!!!), else we have the tilesAction execute signature. I can allways do a map.get(request) This would work for SOAP or other protocols. .V Yes I agree KISS is better, Vic. It is better by the design. Maybe you can be person to announce to the Struts 1.0 1.1 user base that all of their Actions are now invalid, they wont compile for Struts 2.0 because you need to upgrade ALL your state methods to get HttpServletRequest and HttpServletResponse and ActionForm and ActionMapping from the Chains context. This is early days, and too-low level so I 'd put this point on the back burner. It can be easily solved using Java Reflection. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
-Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Vic Cekvenich ==== public ActionForward someStateAction( org.apache.commons.chain.Context context ); It can *all* go into context(or a Map!!!), else we have the tilesAction execute signature. I can allways do a map.get(request) This would work for SOAP or other protocols. I was going to add: This lets people store and pass additional info. Else they start putting properties in action (not thread safe). Maybe Struts 2.0 should have an action implemenation that gets instaciated every user session (it should not be used but... it exposes the issue). .V If you look Commons Chain then you will that the ``Context'' (or it at least its concrete implementation ``ContextImpl'') is a `java.util.HashMap' subclass. -- Peter Pilgrim, Struts/J2EE Consultant, RBoS FM, Risk IT Tel: +44 (0)207-375-4923 *** The Royal Bank of Scotland plc. Registered in Scotland No 90312. Registered Office: 36 St Andrew Square, Edinburgh EH2 2YB. Authorised and regulated by the Financial Services Authority This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. The Royal Bank of Scotland plc does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by The Royal Bank of Scotland plc in this regard and the recipient should carry out such virus and other checks as it considers appropriate. Visit our websites at: http://www.rbs.co.uk/CBFM http://www.rbsmarkets.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
public ActionForward someStateAction(
org.apache.commons.chain.Context context,
some.generic.request request,
some.generic.response response );
Why not just KISS and
public ActionForward someStateAction(
org.apache.commons.chain.Context context );
It can *all* go into context(or a Map!!!), else we have the
tilesAction
execute signature.
I can allways do a
map.get(request)
This would work for SOAP or other protocols.
.V
Yes I agree KISS is better, Vic. It is better by the design.
Maybe you can be person to announce to the Struts 1.0
1.1 user base that all of their Actions are now invalid, they
wont compile for Struts 2.0 because you need to upgrade ALL
your state methods to get HttpServletRequest and
HttpServletResponse and ActionForm and ActionMapping
from the Chains context.
Both above method signatures above are not compatible!
But you could have a base class:
execute(context) {
execute(context.getReq(),context.getMapp(),...
}
You could go the other way too, not at the same time
execte(req,resp,mapping,the4ththing) {
context = new Context();
context.setReq(req);
context.setMapping(mappping);
execute(context);
}
This is sort of what I do now in bP
So it can be compatible.
Beside, we had perform and excute once, so users know.
Also, I imagine a long road to 2.0, people will be using nightly build
for a while that only has the new stuff.
.V
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
PILGRIM, Peter, FM wrote: This is early days, and too-low level so I 'd put this point on the back burner. We've started to track suggestions like these here: http://cvs.apache.org/viewcvs.cgi/jakarta-struts/contrib/struts-jericho/ to help avoid recovering the same ground. Of course, what's on the roadmap for Struts 2.0.x still goes as well. http://jakarta.apache.org/struts/status.html -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to get action name
Hi, Can any one tell me how to get the actionpath from the HTTPRequest or ActionMapping? Regards VasudevRaoGupta Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25630] - Add 'server' keyword to validator to allow server side only checks for some fields.
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=25630. 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=25630 Add 'server' keyword to validator to allow server side only checks for some fields. --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 16:55 --- Maybe instead of server it should be something like field client=false or field script=false. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ideia
On Thu, 18 Dec 2003 [EMAIL PROTECTED] wrote: We could use those suggested action-forward parameters to configure the Tiles Framework. Instead of creating one definition for each page, the forward mappping parameter could be used to configure the definition parameters. Creating one definition of each target is hard work (this is true when using extension too), because most of pages of a module works on the same page layout. It's not hard work at all if you make use of 'extends'. ;-) -- Martin Cooper If this can't be done, we could use the last word of the definition name to denote the value of a 'special' parameter, such as body. For example: .common.client.showClient.jsp - could configure the 'body' property of the '.common.client' definition. Stutz - 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: Ideia
Martin Cooper wrote: On Thu, 18 Dec 2003 [EMAIL PROTECTED] wrote: Creating one definition of each target is hard work (this is true when using extension too), because most of pages of a module works on the same page layout. It's not hard work at all if you make use of 'extends'. ;-) -- Martin Cooper If there is a way to *not* have to create a definition just to change on tile... and maybe combine it to Struts config so the * mapping can be used. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
On Wed, 17 Dec 2003, Don Brown wrote: Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x release work. :) I'll throw out some ideas here, then develop them later in the wiki: - Make Inversion of Control central. By using an IoC framework to wire Struts together, it makes it really easy to extend or improve Struts not only for future development but for users as well. I'd recommend Spring's IoC impl as it is small (100k), really easy to use, and easily extendable. If we wanted to remain more agnostic, there are meta IoC frameworks that let you plug in Pico/Spring/Avalon, etc. I'm a little hesitant to start depending on other frameworks. It's not that I think they don't have anything to offer us, it's just what it does to the newcomer to Struts. If someone has to learn Struts *and* Spring (for example) to get going, then we've set the bar much higher. If we do end up deciding to depend on something like this, I believe we'll need to put in the work to make it look like Struts. Taking Spring as an example again, the substantial difference in the character of the XML config files would easily confuse a newcomer trying to get his/her head around the syntax. If we could make those files look like Struts config files (or vice versa, for that matter), that would help, though. -- Martin Cooper - Use XML Schema over DTD's. Give struts config its own default namespace to make it easier for users to mix in elements of other namespaces. An example would be adding custom documentation attributes and elements. Of course the usual arguments for XML Schema over DTD's apply as well. - Replace paths with URL's, allowing for a default protocol. An action path would look like action://foo or a tiles forward would be tiles://tilesdef This would make it easy to plug in handlers to support different presentation engines. If no protocol is specified, the path is handled as usual. - As Ted said, contine with the wildcard theme. Struts should do everything possible to cut down configuration. - Also, again totally agreeing with Ted, make everything interface based, have default implementations, and free apps of HTTP. Ideally, I'd like to see extra effort going into making it easy if not effortless to take a Struts 2.0 app and use the code in a portlet or web service environment. At least in my area, clients are wanting human and machine interfaces, with the human interface generally being behind a portal. Anyways, those are my brainstorming thoughts. If any look interesting, I'll write something up in the wiki. Don - 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 25630] - Add 'server' keyword to validator to allow server side only checks for some fields.
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=25630. 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=25630 Add 'server' keyword to validator to allow server side only checks for some fields. --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 17:24 --- Agreed,Thats much cleaner ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-jericho README.txt
husted 2003/12/18 09:26:33 Modified:contrib/struts-jericho README.txt Log: Clarifications and additional items for consideration. Revision ChangesPath 1.6 +2 -0 jakarta-struts/contrib/struts-jericho/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-struts/contrib/struts-jericho/README.txt,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- README.txt18 Dec 2003 14:10:07 - 1.5 +++ README.txt18 Dec 2003 17:26:33 - 1.6 @@ -58,4 +58,6 @@ * Utilize JodaBeans http://www.joda.org/ as a foundation class for core components. +* Load all configuration defaults form a core.properties file so that less is hardcoded, including a PlugIn class to bootstrap loading the core configuraiton. + ### - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-jericho OVERVIEW.txt
husted 2003/12/18 09:27:00 Added: contrib/struts-jericho OVERVIEW.txt Log: Add overview document. Revision ChangesPath 1.1 jakarta-struts/contrib/struts-jericho/OVERVIEW.txt Index: OVERVIEW.txt === -COMPONENT OVERVIEW- Configuration registry * At initialiation, each request adapter (servlet, filter, et cetera), adds its configuration to a single registry at a global location under a unique key. Command Context * Extends CoR Context to encapsulate framework members needed to process request and render response Request Adapter (module, portlet, mock) * Receives request from container (or TestRunner) * Normalizes request path (masks pattern registered with container) * Creates context to wrap request and response objects * Adds reference to its configuration (stored in global registry) * Invokes Controller * When control returns, dispatches to Location (if any) Controller * Receives context and selects the matching mapping * Adds reference to mapping instance to context * Removes any expired messages from context * Invokes processor for mapping Processor * Invokes series of methods (Chain of Commands) to handle request. The default series includes * Multipart * Locale * ContentType * NoCache * PreProcess * Roles * FormHandler * Cancel * Reset * Populate * Validate * Invalid * MappingHandler * Command | Script | Forward | Include ExceptionHandler * Intercept any Exception thrown by Processor and dispatch to designated error page. Tags/Tools * Reference Command Context (stored in request) to access framework members Server Pages * Utilize tags and tools to render dynamic data. ### - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Quoting Martin Cooper [EMAIL PROTECTED]: Just to add a few more off the top of my head: * Make the Struts core independent of the Servlets spec and the Portlets spec, so that it can be used for both, and more. * Separate view-technology-specific code into separate components, so that the core is view-technology agnostic. So, for example, all JSP specific code, including all of the taglibs, would move to a JSP component. * Rework Tiles into two facets, so that the core is independent of the Servlets spec and JSP, and the JSP component is part of the view specific component described above. * Split out file upload handling into a separate pluggable component, with its own configuration. I noticed that this is still in the initial Jericho DTD, but I think it should not be. The file upload implementation is pluggable, and so should be able to have its own config definition. I know I have more in notes at home, but just wanted to throw these out. A sort of meta-question: When is Struts no longer Struts? I mean, how much change can we introduce in Struts 2.0 before it becomes so different that it's really a different framework? Do we need to decide on what Struts is, and is not, before we go too far down the path of Struts 2.0? Or do we let whatever falls out just fall out and deal with it later? Product names are marketing, not technology. Struts 2.0 will be Struts if *we* call it Struts :-). More seriously, the amount of change between major product versions can be pretty enormous in some cases (ask classic ASP developers if they think ASP.NET is really the same environment or not). Innovation and revolution are perfectly fine things to do (applying all the lessons we've learned along the way), but we should also remember that there are thousands of apps based on a Struts 1.x architecture that need continuing support. We need to have the discipline to continue to work evolving a 1.2.x world while we're creating a new 2.x one. Regarding 2.x, an important consideration will be base technology platforms -- I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e. Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the presentation technology, etc.). -- Martin Cooper Craig On Wed, 17 Dec 2003, Don Brown wrote: Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x release work. :) I'll throw out some ideas here, then develop them later in the wiki: - Make Inversion of Control central. By using an IoC framework to wire Struts together, it makes it really easy to extend or improve Struts not only for future development but for users as well. I'd recommend Spring's IoC impl as it is small (100k), really easy to use, and easily extendable. If we wanted to remain more agnostic, there are meta IoC frameworks that let you plug in Pico/Spring/Avalon, etc. - Use XML Schema over DTD's. Give struts config its own default namespace to make it easier for users to mix in elements of other namespaces. An example would be adding custom documentation attributes and elements. Of course the usual arguments for XML Schema over DTD's apply as well. - Replace paths with URL's, allowing for a default protocol. An action path would look like action://foo or a tiles forward would be tiles://tilesdef This would make it easy to plug in handlers to support different presentation engines. If no protocol is specified, the path is handled as usual. - As Ted said, contine with the wildcard theme. Struts should do everything possible to cut down configuration. - Also, again totally agreeing with Ted, make everything interface based, have default implementations, and free apps of HTTP. Ideally, I'd like to see extra effort going into making it easy if not effortless to take a Struts 2.0 app and use the code in a portlet or web service environment. At least in my area, clients are wanting human and machine interfaces, with the human interface generally being behind a portal. Anyways, those are my brainstorming thoughts. If any look interesting, I'll write something up in the wiki. Don - 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]
What about Struts 2.0 and JSF?
Guys, I am wondering what is the relation between Struts 2.0 and JSF. Will Struts be an implementation of JSF specification? Will it be the Reference Implementation (UHUUU)? Stutz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Craig R. McClanahan wrote: Regarding 2.x, an important consideration will be base technology platforms -- I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e. Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the presentation technology, etc.). JDK 1.4, yes. One popular? goal mentioned was: Get away from reliance on Servlet API I like being on Tomcat 4. What does it gain to be Tomcat 5 technically? What containers support 2.4? How long for users to convert to the new 2.4 containers? It'd be limiting. If it ends up being interface, so it could be even used from Soap or applications (the discussed interface execute(Context ctx) ; ) it won't matter much. .V ps: I would like light IoC to be considered just a bit more as platform, Pico, Oscar. Not Spring or Avalon. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
On Thu, 18 Dec 2003, Craig R. McClanahan wrote: Quoting Martin Cooper [EMAIL PROTECTED]: Just to add a few more off the top of my head: * Make the Struts core independent of the Servlets spec and the Portlets spec, so that it can be used for both, and more. * Separate view-technology-specific code into separate components, so that the core is view-technology agnostic. So, for example, all JSP specific code, including all of the taglibs, would move to a JSP component. * Rework Tiles into two facets, so that the core is independent of the Servlets spec and JSP, and the JSP component is part of the view specific component described above. * Split out file upload handling into a separate pluggable component, with its own configuration. I noticed that this is still in the initial Jericho DTD, but I think it should not be. The file upload implementation is pluggable, and so should be able to have its own config definition. I know I have more in notes at home, but just wanted to throw these out. A sort of meta-question: When is Struts no longer Struts? I mean, how much change can we introduce in Struts 2.0 before it becomes so different that it's really a different framework? Do we need to decide on what Struts is, and is not, before we go too far down the path of Struts 2.0? Or do we let whatever falls out just fall out and deal with it later? Product names are marketing, not technology. Struts 2.0 will be Struts if *we* call it Struts :-). More seriously, the amount of change between major product versions can be pretty enormous in some cases (ask classic ASP developers if they think ASP.NET is really the same environment or not). Innovation and revolution are perfectly fine things to do (applying all the lessons we've learned along the way), but we should also remember that there are thousands of apps based on a Struts 1.x architecture that need continuing support. We need to have the discipline to continue to work evolving a 1.2.x world while we're creating a new 2.x one. I think I need to elaborate on my thoughts some more, since I wasn't really clear the first time around... A great deal has happened in web application framework land since Struts came along 3-1/2 years ago. There is a boatload of frameworks out there now, and some of them have some great ideas. What I don't really want to end up with is a Struts 2.0 that is simply a reinvention of what other people have done, with a compatibility layer to make it accessible to Struts 1.x developers. So, what makes Struts Struts? What characteristics do we need to preserve in order to keep it Struts, and retain the greatness that has made it so amazingly popular? How far can we go before the decision to choose Struts 2.0, or not, is no different to a potential developer than the decision to chose any one of the other frameworks out there today? Obviously, compatibility is going to be very important, but I hope that's not all! Regarding 2.x, an important consideration will be base technology platforms -- I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e. Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the presentation technology, etc.). +1 to a J2EE baseline. -- Martin Cooper -- Martin Cooper Craig On Wed, 17 Dec 2003, Don Brown wrote: Ok, I wasn't sure as I didn't want to distract from the onging 1.2.x release work. :) I'll throw out some ideas here, then develop them later in the wiki: - Make Inversion of Control central. By using an IoC framework to wire Struts together, it makes it really easy to extend or improve Struts not only for future development but for users as well. I'd recommend Spring's IoC impl as it is small (100k), really easy to use, and easily extendable. If we wanted to remain more agnostic, there are meta IoC frameworks that let you plug in Pico/Spring/Avalon, etc. - Use XML Schema over DTD's. Give struts config its own default namespace to make it easier for users to mix in elements of other namespaces. An example would be adding custom documentation attributes and elements. Of course the usual arguments for XML Schema over DTD's apply as well. - Replace paths with URL's, allowing for a default protocol. An action path would look like action://foo or a tiles forward would be tiles://tilesdef This would make it easy to plug in handlers to support different presentation engines. If no protocol is specified, the path is handled as usual. - As Ted said, contine with the wildcard theme. Struts should do everything possible to cut down configuration. - Also, again totally agreeing with Ted, make everything interface based, have default implementations, and free apps of HTTP. Ideally, I'd like to see extra effort going into making it easy if not effortless to take a Struts 2.0 app and use the code in a
cvs commit: jakarta-struts/contrib/struts-jericho OVERVIEW.txt
husted 2003/12/18 09:58:34 Modified:contrib/struts-jericho OVERVIEW.txt Log: Move dispatch step into Request Adaptor. Revision ChangesPath 1.2 +8 -2 jakarta-struts/contrib/struts-jericho/OVERVIEW.txt Index: OVERVIEW.txt === RCS file: /home/cvs/jakarta-struts/contrib/struts-jericho/OVERVIEW.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- OVERVIEW.txt 18 Dec 2003 17:27:00 - 1.1 +++ OVERVIEW.txt 18 Dec 2003 17:58:34 - 1.2 @@ -17,6 +17,7 @@ Controller * Receives context and selects the matching mapping * Adds reference to mapping instance to context +* Sets mapping's default Location to context * Removes any expired messages from context * Invokes processor for mapping @@ -35,10 +36,15 @@ * Validate * Invalid * MappingHandler -* Command | Script | Forward | Include +* Command | Script + * Invoke buiness logic + * Affect context state + * Identify resource to render response +* Location + * Identify resource to render response ExceptionHandler -* Intercept any Exception thrown by Processor and dispatch to designated error page. +* Intercept any Exception thrown by Processor and set Location to designated error page. Tags/Tools * Reference Command Context (stored in request) to access framework members - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-jericho/src/conf struts-jericho-config_2_0.dtd
husted 2003/12/18 09:59:30
Modified:contrib/struts-jericho/src/conf
struts-jericho-config_2_0.dtd
Log:
Move forward and include behaviors into Location.
Revision ChangesPath
1.3 +70 -65
jakarta-struts/contrib/struts-jericho/src/conf/struts-jericho-config_2_0.dtd
Index: struts-jericho-config_2_0.dtd
===
RCS file:
/home/cvs/jakarta-struts/contrib/struts-jericho/src/conf/struts-jericho-config_2_0.dtd,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- struts-jericho-config_2_0.dtd 18 Dec 2003 13:20:25 - 1.2
+++ struts-jericho-config_2_0.dtd 18 Dec 2003 17:59:29 - 1.3
@@ -80,6 +80,12 @@
!ENTITY % Scope (request|session|application)
+!-- A LocationType is the string representation of the alternate ways a response
+ can be rendered
+--
+!ENTITY % LocationType (forward|include|redirect)
+
+
!-- == Top Level Elements --
@@ -214,7 +220,7 @@
initial String representation of the initial value for this property.
If not specified, primitives will be initialized to zero and
objects initialized to the zero-argument instantiation of that
- object class. For example, Strings will be initialized to
+ object class. For example, Strings will be initialized to
sizeThe number of array elements to create if the value of the
handler attribute specifies an array, but there is no value
@@ -229,7 +235,7 @@
!ATTLIST form-property size %Integer; #IMPLIED
-!-- The locations element describes a set of Location objects
+!-- The locations element describes a set of Location objects
(org.apache.struts.core.Location) that may be referenced by other elements
and returned by an MappingHandler's execute method. The individual Locations
are configured through nested location elements. Other elements, such
@@ -257,14 +263,14 @@
other elements and by the MappingHandler object at runtime
to select - by its logical name - the resource that should
complete the request/response. May also be referenced by
- an extends attribute of anohter location element.
+ an extends attribute of another location element.
extends Name of a form descriptor that is used as a value template for
this element. All attributes from the template are available to
the new element. Any attribute inherited from the template can
be overridden by providing a new value.
- command Name of a Command to execute before forwarding control to
+ command Name of a Command to execute before dispatching control to
the resource for this element. The Command can be used to
prepare the contexts for the resource.
@@ -276,25 +282,23 @@
a slash (/) character.
mappingRef Set to true if the path specified for resource is a
reference
- to a Mapping. If true, calling getResource will return a URI
to
+ to a Mapping. If true, calling getResource will return a
URI to
the Mapping with the appropriate prefix or extension resolved.
[false]
appRelative Set to true if, in a modular application, the resource
attribute starts with a slash / and should be considered
- relative to application root rather than the current module.
+ relative to the application root rather than the current
module.
[false]
merge Set to true if the resource path should be scanned for
replacement
- parameters {[scope:]xyz}. Replacement parameters must begin
+ parameters: {[scope:]xyz}. Replacement parameters must begin
with a letter. If a scope is not specified, all scopes are
checked in turn (request, session, application).
- redirectSet to true if a redirect instruction should be issued to
- the user-agent so that a new request is issued for this
- Location's resource. If true, RequestDispatcher.Redirect is
- called. If false, RequestDispatcher.forward is called
instead.
- [false]
+ typeMay be set to forward, include, or redirect to indicate
+ what
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Quoting PILGRIM, Peter, FM [EMAIL PROTECTED]: [snip] Although it's not evident from the Jericho DTD, the intention is to use a Context object in the signatures, perhaps the Commons Chain Context, so as to encapsulate Servlet/Portlet dependencies. So you no longer going to pass in request and response objects around, but instead have a context instead. Maybe it would be a little inconvenient for every Action to call ``context.getRequest()'' all the time. Perhaps we can keep them please. I dont mind losing the form bean. I could live with ``context.getForm()'', because for some environments you dont need to buffer a user's input. e.g. web services, or even a flat file. public ActionForward someStateAction( org.apache.commons.chain.Context context, some.generic.request request, some.generic.response response ); And for those of us who have subclassed Action, and ActionForm to create our own super frameworks, this will be very interesting and involved work to say the least/. If you're going to call context.getRequest() at all, then I think you're losing most of the benefits of abstracting away the servlet APIs - if you want to be able to reuse actions in the business tier then there *is* no such thing as a request. Instead, it would be better for a particular Command (for purposes of this discussion, I'm assuming we use something like commons-chain as the plumbing so I use that terminology; it would need to be translated for a different low level API but the concepts sare still the same) that represents the concept of an action to presume that some previous commands in the chain have already pulled the presentation tier specific data out of whatever request objects there were, and made it available as context attributes of the appropriate (framework-specific) types. For example, assume we created an abstraction of a form (what is now ActionForm) to represent incoming data from the user. Copying request parameters into this abstract form thingie would be the job of a command very early in the chain. It's easy to imagine at least three commonly used lead-in actions: * One that pulls request parameters from an HttpServletRequest (servlet api) * One that pulls request parameters from a PortletRequest (portlet api) * One that pulls request parameters from a SOAP request The key value-add is that, once the lead-in command has performed this transition for you, no further commands ever need to know that there *was* such a thing as a request. Those commands would never call getRequest(), because they don't care how the form thingie got there; it contains everything they need to perform their tasks. Therefore, you can reuse the processing command in new and interesting ways -- just to whet the appetite, consider: * In a unit test, where the test case synthesizes a form thingie with known contents, calls the processing logic, and ensures that the correct state changes happened. No real request ever exists. * In an integration app, where you want to have changes made in an existing application also affect data in a separate app. One way to do that would be to synthesize more than one form from the same actual user input, and do all the necessary updates. The business logic for any single transaction has no need to know that it's being used in this new way. * In a batch application (or a messaging appication, or ...) where the incoming data is acquired from data files rather than users, but you want the same sorts of state changes in your back-end systems. The hard part (in terms of designing the framework) is to understand how to factor the reusable concepts, and then what to name them -- on that topic, for example, even the name form thingie might be a little bit to constraining when imagining how the basic idea can be used in more than one context. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Martin Cooper wrote: A great deal has happened in web application framework land since Struts came along 3-1/2 years ago. There is a boatload of frameworks out there now, and some of them have some great ideas. What I don't really want to end up with is a Struts 2.0 that is simply a reinvention of what other people have done, with a compatibility layer to make it accessible to Struts 1.x developers. So, what makes Struts Struts? What characteristics do we need to preserve in order to keep it Struts, and retain the greatness that has made it so amazingly popular? How far can we go before the decision to choose Struts 2.0, or not, is no different to a potential developer than the decision to chose any one of the other frameworks out there today? Obviously, compatibility is going to be very important, but I hope that's not all! I think that's going to come down to I know it when I see it. I'd say that Struts (or any framework) is an aggregation of its components. In Struts 1.0, we had mainly Form, Forward, Mapping, Action, and Messaging components. In Struts 1.1, we added Exception, Validation, Composite (or Tile), and PlugIn components. So long as Struts 2.x retains the same hallmark components in a recognizable form, I'd say it's still Struts. And, so far, I haven't heard anyone suggest anything that couldn't also be implemented in Struts 1.x over time. It's just that deprecation and migration can be a painful process, and sometimes it's better to bite the bullet and tell people that they might have to change this or that if they want to migrate now. We've all admitted several times that we would-a could-a done things differently if we knew then what we know now. All anyone is saying is that now is the time to fix the would-a and could-a's. I don't know about anyone else, but I'm sorta planning on spending yet another twenty years writing business applications, and this seems like a very good time to try and write the best Struts framework we can, and make my declining years easier to bear :) Of course, the important thing will be for whoever is working on a Struts 2.x implementation to eat our own dog food, like we had to do for Struts 1.x. If it doesn't work for us, it's surely not going to work for anyone else. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-jericho README.txt
martinc 2003/12/18 10:14:36 Modified:contrib/struts-jericho README.txt Log: Add Cornerstone (from Jetspeed 2) to the list of frameworks to consider. Revision ChangesPath 1.7 +1 -1 jakarta-struts/contrib/struts-jericho/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-struts/contrib/struts-jericho/README.txt,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- README.txt18 Dec 2003 17:26:33 - 1.6 +++ README.txt18 Dec 2003 18:14:36 - 1.7 @@ -42,7 +42,7 @@ -Also under consideration- -* Services framework. Utilize Spring IoC, HiveMind, Avalon, orPico, et cetera, to configure services. +* Services framework. Utilize Spring IoC, HiveMind, Avalon, Pico, Cornerstone, et cetera, to configure services. * Configuration testing. Integrate utility of Struts TestCase, ideally configured from an XML configuration (a la Canoo Webtest). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What about Struts 2.0 and JSF?
Quoting [EMAIL PROTECTED]: Guys, I am wondering what is the relation between Struts 2.0 and JSF. It should certainly be possible to use JavaServer Faces in your view tier of a Struts 2.0 based app. Will Struts be an implementation of JSF specification? That hasn't been articulated on the list of goals to date. If we want an Apache open source implementation of JSF, I would recommend it be done in a separate project (certainly can be overlapping developers if existing Struts folks are interested). The Struts 2.0 design should probably take into account where JSF is going -- watch for additional news in that regard very soon -- so that integration can happen in response to UI events from a JSF-based UI, but most of what we're talking about for Struts 2.0 is actually in the controller, not the view. Will it be the Reference Implementation (UHUUU)? No. Remember that reference implementation has a specific meaning for Java standards, and the spec lead for a particular JSR is required to deliver the corresponding RI -- In the case of JavaServer Faces (JSR-127), Sun is delivering the RI. There is a (mis)conception, for example, that Tomcat is the RI for the servlet and JSP APIs. That is not the case -- the official RI is the J2EE SDK available at http://java.sun.com/j2ee/1.4/download-dr.html. It happens to *include* code from Tomcat, but this is the real RI. Stutz Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-struts/contrib/struts-jericho README.txt OVERVIEW.txt
husted 2003/12/18 10:26:50 Modified:contrib/struts-jericho README.txt OVERVIEW.txt Log: Mention SOAP. Revision ChangesPath 1.8 +3 -3 jakarta-struts/contrib/struts-jericho/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-struts/contrib/struts-jericho/README.txt,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- README.txt18 Dec 2003 18:14:36 - 1.7 +++ README.txt18 Dec 2003 18:26:50 - 1.8 @@ -12,7 +12,7 @@ * Providing additional extension points from core components so that the Inversion of Control pattern is fully realized. (e.g., a populate method for the FormHandler.) -* Providing POJO signatures that encapsulate servlet/portlet behavior so that applications can be freed of servlet/portlet semantics, if so desired. This strategy would also be applied to optional packages like Validator and Tiles. +* Providing POJO signatures that encapsulate servlet/portlet/soap behavior so that applications can be freed of servlet/portlet/soap semantics, if so desired. This strategy would also be applied to optional packages like Validator and Tiles. * Retain optional access to servlet/portlet objects so that applications can be free to do whatever they need to do. @@ -36,9 +36,9 @@ A second alternative might be to provide an alternate configuration loader that would map the Struts 1.2 elements to Struts Jericho objects at initialization. --Servlet/Portlet/Mock support- +-Servlet/Portlet/Soap/Mock support- -Core components will implement signatures that reference a StrutsContext. Implementations of this interface can be backed by servlet, portlet, or mock implementations as needed. +Core components will implement signatures that reference a StrutsContext. Implementations of this interface can be backed by servlet, portlet, soap, or mock implementations as needed. -Also under consideration- 1.3 +1 -1 jakarta-struts/contrib/struts-jericho/OVERVIEW.txt Index: OVERVIEW.txt === RCS file: /home/cvs/jakarta-struts/contrib/struts-jericho/OVERVIEW.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- OVERVIEW.txt 18 Dec 2003 17:58:34 - 1.2 +++ OVERVIEW.txt 18 Dec 2003 18:26:50 - 1.3 @@ -6,7 +6,7 @@ Command Context * Extends CoR Context to encapsulate framework members needed to process request and render response -Request Adapter (module, portlet, mock) +Request Adapter (servlet module, portlet, SOAP, mock) * Receives request from container (or TestRunner) * Normalizes request path (masks pattern registered with container) * Creates context to wrap request and response objects - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Quoting Vic Cekvenich [EMAIL PROTECTED]: Craig R. McClanahan wrote: Regarding 2.x, an important consideration will be base technology platforms -- I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e. Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the presentation technology, etc.). JDK 1.4, yes. One popular? goal mentioned was: Get away from reliance on Servlet API I like being on Tomcat 4. What does it gain to be Tomcat 5 technically? For the portions of the framework that depend on Servlet 2.4, you get two modest but useful features: * Ability to execute filters on RequestDispatcher.include and RequestDispatcher.forward calls, which is not possible in 2.3. This gives you additional degrees of freedom in how you organize the processing logic of a framework like Struts -- for example, it would now be technically feasible to implement the controller as a filter instead of a servlet. * Ability to define request lifecycle listeners (like the older ones for session and application lifecycle) so you get a complete and consistent event handling model. If your presentation tier is based on JSP 2.0 (instead of 1.1/1.2), you get a very large number of benefits. The most visible ones are: * New ***much*** simpler API for building tag classes (tag instance pooling is gone, single invocation method instead of doStart/doEnd, ability to define a tag that takes an arbitrary list of attributes, ...). * Tag files -- essentially, the ability to write a tag handler using JSP code instead of Java, complete with parameter passing. * EL expressions evaluated everywhere (even template text), so you don't need to limit yourself to just tags that implement support for it (meaning we don't need struts-el variants). What containers support 2.4? How long for users to convert to the new 2.4 containers? It'd be limiting. The timing only matters when we're *done* with Struts 2.0, not now. Based on our past history, I'd bet we're talking 12-18 months before a production quality release of 2.0 would be designed, developed, tested, and evolved to the point where we were happy enough to call it (and the APIs inside it) stable. Because of how long it took for the J2EE 1.4 standards to go final (we were done with servlet and JSP last summer, but had to wait for the web services standards to go final), the various app server vendors are already well on the way towards 1.4 compliance. (Sun's certified server is already available, and is free for development AND production). In the open source world, Tomcat 5 already has production quality support, of course, and Jetty at least is not far behind (Greg is using Jasper2 for the JSP 2.0 stuff, so all he's got to do is catch up on the servlet 2.4 changes, which are pretty modest). If it ends up being interface, so it could be even used from Soap or applications (the discussed interface execute(Context ctx) ; ) it won't matter much. I agree that execute(Context ctx) is the right sort of method signature for the low level elements. Come to think of it, that's already the signature used in commons-chain :-). .V ps: I would like light IoC to be considered just a bit more as platform, Pico, Oscar. Not Spring or Avalon. All of these are interesting, but I think there's two levels of IoC that need to be thought about: * How the various pieces of Struts itself glue themselves together. * How application level services are composed and made available. It seems to me that different choices are possible at these two levels, and that (if different) the former should be lighter weight than the latter. But we can't really pick particular technologies without having identified the needs and use cases first. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
I don't think I'm going to articulate this question very clearly, but hopefully my drift will be gotten, so to speak. If we're talking about making Struts independent of Servlets, then what part of Struts would depend on either Servlet 2.3 or Servlet 2.4? Rather, how will we partition Struts so that we know our boundaries? Presumably in a chain-like world, you could have Servlet 2.3 pre-processing chains and Servlet 2.4 pre-processing chains, and of course we're going to have view post-processors for XSLT, Velocity... so why shouldn't there be JSP 1.2 and JSP 2.0 post-processors? I suppose we ought to draft a glossary to make sure we all agree on these various concepts... Joe At 10:51 AM -0800 12/18/03, Craig R. McClanahan wrote: For the portions of the framework that depend on Servlet 2.4, you get two modest but useful features: * Ability to execute filters on RequestDispatcher.include and RequestDispatcher.forward calls, which is not possible in 2.3. This gives you additional degrees of freedom in how you organize the processing logic of a framework like Struts -- for example, it would now be technically feasible to implement the controller as a filter instead of a servlet. * Ability to define request lifecycle listeners (like the older ones for session and application lifecycle) so you get a complete and consistent event handling model. If your presentation tier is based on JSP 2.0 (instead of 1.1/1.2), you get a very large number of benefits. The most visible ones are: * New ***much*** simpler API for building tag classes (tag instance pooling is gone, single invocation method instead of doStart/doEnd, ability to define a tag that takes an arbitrary list of attributes, ...). * Tag files -- essentially, the ability to write a tag handler using JSP code instead of Java, complete with parameter passing. * EL expressions evaluated everywhere (even template text), so you don't need to limit yourself to just tags that implement support for it (meaning we don't need struts-el variants). -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Martin Cooper wrote: I think I need to elaborate on my thoughts some more, since I wasn't really clear the first time around... A great deal has happened in web application framework land since Struts came along 3-1/2 years ago. new technologies: bytecode manipulation IoC SOA filters xml (XML Beans?) AOP (just to list all) Oscar Unit Testing scripting (including client javascript) XML-RPC (not really new, just I like ) JDK 1.4 (interesting quirk: should jericko use the poor JDK logger? Maybe, but it's poor.) Some can be leveraged... others do not apply. So, what makes Struts Struts? What characteristics do we need to preserve in order to keep it Struts, and retain the greatness that has made it so amazingly popular? My answer is: -light weight. If jericho is bloated, then IMO it fails. -formbeans. The concept that bean properties correspond to a (html data entry) form. (thinking outside the box: maybe a XML Document that maps to form properties can also be a form bean in Jericho). -it had several clear extension points And what it did not have: - A DAO. Many popular frameworks of the day went down with their DAO. It was a minimalist framework, that did 80% of what you need and it did not get in the way when you wanted it to do things it was not designed for. Therefore, one person needs to write most of Jericho over a single weekend and not try to please a committee, just their own business application and do initial check in! :-) Lets not forget validation, btw. it should not be an after taught. Keep same? yes. .V perfection is achived when you have nothing left to remove by Saint something or other - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Quoting Joe Germuska [EMAIL PROTECTED]: I don't think I'm going to articulate this question very clearly, but hopefully my drift will be gotten, so to speak. If we're talking about making Struts independent of Servlets, then what part of Struts would depend on either Servlet 2.3 or Servlet 2.4? Even if the core framework is independent of the presentation tier APIs, you still need an adapter layer (often called a binding) between the particular presentation API in use and the fundamental controller capabilities. As I pointed out in a previous message, I can see three very obvious bindings (to servlets, to portlets, and to SOAP) that we'd undoubtedly want to include in the basic package -- but we know we've succeeded when you can use the same actions in each of those three environments (to perform the same transaction). Rather, how will we partition Struts so that we know our boundaries? Presumably in a chain-like world, you could have Servlet 2.3 pre-processing chains and Servlet 2.4 pre-processing chains, and of course we're going to have view post-processors for XSLT, Velocity... so why shouldn't there be JSP 1.2 and JSP 2.0 post-processors? For servlet 2.3 versus 2.4, one approach to building frameworks would be to architect the controller as a filter (or set of cooperating filters) rather than as a servlet. That is not a practical reality in servlet 2.3 because you can't interpose filters on a RequestDispatcher call. It's probably feasible to have a decomposed request processor that can be implemented as either a set of filters (which, after all, is sort of the CoR pattern again, just with different APIs) or as a servlet. In practical terms, though, it's easier to abstract the layers if we stick with a servlet as the basic adapatation gadget. The main reason I'm interested in J2EE 1.4 as the base platform is for JSP 2.0. But the choice between JSP 1.2 and JSP 2.0 should have zero impact on the organization of the request processor -- it should be as totally an independent decision as possible. However, if you choose JSP 2.0 for the minimum platform for JSP-based presentation stuff, you get servlet 2.4 for free to use in the controller tier if you want. I suppose we ought to draft a glossary to make sure we all agree on these various concepts... Joe Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Quoting Martin Cooper [EMAIL PROTECTED]: On Thu, 18 Dec 2003, Craig R. McClanahan wrote: Quoting Vic Cekvenich [EMAIL PROTECTED]: Craig R. McClanahan wrote: Regarding 2.x, an important consideration will be base technology platforms -- I'm in favor of using J2SE 1.4 and the relevant standards from J2EE 1.4 (i.e. Servlet 2.4 for web applications, JSP 2.0 if you're using JSP as the presentation technology, etc.). JDK 1.4, yes. One popular? goal mentioned was: Get away from reliance on Servlet API I like being on Tomcat 4. What does it gain to be Tomcat 5 technically? For the portions of the framework that depend on Servlet 2.4, you get two modest but useful features: * Ability to execute filters on RequestDispatcher.include and RequestDispatcher.forward calls, which is not possible in 2.3. This gives you additional degrees of freedom in how you organize the processing logic of a framework like Struts -- for example, it would now be technically feasible to implement the controller as a filter instead of a servlet. It would certainly be technically feasible to do that, but are there practical advantages to doing so? The only thing I can think of is that it's easy to punt on a request and let something else (i.e. another filter or a servlet) handle it, but I'm not sure why I would want to do that. Any good examples? One of the things people have said they liked about using a chain to decompose RequestProcessor is that you could easily compose your own chains, adding your own custom processing stages and so on. You can do exactly the same thing with Filters by making each processXxx method its own filter, and using (say) the request attributes to play the role of the Context object in commons-chain. Filters have an additional capability if you're building a servlet-specific framework -- they can wrap the actual request and response objects that are passed on to the next filter in the chain, so you can implement some interesting things not directly possible with a chain based implementation -- such as caching or on-the-fly compression of the response. -- Martin Cooper Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Craig R. McClanahan wrote: One of the things people have said they liked about using a chain to decompose RequestProcessor is that you could easily compose your own chains, adding your own custom processing stages and so on. You can do exactly the same thing with Filters by making each processXxx method its own filter, and using (say) the request attributes to play the role of the Context object in commons-chain. Filters have an additional capability if you're building a servlet-specific framework -- they can wrap the actual request and response objects that are passed on to the next filter in the chain, so you can implement some interesting things not directly possible with a chain based implementation -- such as caching or on-the-fly compression of the response. Craig I do not get chains, but Hookom posted this link: http://java.sun.com/blueprints/corej2eepatterns/Patterns/InterceptingFilter.html which I sort of get (sort of) and it's my favoirte chain impl. So if we can use filters or other chain, somone clever could write an chainRequestProcessor *interface*, that could be impledented for JSP2.0 filter... and then somone else could later write a JSP 1.2 version, even non filter versions. ? So I like chain as interface, and action as interface. I am thinking of fliping sides on FormBean as interface, I am now leaning against formbeans being an interface. FormBean is a concept (properties that map to form elements), plus this idea of XML as a FormBean. It could be a List or String or anything. As long as it itself does not do DAO, and it maps to a form, good. (but do have way to unit test it w/o a container) For starters so the JSTL x: tag can be used instead of c:out, plus some Stxx things. (Then maybe a way to make HTML tag submit XML Doc, multi row and all). .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Struts EL Distro
The binary Struts build includes struts-el in the contrib directory. Why does struts-el/lib include the commons-*.jars and JSTL jars? The common jars are already distributed with the standard Struts build and the JSTL jars should be downloaded separately. Considering the frequency of Struts downloads and our large 21MB distro size, removing these duplicate jars will save Apache a considerable amount of bandwidth. David __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
I am thinking of fliping sides on FormBean as interface, I am now leaning against formbeans being an interface. FormBean is a concept (properties that map to form elements), plus this idea of XML as a FormBean. It could be a List or String or anything. XML as a FormBean! That got my attention... Say we want to populate customer information where a user can edit it like in an Excel spreadsheet. If the Action accesses a web service and receives a SOAP response and some XML objects in the SOAP response, sometimes it is too much processing to convert XML to Java objects if it is a lot of XML (for example: If the web service returns a list of 50 customers with detailed info). In such cases it may make more sense to do an XSLT transformation over the XML objects and render the form. Any suggestions on how this could be done in Struts 2.0? Thanks, Mete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts EL Distro
I agree, also each of the *.war files have a copy of the .jar files. Would it be acceptable to have a script or ant to gut the WEB-INF/lib directory of war files before distribution then reinsert them by running another script after they are unpacked by the user? The Distro would be less than 4MB if we did that. We could create another ant target that never assembles the war files in the first place, and another 'ant demo-war' command could package the already compiled *.class files of the app into a war. -Rob -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, December 18, 2003 09:54 PM To: [EMAIL PROTECTED] Subject: Struts EL Distro The binary Struts build includes struts-el in the contrib directory. Why does struts-el/lib include the commons-*.jars and JSTL jars? The common jars are already distributed with the standard Struts build and the JSTL jars should be downloaded separately. Considering the frequency of Struts downloads and our large 21MB distro size, removing these duplicate jars will save Apache a considerable amount of bandwidth. David __ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
--- Mete Kural [EMAIL PROTECTED] wrote: FormBean is a concept (properties that map to form elements), plus this idea of XML as a FormBean. It could be a List or String or anything. XML as a FormBean! That got my attention... What I would like to explore is the possibility of reusing existing DTOs/VOs in the form beans. Perhaps they (DTO/VO) won't be used to hold the form values directly, but the framework can use them to determine the fields of the form. The framework can already interpret whether the input string is valid or not, there's a good chance it'll only take a step or two more to let the framework convert it to the right data type. This will really reduce DRY violations between DTO/VO objects, form beans and validation rule mappings. For a given form/action, the framework will be supplied with the FQCN of the DTO/VO. From there, it can determine what the fields of the form will be. The form bean validation/descriptor XML will provide the validation information and any conversion rules as needed to format/parse between the value object and the string representation for the form bean. I've been playing around with this idea for sometime now, and wouldn't mind working on its code if there's interest in it. __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 18237] - Tiles excessive memory usage
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=18237. 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=18237 Tiles excessive memory usage [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14471] - validator-rules.xml JavaScript fails when field not present in jsp
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14471. 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=14471 validator-rules.xml JavaScript fails when field not present in jsp [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16810] - Javascript Date validation for datePattern not supported
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=16810. 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=16810 Javascript Date validation for datePattern not supported [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 22:59 --- See #22384 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16946] - SwitchAction not setting context properly for tiles
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=16946. 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=16946 SwitchAction not setting context properly for tiles [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17977] - nested:iterate loses index with jsp: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=17977. 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=17977 nested:iterate loses index with jsp:include [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Enhancement Target Milestone|1.1 Family |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 19543] - Problem with radio buttons and focusField.focus()
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=19543. 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=19543 Problem with radio buttons and focusField.focus() [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 23:02 --- See #11520 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17977] - nested:iterate loses index with jsp: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=17977. 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=17977 nested:iterate loses index with jsp:include [EMAIL PROTECTED] changed: What|Removed |Added Severity|Enhancement |Minor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20854] - Error with nesting tags in separate pages
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=20854. 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=20854 Error with nesting tags in separate pages [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Minor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21239] - nested:iterate not setting current object
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=21239. 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=21239 nested:iterate not setting current object [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Minor Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21254] - nested:messagePresent tag does not append parent name to indexed property
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=21254. 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=21254 nested:messagePresent tag does not append parent name to indexed property [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable Priority|Other |High - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21263] - browser frozen on file upload when displaying errors using a large JSP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21263. 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=21263 browser frozen on file upload when displaying errors using a large JSP [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21517] - tile definition's put tag works in non-standard way when it is of the 'definition' type
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=21517. 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=21517 tile definition's put tag works in non-standard way when it is of the 'definition' type [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21613] - nested:error tag stopped displaying error messages (of certain scenario) when upgraded from Struts1.1 R1 to Final version
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=21613. 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=21613 nested:error tag stopped displaying error messages (of certain scenario) when upgraded from Struts1.1 R1 to Final version [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable Priority|Other |High Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21890] - MessageResources quoting single quotes
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=21890. 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=21890 MessageResources quoting single quotes [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21896] - DefinitionDispatcherAction does not recegnize anchor correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21896. 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=21896 DefinitionDispatcherAction does not recegnize anchor correctly [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Enhancement Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
For a given form/action, the framework will be supplied with the FQCN of the DTO/VO. From there, it can determine what the fields of the form will be. The form bean validation/descriptor XML will provide the validation information and any conversion rules as needed to format/parse between the value object and the string representation for the form bean. That sounds very interesting. I think there is interest in having support for dynamic forms where the fields of the form are determined dynamically rather than hardcoded in the JSP. What are the ideas on how to handle dynamic field names (and number of fields) in Struts 2.0? Let's say that we are designing a dynamic customer information editing form. Every user has different preferences on what fields they want to edit or allowed to edit. Action class accesses a web service and receives a SOAP response with exactly those fields that are fit for this user. How could Struts assemble the form dynamically and pre-populate the customer information and then validate it when the user submits? Regards, Mete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 21992] - Localized number formatting inconsistency
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=21992. 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=21992 Localized number formatting inconsistency [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable Priority|Other |High - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22207] - serialization and deserialization
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=22207. 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=22207 serialization and deserialization [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|struts- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22371] - DynaActionForm is unable to return nulls
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=22371. 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=22371 DynaActionForm is unable to return nulls [EMAIL PROTECTED] changed: What|Removed |Added Component|Controller |Documentation - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22703] - date field pattern in struts form: inconsistency
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=22703. 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=22703 date field pattern in struts form: inconsistency [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 23:19 --- ActionForms are not intended to support binary types such as Dates. The idiom is to collect the input as Strings, and then do the coversion when the String is transferred to the business object. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23020] - simple page action mappings within modules to jsp's not working
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=23020. 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=23020 simple page action mappings within modules to jsp's not working [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
I think we're tackling different issues here. What I'm trying to avaoid is having (1) a data transfer object used by the different tiers, and (2) a form bean object or dyna form bean definition which is a close reflection of the fields that the DTO already defines, and (3) a validation rule xml which lists down all/most of the fields along with rules on how to validate each. Of course, I'll also need to write code to convert my DTO to a form bean and vice versa. I'm thinking we can lose the explicit form bean definition and the code which converts between the DTO and form bean. --- Mete Kural [EMAIL PROTECTED] wrote: For a given form/action, the framework will be supplied with the FQCN of the DTO/VO. From there, it can determine what the fields of the form will be. The form bean validation/descriptor XML will provide the validation information and any conversion rules as needed to format/parse between the value object and the string representation for the form bean. That sounds very interesting. I think there is interest in having support for dynamic forms where the fields of the form are determined dynamically rather than hardcoded in the JSP. What are the ideas on how to handle dynamic field names (and number of fields) in Struts 2.0? Let's say that we are designing a dynamic customer information editing form. Every user has different preferences on what fields they want to edit or allowed to edit. Action class accesses a web service and receives a SOAP response with exactly those fields that are fit for this user. How could Struts assemble the form dynamically and pre-populate the customer information and then validate it when the user submits? Regards, Mete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
The documentation's a bit sketchy, but the FormProc project in SourceForge works this way. The idea is that it validates and populates another object directly from the request parameters. At some point, I'd like to try to make it an alternative to the Commons/Struts Validator. But this would be easier to do once the composable request processor is in place. -Ted. Hubert Rabago wrote: --- Mete Kural [EMAIL PROTECTED] wrote: FormBean is a concept (properties that map to form elements), plus this idea of XML as a FormBean. It could be a List or String or anything. XML as a FormBean! That got my attention... What I would like to explore is the possibility of reusing existing DTOs/VOs in the form beans. Perhaps they (DTO/VO) won't be used to hold the form values directly, but the framework can use them to determine the fields of the form. The framework can already interpret whether the input string is valid or not, there's a good chance it'll only take a step or two more to let the framework convert it to the right data type. This will really reduce DRY violations between DTO/VO objects, form beans and validation rule mappings. For a given form/action, the framework will be supplied with the FQCN of the DTO/VO. From there, it can determine what the fields of the form will be. The form bean validation/descriptor XML will provide the validation information and any conversion rules as needed to format/parse between the value object and the string representation for the form bean. I've been playing around with this idea for sometime now, and wouldn't mind working on its code if there's interest in it. __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
The dynamic field use case comes up all the time, but I have trouble getting my head around it. What would be helpful would be a example application that people could play with. You can take thought experiments only so far :) My first question would be how would anything (never mind Struts) address this use case? The other half of the problem would be creating a dynamic query to go with the dynamic form, so that only the fields you are editing are updated. -Ted. Mete Kural wrote: For a given form/action, the framework will be supplied with the FQCN of the DTO/VO. From there, it can determine what the fields of the form will be. The form bean validation/descriptor XML will provide the validation information and any conversion rules as needed to format/parse between the value object and the string representation for the form bean. That sounds very interesting. I think there is interest in having support for dynamic forms where the fields of the form are determined dynamically rather than hardcoded in the JSP. What are the ideas on how to handle dynamic field names (and number of fields) in Struts 2.0? Let's say that we are designing a dynamic customer information editing form. Every user has different preferences on what fields they want to edit or allowed to edit. Action class accesses a web service and receives a SOAP response with exactly those fields that are fit for this user. How could Struts assemble the form dynamically and pre-populate the customer information and then validate it when the user submits? Regards, Mete - 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 23034] - maxlength not reading from resource bundle by default
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=23034. 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=23034 maxlength not reading from resource bundle by default [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23127] - Page attribute of img and image tags doesn't use pagePattern setting
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=23127. 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=23127 Page attribute of img and image tags doesn't use pagePattern setting [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable Priority|Other |High Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23255] - FormFile#getFileName() problem in multibyte character file name
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=23255. 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=23255 FormFile#getFileName() problem in multibyte character file name [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23337] - 'integer' rule doesn't work properly with indexed properties
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=23337. 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=23337 'integer' rule doesn't work properly with indexed properties [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |1.2 Family --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 23:35 --- Have - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23370] - Unable to validate indexed properties
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=23370. 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=23370 Unable to validate indexed properties [EMAIL PROTECTED] changed: What|Removed |Added Severity|Blocker |Normal Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
Ted Husted wrote: The dynamic field use case comes up all the time, but I have trouble getting my head around it. What would be helpful would be a example application that people could play with. And making it that dynamic defeats testing and layers. I am not aware of even Client Server uses cases for dynamic fields. Simple example: A report for Jasper and SQL. If you have diferent sql fields, it's a diferent report. Struts example: Clients give you a mock up of a view somehow, you then know the fileds on the view, you know the formbean properties. (and then implement a DAO to CRUD the formbean contract) So dyamic fields I think should be in the 20% not to be done by core Struts. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23834] - jsessionid appended twice in html-el:img
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=23834. 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=23834 jsessionid appended twice in html-el:img [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24236] - Validaor error while validator for fields in select element
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=24236. 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=24236 Validaor error while validator for fields in select element [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24486] - Special Charactes like German Umlaute don't work with multipart upload
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=24486. 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=24486 Special Charactes like German Umlaute don't work with multipart upload [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 23:38 --- *** This bug has been marked as a duplicate of 23255 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23255] - FormFile#getFileName() problem in multibyte character file name
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=23255. 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=23255 FormFile#getFileName() problem in multibyte character file name [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 23:38 --- *** Bug 24486 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24503] - all form variables lost after a MAX_LENGTH_EXCEEDED_ERROR
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=24503. 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=24503 all form variables lost after a MAX_LENGTH_EXCEEDED_ERROR [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24631] - Struts tags use bytes of UTF-8 for urlencoding unconditionally
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=24631. 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=24631 Struts tags use bytes of UTF-8 for urlencoding unconditionally [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAvailable Priority|Other |High Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24638] - upload-utf8.jsp doesn't work with bea weblogic server 7.0 - 8.1
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=24638. 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=24638 upload-utf8.jsp doesn't work with bea weblogic server 7.0 - 8.1 [EMAIL PROTECTED] changed: What|Removed |Added Severity|Blocker |Enhancement Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24657] - Context-relative redirects duplicate context-root in URL (in WAS)
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=24657. 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=24657 Context-relative redirects duplicate context-root in URL (in WAS) [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24657] - Context-relative redirects duplicate context-root in URL (in WAS)
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=24657. 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=24657 Context-relative redirects duplicate context-root in URL (in WAS) [EMAIL PROTECTED] changed: What|Removed |Added Resolution|WORKSFORME |INVALID - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24670] - File name is not decoded properly when character encoding is different than on application server
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=24670. 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=24670 File name is not decoded properly when character encoding is different than on application server [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 23:43 --- *** This bug has been marked as a duplicate of 23255 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23255] - FormFile#getFileName() problem in multibyte character file name
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=23255. 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=23255 FormFile#getFileName() problem in multibyte character file name [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 23:43 --- *** Bug 24670 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 24820] - Encoding for file names not properly handled
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=24820. 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=24820 Encoding for file names not properly handled [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 23:43 --- *** This bug has been marked as a duplicate of 23255 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23255] - FormFile#getFileName() problem in multibyte character file name
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=23255. 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=23255 FormFile#getFileName() problem in multibyte character file name [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 23:43 --- *** Bug 24820 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25023] - OutOfMemoryErrors after file uploads
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=25023. 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=25023 OutOfMemoryErrors after file uploads [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25134] - bean:write format on Dates doesn't use the locale
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=25134. 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=25134 bean:write format on Dates doesn't use the locale [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25165] - tile plugin not initialized when using two struts-configs for a single module.
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=25165. 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=25165 tile plugin not initialized when using two struts-configs for a single module. [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25192] - The package name of BigDecimal and BigInteger is mistaken.
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=25192. 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=25192 The package name of BigDecimal and BigInteger is mistaken. [EMAIL PROTECTED] changed: What|Removed |Added Component|Web Site|Documentation Summary|The package name of |The package name of |BigDecimal and BigInteger is|BigDecimal and BigInteger is |mistaken. |mistaken. Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23034] - maxlength not reading from resource bundle by default
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=23034. 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=23034 maxlength not reading from resource bundle by default [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 23:50 --- I think this is a valid issue. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum)
I use dynamic fields all the time. The fields visible to the user are based on a usage profile, for example if a user is entering orders and his profile is for export orders he sees a booking field, if his profile is for domestic orders he doesn't. This is a view issue, the booking should be in the model and passed through struts NMW (I don't believe the small DB optimization is worth the trouble). The issue to struts and the model is the conditional validation. There is one other place where this is a problem and that is with the struts method of handling checkboxes since all of them on a specific form have to be reset and if they are conditional in the view it poses a problem although they pose a problem on a multipage form in any case. Edgar -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Thursday, December 18, 2003 6:29 PM To: Struts Developers List Subject: Re: Struts 2.0 Ideas (was Re: Struts 2.0 Discussion Forum) The dynamic field use case comes up all the time, but I have trouble getting my head around it. What would be helpful would be a example application that people could play with. You can take thought experiments only so far :) My first question would be how would anything (never mind Struts) address this use case? The other half of the problem would be creating a dynamic query to go with the dynamic form, so that only the fields you are editing are updated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25291] - XHTML attribute values
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=25291. 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=25291 XHTML attribute values [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25383] - LookupDispatchAction does not work without message-resource definition
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=25383. 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=25383 LookupDispatchAction does not work without message-resource definition [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-12-18 23:59 --- *** This bug has been marked as a duplicate of 21226 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25434] - multipart/form-data loses all request parameters in action forward.
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=25434. 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=25434 multipart/form-data loses all request parameters in action forward. [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25291] - XHTML attribute values newline filtering
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=25291. 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=25291 XHTML attribute values newline filtering [EMAIL PROTECTED] changed: What|Removed |Added Summary|XHTML attribute values |XHTML attribute values ||newline filtering - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25488] - Nesting tags are incorrectly clearing parent nesting context.
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=25488. 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=25488 Nesting tags are incorrectly clearing parent nesting context. [EMAIL PROTECTED] changed: What|Removed |Added Severity|Critical|Normal Keywords||PatchAvailable Priority|Other |High Target Milestone|--- |1.2 Family - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25521] - Redirect to error page problem when JSP Exception occurs in tiles
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=25521. 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=25521 Redirect to error page problem when JSP Exception occurs in tiles [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-12-19 00:02 --- I believe the nature of Tiles is such that by the time the error is detected, the response has already begun, so dispatching to another page is not an option. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
