cvs commit: jakarta-struts/web/test/test/org/apache/struts/taglib/html TestOptionsTag1.jsp

[jmitchell]

jmitchell2004/01/02 22:07:56

  Added:   src/test/org/apache/struts/taglib/html TestOptionsTag1.java
   web/test/test/org/apache/struts/taglib/html
TestOptionsTag1.jsp
  Log:
  Add 10 new tests that cover "some" of the functionality
  provided by html:options.  I'll add additional tests for complete
  coverage soon.
  
  Revision  ChangesPath
  1.1  
jakarta-struts/src/test/org/apache/struts/taglib/html/TestOptionsTag1.java
  
  Index: TestOptionsTag1.java
  ===
  /*
   * $Header: 
/home/cvs/jakarta-struts/src/test/org/apache/struts/taglib/html/TestOptionsTag1.java,v 
1.1 2004/01/03 06:07:56 jmitchell Exp $
   * $Revision: 1.1 $
   * $Date: 2004/01/03 06:07:56 $
   *
   * 
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999-2003 The Apache Software Foundation.  All rights
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer.
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:
   *   "This product includes software developed by the
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Struts", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior written
   *permission of the Apache Group.
   *
   * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
   * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
   * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
   * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
   * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
   * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
   * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
   * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
   * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   * 
   *
   * This software consists of voluntary contributions made by many
   * individuals on behalf of the Apache Software Foundation.  For more
   * information on the Apache Software Foundation, please see
   * .
   *
   */
  package org.apache.struts.taglib.html;
  
  import java.util.Locale;
  
  import javax.servlet.jsp.PageContext;
  
  import junit.framework.Test;
  import junit.framework.TestSuite;
  
  import org.apache.cactus.JspTestCase;
  import org.apache.struts.Globals;
  import org.apache.struts.taglib.SimpleBeanForTesting;
  import org.apache.struts.util.LabelValueBean;
  
  /**
   * Suite of unit tests for the
   * org.apache.struts.taglib.html.OptionsTag class.
   *
   * @author James Mitchell
   */
  public class TestOptionsTag1 extends JspTestCase {
  
  
  /**
   * Defines the testcase name for JUnit.
   *
   * @param theName the testcase's name.
   */
  public TestOptionsTag1(String theName) {
  super(theName);
  }
  
  /**
   * Start the tests.
   *
   * @param theArgs the arguments. Not used
   */
  public static void main(String[] theArgs) {
  junit.awtui.TestRunner.main(new String[] {TestOptionsTag1.class.getName()});
  }
  
  /**
   * @return a test suite (TestSuite) that includes all methods
   * starting with "test"
   */
  public static Test suite() {
  return new TestSuite(TestOptionsTag1.class);
  }
  
  private void runTest(String whichTest, String locale) throws Exception {
  pageContext.setAttribute(Globals.LOCALE_KEY,
  new Locale(locale, locale),

Re: [Proposal] ActionFactory refactoring

[BaTien Duong]

Vic Cekvenich wrote:



Don Brown wrote:
 It would take probably a few hours
to code so little effort is "wasted" when the struts-chain move takes
place.
I think that is the key at the end of the day. I think it be more 
effective the few hours be spent on integrating IoC into struts-chain 
Yes, integration of Struts-chain and IoC seems to hold a key for 
managing a group of services that are passed via Struts-Chain as a 
controller. I am exploring this with PicoContainer (using 
DefaultLifeCyclePicoContainer which provides both life cycle management 
and Config object).

BaTien
DBGROUPS
but I do not need to remind anyone I am not a commiter, and even then 
each comiter can commit what they please, but I would rather see a 
design of IoC in CoR. If CoR already does digester, it can't be to far 
away from some level of alpha. I think it easier to work with a clean 
sheet of paper, but your preference, thanks for contributions.
Maybe if there is a way to create a commons-IoC-api of interfaces that 
could be implemented as Nano, Hivemind, etc.  and  I duno.

.V



-
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 25860] - html:cancel alteration to allow for default enter key form submission

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=25860

html:cancel alteration to allow for default enter key form submission





--- Additional Comments From [EMAIL PROTECTED]  2004-01-03 00:49 ---
I've gone ahead and added a "javascript" field to the TLD/userGuide and appropriate 
members to 
the CancelTag.java class.  Now, the rendering is by default done using the html submit 
method, 
but if the developer adds javascript="true", then the button will be rendered using a 
javascript 
button/hidden element combination.

This is shown in the above (latest) patch.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25860] - html:cancel alteration to allow for default enter key form submission

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=25860

html:cancel alteration to allow for default enter key form submission





--- Additional Comments From [EMAIL PROTECTED]  2004-01-03 00:46 ---
Created an attachment (id=9778)
Patch for adding a javascript property to the TLD and CancelTag.java

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] ActionFactory refactoring

[Craig R. McClanahan]

Quoting Don Brown <[EMAIL PROTECTED]>:

> What if we extracted the creation of Actions and ActionForms (including
> DynaActionForms) into an ActionFactory, overridable by the user?
> 

The idea of factories for all Struts objects is an appealing one (I don't buy
the "too hard to teach" assertion either -- if you don't like teaching it, go
tell the GoF that they've got things all wrong :-).  The idea of a single
factory for all of them isn't quite so appealing -- every time we want to add a
new Struts API object, we need to go back and modify the standard factory
class, which is messy.

One interesting approach to this would be to add a responsibility to the
existing set of FooConfig objects, adding an appropriate create method to each.
 After all, if you want a specialized type of Action or ActionForm object,
you're probably going to need someplace to store extra configuration
information also, and the config object is exactly where you'd want to add
those properties.  Instead of createDynaActionForm() and
createDefaultActionForm(), then, we'd simply have createActionForm() on the
FormBeanConfig class, and it would do the right thing.  Using this approach,
configuring a specialized config bean class automatically configures a new
factory method as well, so you don't have to change two configuration settings
in struts-config.xml either.

An additional decision related to this whole condept, of course, is whether we
stick with the pure JavaBeans style object creation (zero-args constructor,
configure everything with property setters) or something like what Pico wants
(everything configured by arguments to the constructor).  I've dealt with
enough tools vendors in the last couple of years to be convinced that the
former (JavaBeans style) is *substantially* easier to build tools for, and
would therefore favor continuing that design pattern for any kinds of objects
(and object factories) that we create in the future.

Craig McClanahan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] ActionFactory refactoring

[Don Brown]

Heh, in my first proposal, I mentioned these bugs by name and URL too :)

Don

On Fri, 2 Jan 2004, Ted Husted wrote:

> On Fri, 02 Jan 2004 13:42:48 -1000 (HST), Don Brown wrote:
> > Ok, sounds good.  I'll create a bugzilla entry and post the patches
> > there.
>
> Here's an old one that you could use:
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=23583
>
> -T.
>
>
>
> -
> 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: [Proposal] ActionFactory refactoring

[Ted Husted]

On Fri, 02 Jan 2004 13:42:48 -1000 (HST), Don Brown wrote:
> Ok, sounds good.  I'll create a bugzilla entry and post the patches
> there.

Here's an old one that you could use:

http://issues.apache.org/bugzilla/show_bug.cgi?id=23583

-T.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] ActionFactory refactoring

[Ted Husted]

On Fri, 02 Jan 2004 13:42:48 -1000 (HST), Don Brown wrote:
> Ok, sounds good.  I'll create a bugzilla entry and post the patches
> there.

Speaking of factories ...

http://issues.apache.org/bugzilla/show_bug.cgi?id=13638

-T.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] ActionFactory refactoring

[Don Brown]

On Fri, 2 Jan 2004, Ted Husted wrote:

> My one concern is the ActionServlet reference in the signature. I don't
> feel good about adding any more http dependencies to interfaces we may
> have to live with for some time. But it may be unavoidable, and when we
> do start encapsulating http, this whole she-bang might be encapsulated
> as well.

I agree, however, when we do write Servlets out of Struts, I think
everything will need to be rewritten, including this factory and the
objects it creates.  Since this is more of an internal refactoring than a
new feature, I think we don't have to be as concerned about
backward-compatibility, especially since writing Servlets out of Struts
will break everything anyways. (of course by "writing Servlets out of
Struts" I mean removing Servlet dependencies in Struts)

>
> If you can do it over the weekend, and post a patch that people could
> review first, and you felt confident in the code, I would say that it
> could still make the 1.2.0 cut. I feel strongly that we need to address
> the remaining problem reports regarding pagePattern et cetera. I'm
> actively working  on the module examples application now, but the
> application and the fixes aren't going to happen before Monday.
>
> Of course, an equally reasonable opinion would be to hold the patch for
> after the 1.2.0 roll, so that it can live in the nightly build for
> awhile. But it seems like a fairly straight-forward matter to me, and
> should either work or not.

Ok, sounds good.  I'll create a bugzilla entry and post the patches there.

Don

>
> -Ted.
>
> On Fri, 02 Jan 2004 12:17:16 -1000 (HST), Don Brown wrote:
> > Yeah, I wasn't sure what to call them either.  I think it would be
> > nice to have one that will create the form from the config, no
> > matter what type it is, but still have others that create the
> > specific type.  This is mostly useful for testing as it makes it
> > easy to create dynaforms, a feature I've been hearing a lot.  Of
> > course, it could just be two methods, and if you just wanted a
> > dynaform, create a FormBeanConfig and set dynamic to true.
> >
> > As for when, it doesn't matter.  I could easily put it in over the
> > weekend, code and tests, but if we are trying to get 1.2 out the
> > door, it can wait.
> >
> > Don
> >
> >
> > On Fri, 2 Jan 2004, Martin Cooper wrote:
> >
> >
> >> Off the top of my head (meaning I haven't thought through all of
> >> the possible ramifications yet ;), I like this idea. I know that
> >> when I added factories to Commons FileUpload, it took the ability
> >> to customise things to a level that just isn't possible with
> >> straight 'new' coding. I can see how the same would be true for
> >> Actions as well.
> >>
> >> I'm not sure about the specific API you suggest. I assume by
> >> "default" you mean the non-dyna flavour? Something about the API
> >> doesn't "feel" right, but I'll try to give it some thought later
> >> and see if I can come up with anything better.
> >>
> >> BTW, I assume you're proposing this as a post-1.2.0 change?
> >>
> >>
> >> --
> >> Martin Cooper
>
>
>
> -
> 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: [Proposal] ActionFactory refactoring

[Ted Husted]

IMHO, if we were writing Struts today, then this definitely would have been a factory 
in the first place. So making it a factory now seems reasonable, so long as someone is 
willing to do the work :)

My one concern is the ActionServlet reference in the signature. I don't feel good 
about adding any more http dependencies to interfaces we may have to live with for 
some time. But it may be unavoidable, and when we do start encapsulating http, this 
whole she-bang might be encapsulated as well.

If you can do it over the weekend, and post a patch that people could review first, 
and you felt confident in the code, I would say that it could still make the 1.2.0 
cut. I feel strongly that we need to address the remaining problem reports regarding 
pagePattern et cetera. I'm actively working  on the module examples application now, 
but the application and the fixes aren't going to happen before Monday.

Of course, an equally reasonable opinion would be to hold the patch for after the 
1.2.0 roll, so that it can live in the nightly build for awhile. But it seems like a 
fairly straight-forward matter to me, and should either work or not.

-Ted.

On Fri, 02 Jan 2004 12:17:16 -1000 (HST), Don Brown wrote:
> Yeah, I wasn't sure what to call them either.  I think it would be
> nice to have one that will create the form from the config, no
> matter what type it is, but still have others that create the
> specific type.  This is mostly useful for testing as it makes it
> easy to create dynaforms, a feature I've been hearing a lot.  Of
> course, it could just be two methods, and if you just wanted a
> dynaform, create a FormBeanConfig and set dynamic to true.
>
> As for when, it doesn't matter.  I could easily put it in over the
> weekend, code and tests, but if we are trying to get 1.2 out the
> door, it can wait.
>
> Don
>
>
> On Fri, 2 Jan 2004, Martin Cooper wrote:
>
>
>> Off the top of my head (meaning I haven't thought through all of
>> the possible ramifications yet ;), I like this idea. I know that
>> when I added factories to Commons FileUpload, it took the ability
>> to customise things to a level that just isn't possible with
>> straight 'new' coding. I can see how the same would be true for
>> Actions as well.
>>
>> I'm not sure about the specific API you suggest. I assume by
>> "default" you mean the non-dyna flavour? Something about the API
>> doesn't "feel" right, but I'll try to give it some thought later
>> and see if I can come up with anything better.
>>
>> BTW, I assume you're proposing this as a post-1.2.0 change?
>>
>>
>> --
>> Martin Cooper



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] ActionFactory refactoring

[Joe Germuska]

At 10:44 AM -1000 1/2/04, Don Brown wrote:
What if we extracted the creation of Actions and ActionForms (including
DynaActionForms) into an ActionFactory, overridable by the user?
In general, I'm in favor.   I disagree with Vic's assertion, 
paraphrased "factories are too complicated; it's good enough to 
directly call the constructor" -- certainly that is appropriate for 
some classes, but by centralizing expertise for creating instances 
within a single class, you have a lot more flexibility to make an 
across-the-board change to what exactly which objects are created. 
(Something to which Martin alluded while I was composing this 
message.)

I won't elaborate too much at the risk of hijacking, but I wonder if 
we could also use this as an easy step towards an API whereby an 
Action could request an "output form" instance for pre-population. 
(That is, the form bean which would back an html:form block in the 
destination view, as opposed to the "input form" which  encapsulates 
the request parameters.)

This was one of the motivations for adding a view controller, which 
we talked about in the fall, and which  I looked at doing for a 
little bit.  A full-fledged view controller raised a lot of questions 
which made me inclined to wait for struts-chain, but a simple 
mechanism which boils down (for most users) to a method in Action or 
ActionMapping like "getOutputForm(String)" might be a nice 
compromise.  Personally, if I could easily get an output form in an 
Action, I could live a while longer without a separate class to 
encapsulate my view stuff.  The mechanism we use now is a horrible 
hack.

OK, I'm afraid I've already elaborated too much...  Back to the 
specifics, I'm a little uneasy about the method to explicitly get a 
DynaActionForm.  Otherwise, I think it's likely to be helpful, and 
likely to be a low-impact change.

Joe
--
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: [Proposal] ActionFactory refactoring

[Don Brown]

Yeah, I wasn't sure what to call them either.  I think it would be nice to
have one that will create the form from the config, no matter what type it
is, but still have others that create the specific type.  This is mostly
useful for testing as it makes it easy to create dynaforms, a feature I've
been hearing a lot.  Of course, it could just be two methods, and if you
just wanted a dynaform, create a FormBeanConfig and set dynamic to true.

As for when, it doesn't matter.  I could easily put it in over the
weekend, code and tests, but if we are trying to get 1.2 out the door, it
can wait.

Don

On Fri, 2 Jan 2004, Martin Cooper wrote:

> Off the top of my head (meaning I haven't thought through all of the
> possible ramifications yet ;), I like this idea. I know that when I added
> factories to Commons FileUpload, it took the ability to customise things
> to a level that just isn't possible with straight 'new' coding. I can see
> how the same would be true for Actions as well.
>
> I'm not sure about the specific API you suggest. I assume by "default" you
> mean the non-dyna flavour? Something about the API doesn't "feel" right,
> but I'll try to give it some thought later and see if I can come up with
> anything better.
>
> BTW, I assume you're proposing this as a post-1.2.0 change?
>
> --
> Martin Cooper
>
>
> On Fri, 2 Jan 2004, Don Brown wrote:
>
> > What if we extracted the creation of Actions and ActionForms (including
> > DynaActionForms) into an ActionFactory, overridable by the user?
> >
> > Here's the problem as I see it: there is no simple way for a user to plug
> > in their own code to manage the creation of actions and action
> > forms.  The actual creation is handled by static methods in
> > RequestUtils, obviously not overridable, leaving the only option to
> > extend RequestProcessor and duplicate a lot of logic.
> >
> > Why would you want to plug in your own ActionFactory?  My primary purpose
> > is to better integrate Inversion of Control (IoC), specifically Spring's
> > IoC, into Struts.  By letting Spring create Struts objects, Spring can
> > handle any dependencies and configuration they need.  Another use, as
> > stated in bug #23583
> > (http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
> > factory that creates ActionForms using JavaAssist at runtime.  Finally,
> > this factory would be an easy way for the user to create their own
> > DynaActionForms, particularly useful for unit testing.
> >
> > Impact: This would have no impact on current Struts applications as it is
> > an internal refactoring and default behavior would remain the same.
> > Extensions that include custom RequestProcessors or interfere with object
> > creation might be affected.
> >
> > Configuration: I'd recommend another attribute in the 
> > element in struts-config, possibily named "actionFactoryClass", pointing
> > to the new ActionFactory implementation to use.  If none specified, a
> > default factory which mimics current behavior would be used.
> >
> > This is my proposed interface:
> >
> > public interface ActionFactory {
> >
> > public Action createAction(ActionServlet servlet);
> >
> > public DynaActionForm createDynaActionForm(ActionServlet servlet,
> >FormBeanConfig config,
> >ActionConfig mapping);
> >
> > public ActionForm createDefaultActionForm(ActionServlet,
> >   FormBeanConfig config);
> >
> >
> > public ActionForm createActionForm(ActionServlet servlet,
> >FormBeanConfig config,
> >ActionConfig mapping);
> >
> > }
> >
> > Note createActionForm() creates either a DynaActionForm or ActionForm
> > depending on the config.
> >
> > Comments?  Obviously, I'd perform the refactorings if this feature was
> > agreed upon.  Future targets for factories could include config objects:
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=13638
> >
> > 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]

Re: [Proposal] ActionFactory refactoring

[Vic Cekvenich]

Don Brown wrote:
 It would take probably a few hours
to code so little effort is "wasted" when the struts-chain move takes
place.
I think that is the key at the end of the day. I think it be more 
effective the few hours be spent on integrating IoC into 
struts-chain but I do not need to remind anyone I am not a commiter, 
and even then each comiter can commit what they please, but I would 
rather see a design of IoC in CoR. If CoR already does digester, it 
can't be to far away from some level of alpha. I think it easier to work 
with a clean sheet of paper, but your preference, thanks for contributions.
Maybe if there is a way to create a commons-IoC-api of interfaces that 
could be implemented as Nano, Hivemind, etc.  and  I duno.

.V



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] ActionFactory refactoring

[Martin Cooper]

Off the top of my head (meaning I haven't thought through all of the
possible ramifications yet ;), I like this idea. I know that when I added
factories to Commons FileUpload, it took the ability to customise things
to a level that just isn't possible with straight 'new' coding. I can see
how the same would be true for Actions as well.

I'm not sure about the specific API you suggest. I assume by "default" you
mean the non-dyna flavour? Something about the API doesn't "feel" right,
but I'll try to give it some thought later and see if I can come up with
anything better.

BTW, I assume you're proposing this as a post-1.2.0 change?

--
Martin Cooper


On Fri, 2 Jan 2004, Don Brown wrote:

> What if we extracted the creation of Actions and ActionForms (including
> DynaActionForms) into an ActionFactory, overridable by the user?
>
> Here's the problem as I see it: there is no simple way for a user to plug
> in their own code to manage the creation of actions and action
> forms.  The actual creation is handled by static methods in
> RequestUtils, obviously not overridable, leaving the only option to
> extend RequestProcessor and duplicate a lot of logic.
>
> Why would you want to plug in your own ActionFactory?  My primary purpose
> is to better integrate Inversion of Control (IoC), specifically Spring's
> IoC, into Struts.  By letting Spring create Struts objects, Spring can
> handle any dependencies and configuration they need.  Another use, as
> stated in bug #23583
> (http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
> factory that creates ActionForms using JavaAssist at runtime.  Finally,
> this factory would be an easy way for the user to create their own
> DynaActionForms, particularly useful for unit testing.
>
> Impact: This would have no impact on current Struts applications as it is
> an internal refactoring and default behavior would remain the same.
> Extensions that include custom RequestProcessors or interfere with object
> creation might be affected.
>
> Configuration: I'd recommend another attribute in the 
> element in struts-config, possibily named "actionFactoryClass", pointing
> to the new ActionFactory implementation to use.  If none specified, a
> default factory which mimics current behavior would be used.
>
> This is my proposed interface:
>
> public interface ActionFactory {
>
>   public Action createAction(ActionServlet servlet);
>
>   public DynaActionForm createDynaActionForm(ActionServlet servlet,
>  FormBeanConfig config,
>  ActionConfig mapping);
>
>   public ActionForm createDefaultActionForm(ActionServlet,
> FormBeanConfig config);
>
>
> public ActionForm createActionForm(ActionServlet servlet,
>FormBeanConfig config,
>ActionConfig mapping);
>
> }
>
> Note createActionForm() creates either a DynaActionForm or ActionForm
> depending on the config.
>
> Comments?  Obviously, I'd perform the refactorings if this feature was
> agreed upon.  Future targets for factories could include config objects:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=13638
>
> 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]

Re: [Proposal] ActionFactory refactoring

[Don Brown]

On Fri, 2 Jan 2004, Vic Cekvenich wrote:

> So here are comments:
> - I like IoC idea!  I prefer Nano, Hivemind or something else Jakarta
> based. I have been using HiveMind on projects and it is very nice.

Exactly my point.  Abstracting object creating into a factory would allow
you to create a factory that uses HiveMind.  The IoC implementation
I mentioned wouldn't be a part of Struts, but rather for a Spring
plugin project I'm working on (http://struts.sf.net/struts-spring).

> - I do not like any kind of factory. It's harder to teach and maintain
> then just new(). Factory and pool had it's place in JDK 1.3, but a new()
> is not bad in 1.4. Besides we know the type of object is comming, so no
> reason for factory, it would just add complexity.

Perhaps we are speaking about different factories...  All a factory
pattern does is hide the object creation details, not necessarily object
pooling which I'm not suggesting at all.  This allows objects to be
created and therefore managed by custom code which could be an IoC impl or
a user's custom object factory.  Furthermore, it makes it easy to change
class implementation either through a different interface impl or
subclass.

Finally, very few Struts apps would use their own factory, as this is more
of an internal refactoring.  If anything, I think it would reduce
complexity as it cuts a section of code out of the huge RequestUtils.

> - I like what Struts chain does, it's simple and clever and it shows
> people how to create their own custom action that extend base action
> with the user base. That should be the starting point and improvments
> should be based on it, IMO. For example, calls from there to IoC. An IoC

Yes, with Struts chain, you would simply replace the command that creates
an action or action form, but still that duplicates logic.  A simple
factory only handles creation, not checking to see if one already exists
like in the case of form beans.

More importantly, Struts chain isn't used now.  RequestProcessor is.  This
refactoring is fairly simple, backwards-compatible, and imposes zero or
little changes the user would notice.  It would take probably a few hours
to code so little effort is "wasted" when the struts-chain move takes
place.

> DAO that populates a XMLFormBean Document. Digester could be called via
> IoC from CoR. I kind of think IoC is something users should do as calls
> from Strut's CoR. I do have a question if struts chain already reads
> digester or there is code someplace that does it or if I want to play
> with it I have to read mapping by myslef?

commons-chain contains ConfigParser, which uses the digester to build
chains from XML, however this is completely optional.  It is very easy to
build chains manually or from some other config source like a database.
The Struts-chain uses the ConfigParser to load its configuration.

Don

>
> .V
>
>
> ps: 2.0 wish: Call a use case implemnetation a "bundle", same as other
> light weight service implementation.
>
> Don Brown wrote:
> > What if we extracted the creation of Actions and ActionForms (including
> > DynaActionForms) into an ActionFactory, overridable by the user?
> >
> > Here's the problem as I see it: there is no simple way for a user to plug
> > in their own code to manage the creation of actions and action
> > forms.  The actual creation is handled by static methods in
> > RequestUtils, obviously not overridable, leaving the only option to
> > extend RequestProcessor and duplicate a lot of logic.
> >
> > Why would you want to plug in your own ActionFactory?  My primary purpose
> > is to better integrate Inversion of Control (IoC), specifically Spring's
> > IoC, into Struts.  By letting Spring create Struts objects, Spring can
> > handle any dependencies and configuration they need.  Another use, as
> > stated in bug #23583
> > (http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
> > factory that creates ActionForms using JavaAssist at runtime.  Finally,
> > this factory would be an easy way for the user to create their own
> > DynaActionForms, particularly useful for unit testing.
> >
> > Impact: This would have no impact on current Struts applications as it is
> > an internal refactoring and default behavior would remain the same.
> > Extensions that include custom RequestProcessors or interfere with object
> > creation might be affected.
> >
> > Configuration: I'd recommend another attribute in the 
> > element in struts-config, possibily named "actionFactoryClass", pointing
> > to the new ActionFactory implementation to use.  If none specified, a
> > default factory which mimics current behavior would be used.
> >
> > This is my proposed interface:
> >
> > public interface ActionFactory {
> >
> > public Action createAction(ActionServlet servlet);
> >
> > public DynaActionForm createDynaActionForm(ActionServlet servlet,
> >FormBeanConfig config,
> > 

DO NOT REPLY [Bug 21992] - Localized number formatting inconsistency

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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





--- Additional Comments From [EMAIL PROTECTED]  2004-01-02 21:44 ---
IMHO, this functionality is correct and appropriate as it is. If the format 
pattern is in a resource file, then it *should* be the localised pattern. If 
you sent off your resource files to an external translator, as many (most?) 
companies do, you don't want to have to point out which entries are supposed to 
be format patterns and therefore not translated. You want them to translate 
everything in the resource file. So format patterns will be translated, and 
therefore no longer contain placeholders, but "real" values.

By the way, it is important to note that, when you specify the format pattern 
in the JSP page itself, you are *not* specifying the "English" format, as 
Emmanuel suggests. These are *placeholder* values. You can think of the 
substitution, in the US case, as being effectively a no-op, because the "real" 
values happen to be the same as the localised values, but *it is still a 
translation* from placeholders to real values.

The documentation of the placeholders is in the Javadoc for DecimalFormat, 
although it isn't very clear about the placeholder versus real value issue.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Proposal] ActionFactory refactoring

[Vic Cekvenich]

So here are comments:
- I like IoC idea!  I prefer Nano, Hivemind or something else Jakarta 
based. I have been using HiveMind on projects and it is very nice.
- I do not like any kind of factory. It's harder to teach and maintain 
then just new(). Factory and pool had it's place in JDK 1.3, but a new() 
is not bad in 1.4. Besides we know the type of object is comming, so no 
reason for factory, it would just add complexity.
- I like what Struts chain does, it's simple and clever and it shows 
people how to create their own custom action that extend base action 
with the user base. That should be the starting point and improvments 
should be based on it, IMO. For example, calls from there to IoC. An IoC 
DAO that populates a XMLFormBean Document. Digester could be called via 
IoC from CoR. I kind of think IoC is something users should do as calls 
from Strut's CoR. I do have a question if struts chain already reads 
digester or there is code someplace that does it or if I want to play 
with it I have to read mapping by myslef?

.V

ps: 2.0 wish: Call a use case implemnetation a "bundle", same as other 
light weight service implementation.

Don Brown wrote:
What if we extracted the creation of Actions and ActionForms (including
DynaActionForms) into an ActionFactory, overridable by the user?
Here's the problem as I see it: there is no simple way for a user to plug
in their own code to manage the creation of actions and action
forms.  The actual creation is handled by static methods in
RequestUtils, obviously not overridable, leaving the only option to
extend RequestProcessor and duplicate a lot of logic.
Why would you want to plug in your own ActionFactory?  My primary purpose
is to better integrate Inversion of Control (IoC), specifically Spring's
IoC, into Struts.  By letting Spring create Struts objects, Spring can
handle any dependencies and configuration they need.  Another use, as
stated in bug #23583
(http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
factory that creates ActionForms using JavaAssist at runtime.  Finally,
this factory would be an easy way for the user to create their own
DynaActionForms, particularly useful for unit testing.
Impact: This would have no impact on current Struts applications as it is
an internal refactoring and default behavior would remain the same.
Extensions that include custom RequestProcessors or interfere with object
creation might be affected.
Configuration: I'd recommend another attribute in the 
element in struts-config, possibily named "actionFactoryClass", pointing
to the new ActionFactory implementation to use.  If none specified, a
default factory which mimics current behavior would be used.
This is my proposed interface:

public interface ActionFactory {

	public Action createAction(ActionServlet servlet);

public DynaActionForm createDynaActionForm(ActionServlet servlet,
   FormBeanConfig config,
   ActionConfig mapping);
public ActionForm createDefaultActionForm(ActionServlet,
  FormBeanConfig config);
public ActionForm createActionForm(ActionServlet servlet,
   FormBeanConfig config,
   ActionConfig mapping);
}

Note createActionForm() creates either a DynaActionForm or ActionForm
depending on the config.
Comments?  Obviously, I'd perform the refactorings if this feature was
agreed upon.  Future targets for factories could include config objects:
http://issues.apache.org/bugzilla/show_bug.cgi?id=13638
Don


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21992] - Localized number formatting inconsistency

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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





--- Additional Comments From [EMAIL PROTECTED]  2004-01-02 21:13 ---
I'm really not sure which way we should go with this. The idea behind a resource
bundle is that it's suppose to contain localized resources. So, using the
localized notation does seem appropriate. On the other hand, I can see why using
the localized notation would be inconvenient. 

If we were to include a switch, we'd need to be careful of any performance
implications involved since the bean:write tag, when used, is often used. Right
now, virtuall all the switches are in the controller object. bean:write also
seems to be looking for a default format in the resource files for the date
fields. (Though, that might not be the best approach.)

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Proposal] ActionFactory refactoring

[Don Brown]

What if we extracted the creation of Actions and ActionForms (including
DynaActionForms) into an ActionFactory, overridable by the user?

Here's the problem as I see it: there is no simple way for a user to plug
in their own code to manage the creation of actions and action
forms.  The actual creation is handled by static methods in
RequestUtils, obviously not overridable, leaving the only option to
extend RequestProcessor and duplicate a lot of logic.

Why would you want to plug in your own ActionFactory?  My primary purpose
is to better integrate Inversion of Control (IoC), specifically Spring's
IoC, into Struts.  By letting Spring create Struts objects, Spring can
handle any dependencies and configuration they need.  Another use, as
stated in bug #23583
(http://issues.apache.org/bugzilla/show_bug.cgi?id=23583), could be a
factory that creates ActionForms using JavaAssist at runtime.  Finally,
this factory would be an easy way for the user to create their own
DynaActionForms, particularly useful for unit testing.

Impact: This would have no impact on current Struts applications as it is
an internal refactoring and default behavior would remain the same.
Extensions that include custom RequestProcessors or interfere with object
creation might be affected.

Configuration: I'd recommend another attribute in the 
element in struts-config, possibily named "actionFactoryClass", pointing
to the new ActionFactory implementation to use.  If none specified, a
default factory which mimics current behavior would be used.

This is my proposed interface:

public interface ActionFactory {

public Action createAction(ActionServlet servlet);

public DynaActionForm createDynaActionForm(ActionServlet servlet,
   FormBeanConfig config,
   ActionConfig mapping);

public ActionForm createDefaultActionForm(ActionServlet,
  FormBeanConfig config);


public ActionForm createActionForm(ActionServlet servlet,
   FormBeanConfig config,
   ActionConfig mapping);

}

Note createActionForm() creates either a DynaActionForm or ActionForm
depending on the config.

Comments?  Obviously, I'd perform the refactorings if this feature was
agreed upon.  Future targets for factories could include config objects:
http://issues.apache.org/bugzilla/show_bug.cgi?id=13638

Don


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Unable to compile the source.

[Anand Stephen]

Thanks!
My build properties was pointing to the wrong jar.
thanks again,
-a



- Original Message - 
From: "Martin Cooper" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Thursday, January 01, 2004 11:24 PM
Subject: Re: Unable to compile the source.


> It looks to me like there's a problem with whatever JSP jar you're
> compiling against, given the complaints about JspException not being
> public. You might want to pick up a servlet/jsp jar from Tomcat or
> elsewhere and compile against that. (On the other hand, if you're
> compiling against your container now, you may have problems even after
> Struts compiles successfully.)
>
> --
> Martin Cooper
>
>
> On Thu, 1 Jan 2004, Anand Stephen wrote:
>
> > Greetings,
> > Wish you all a very happy new year!
> >
> > I am trying to compile the latest source of struts I have attached the
error log.
> >
> > Any help would be appreciated,
> >
> > -anand
> >
> >
> >
> >
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.557 / Virus Database: 349 - Release Date: 12/30/2003
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.557 / Virus Database: 349 - Release Date: 12/30/2003


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: pagePattern

[Ted Husted]

On Fri, 02 Jan 2004 06:49:42 -0800 (PST), David Graham wrote:
> We should discuss LocaleAction in its own thread.  I'm not
> necessarily opposed to putting it in the standard actions package
> but I'd like to have an explanation, use cases and design review
> before we add it.

We can just dodge that bullet for now. We can move it in a "shared" or "toolkit" 
package for the combined examples application for this release, improve it there, and 
decide later.

I did some initial work on the combined examples application, and it looks quite good.

This would replace taglib-exercise, validator, and upload. Leaving blank, mailreader, 
and tiles-documentation as separate applications. So, we'd go from six bundled 
applications to four. Some progress, at least :)

 -Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Example of UML Diagram

[Ted Husted]

This is really a question better suited for the USER list, where there are more people 
to help you. Any UML we had here, would already be part of the distribution :)

Though, the problem is that Struts doesn't do the saving. It just collects the date 
you would need to do the save, and then hands off to a business class. You don't 
"save" in Struts, you just collect data.

-Ted.


On Fri, 02 Jan 2004 13:57:37 +, Kamal Gupta wrote:
> Hi,
>
>
> I am looking for some sequence diagram which displays a save action
> using struts.
>
> Any examples
>
>
> Regards
>
>
> Kamal Gupta
> - Original Message -
> From: "David Graham" <[EMAIL PROTECTED]>
> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent:
> Friday, January 02, 2004 1:36 PM Subject: Re: pagePattern
>
>>
>> --- Ted Husted <[EMAIL PROTECTED]> wrote:
>>> I was setting up a working test for pagePattern in an
>>> application that doesn't use module (the Mailreader Example).
>>> It doesn't seem to recognize a pattern like "/pages$M$P" where
>>> it the same application it does recognize a forwardPattern like
>>> "/do$M$P".
>>>
>>> I think I see where the problem might be, but I really need a
>>> baseline modules application to proceed.
>>>
>>> We broke the "register" portion of MailReader out to
>>> demonstrate multiple configs and then wildcard actions. I'm
>>> thinking we (meaning I) should finish the job and make the
>>> "register" portion a separate module. Thoughts?  Objections?
>>> Alternatives?
>>>
>>
>> This has been a problem with modules all along.  I don't use them
>> because nobody seems to be actively supporting this feature aside
>> from the occasional bugfix.  IMO, the current implementation
>> isn't coherent enough to prevent new bugs popping up (you have to
>> look all over the code base to see if you've broken modules).
>>
>> I think it's a great idea to add some examples to test against.
>>
>>
>> David
>>
>>>
>>> -Ted.
>>
>>
>> __
>> Do you Yahoo!?
>> Free Pop-Up Blocker - Get it now
>> http://companion.yahoo.com/
>>
>>
>> --
>> --- To unsubscribe, e-mail: struts-dev-
>> [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]

DO NOT REPLY [Bug 21992] - Localized number formatting inconsistency

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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

 Status|RESOLVED|REOPENED
  Component|Documentation   |Custom Tags
   Priority|High|Medium
 Resolution|FIXED   |



--- Additional Comments From [EMAIL PROTECTED]  2004-01-02 15:55 ---
Thank you for documenting the issue Ted. You mentioned a boolean switch to
preserve backward-compatibility with existing formats, I'm willing to contribute
it if you accept the idea. Maybe the default behaviour could be later changed in
Struts 2.0.

What would be the best approach for implementing this switch ? A system
property, an application context parameter or a parameter in the struts-config
file ?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 21992] - Localized number formatting inconsistency

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-01-02 14:51 ---
The WriteTag Javadocs have been extended to include details on using localized
notations in resource bundles.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: pagePattern

[David Graham]

--- Ted Husted <[EMAIL PROTECTED]> wrote:
> Hey, here's an alternative:
> 
> How about combining the exercise-taglib, validator, and upload
> applications in to single application three modules?
> 
> That way we can avoid unnecessary complications to the MailReader,
> eliminate two redundant sets of JARs, share the LocaleAction without
> making it a standard Action, and have a shared module example to tinker
> with.

+1
While it is nice to have logically separate apps, the benefits of
combining them are compelling.  The combined app should probably have a
start page with links to the 3 different modules for clarity.

> 
> I still think we need a stock LocaleAction, but that could also be made
> part of a separate distribution with some other goodies that many people
> find helpful but might not be suitable for the actions package.

We should discuss LocaleAction in its own thread.  I'm not necessarily
opposed to putting it in the standard actions package but I'd like to have
an explanation, use cases and design review before we add it.

David

> 
> Since I want to address the pagePattern and other module reports for
> 1.2.0, and need a test-bed, I'm going to have a go at combining the
> aforementioned gang of three.
> 
> -Ted.
> 
> On Fri, 02 Jan 2004 07:18:19 -0500, Ted Husted wrote:
> > I was setting up a working test for pagePattern in an application
> > that doesn't use module (the Mailreader Example). It doesn't seem
> > to recognize a pattern like "/pages$M$P" where it the same
> > application it does recognize a forwardPattern like "/do$M$P".
> >
> > I think I see where the problem might be, but I really need a
> > baseline modules application to proceed.
> >
> > We broke the "register" portion of MailReader out to demonstrate
> > multiple configs and then wildcard actions. I'm thinking we
> > (meaning I) should finish the job and make the "register" portion a
> > separate module. Thoughts?  Objections? Alternatives?
> >
> > -Ted.
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


__
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: Unable to compile the source.

[Venkata Aleti]

can you tell me which server you are using,  make sure u added required jar
files into your lib folder.
-venkat

-Original Message-
From: Anand Stephen [mailto:[EMAIL PROTECTED] 
Sent: Friday, January 02, 2004 1:59 AM
To: [EMAIL PROTECTED]
Subject: Unable to compile the source.


Greetings,
Wish you all a very happy new year!
 
I am trying to compile the latest source of struts I have attached the error
log.
 
Any help would be appreciated,
 
-anand
 
 
 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com
 ).
Version: 6.0.557 / Virus Database: 349 - Release Date: 12/30/2003




This electronic message contains information from CTIS, Inc., which 
may be company sensitive, proprietary, privileged or otherwise protected 
from disclosure. The information is intended to be used solely by the 
recipients named above. If you are not an intended recipient, be aware 
that any review, disclosure, copying, distribution or use of this 
transmission or its contents is prohibited.  If you have received this 
transmission in error, please notify us immediately at [EMAIL PROTECTED] 

Example of UML Diagram

[Kamal Gupta]

Hi,

I am looking for some sequence diagram which displays a save action using
struts.

Any examples

Regards

Kamal Gupta
- Original Message -
From: "David Graham" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>
Sent: Friday, January 02, 2004 1:36 PM
Subject: Re: pagePattern


>
> --- Ted Husted <[EMAIL PROTECTED]> wrote:
> > I was setting up a working test for pagePattern in an application that
> > doesn't use module (the Mailreader Example). It doesn't seem to
> > recognize a pattern like "/pages$M$P" where it the same application it
> > does recognize a forwardPattern like "/do$M$P".
> >
> > I think I see where the problem might be, but I really need a baseline
> > modules application to proceed.
> >
> > We broke the "register" portion of MailReader out to demonstrate
> > multiple configs and then wildcard actions. I'm thinking we (meaning I)
> > should finish the job and make the "register" portion a separate module.
> > Thoughts?  Objections? Alternatives?
>
> This has been a problem with modules all along.  I don't use them because
> nobody seems to be actively supporting this feature aside from the
> occasional bugfix.  IMO, the current implementation isn't coherent enough
> to prevent new bugs popping up (you have to look all over the code base to
> see if you've broken modules).
>
> I think it's a great idea to add some examples to test against.
>
> David
>
> >
> > -Ted.
> >
>
>
> __
> 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: pagePattern

[Ted Husted]

Hey, here's an alternative:

How about combining the exercise-taglib, validator, and upload applications in to 
single application three modules?

That way we can avoid unnecessary complications to the MailReader, eliminate two 
redundant sets of JARs, share the LocaleAction without making it a standard Action, 
and have a shared module example to tinker with.

I still think we need a stock LocaleAction, but that could also be made part of a 
separate distribution with some other goodies that many people find helpful but might 
not be suitable for the actions package.

Since I want to address the pagePattern and other module reports for 1.2.0, and need a 
test-bed, I'm going to have a go at combining the aforementioned gang of three.

-Ted.

On Fri, 02 Jan 2004 07:18:19 -0500, Ted Husted wrote:
> I was setting up a working test for pagePattern in an application
> that doesn't use module (the Mailreader Example). It doesn't seem
> to recognize a pattern like "/pages$M$P" where it the same
> application it does recognize a forwardPattern like "/do$M$P".
>
> I think I see where the problem might be, but I really need a
> baseline modules application to proceed.
>
> We broke the "register" portion of MailReader out to demonstrate
> multiple configs and then wildcard actions. I'm thinking we
> (meaning I) should finish the job and make the "register" portion a
> separate module. Thoughts?  Objections? Alternatives?
>
> -Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: pagePattern

[David Graham]

--- Ted Husted <[EMAIL PROTECTED]> wrote:
> I was setting up a working test for pagePattern in an application that
> doesn't use module (the Mailreader Example). It doesn't seem to
> recognize a pattern like "/pages$M$P" where it the same application it
> does recognize a forwardPattern like "/do$M$P".
> 
> I think I see where the problem might be, but I really need a baseline
> modules application to proceed.
> 
> We broke the "register" portion of MailReader out to demonstrate
> multiple configs and then wildcard actions. I'm thinking we (meaning I)
> should finish the job and make the "register" portion a separate module.
> Thoughts?  Objections? Alternatives?

This has been a problem with modules all along.  I don't use them because
nobody seems to be actively supporting this feature aside from the
occasional bugfix.  IMO, the current implementation isn't coherent enough
to prevent new bugs popping up (you have to look all over the code base to
see if you've broken modules).  

I think it's a great idea to add some examples to test against.

David

> 
> -Ted.
> 


__
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: Renaming DefinitionsFactory or DefinitionsFactory?

[Ted Husted]

We probably wouldn't be able to rename it per se. We'd have to deprecate one class and 
bring another up using the new name. (The one we deprecating being a shell that calls 
the new one.) Tyranny of the installed base, and all that :)

A lot of the naming in the Tiles package is inconsistence and does need to be 
addressed. One reason for this was that Tiles had a name change late in the cycle, so 
sometimes the older name is used.

What would be helpful would be a proposal that presented an new API with al the 
changes, as well as what bridge classes would be needed to get there from here.

-Ted.

On Fri, 02 Jan 2004 07:25:16 -0500, [EMAIL PROTECTED] wrote:
>
> Hi all, I was recently poking around in the source and API docs for
> some of the Tiles classes, and noticed there is an interface
> org.apache.struts.tiles.DefinitionsFactory, and a concrete class
> org.apache.struts.tiles.xmlDefinition.DefinitionsFactory.  Now,
> this isn't a problem in any objective sense, and granted, they are
> in different packages...
>
> But, to a developer new to the Tiles source, it makes things just a
> tad bit confusing.  Actually, a lot of the naming conventions in
> Tiles are confusing to me, and maybe I'll throw some other
> suggestions out later.. but for now, I wonder if there's any
> possibility of  renaming one of the DefinitionsFactory types?
>
> I'm afraid I'm not familiar enough with the code (yet) to have a
> full understanding of what all the ramifications of this would be,
> and maybe it's a dumb idea... but I thought I'd mention it and see
> what the experienced Struts / Tiles folks had to say.
>
>
> Thanks,
>
>
> Phillip Rhodes
> Application Designer
> Voice Data Solutions
> 919-571-4300 x225
> [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Renaming DefinitionsFactory or DefinitionsFactory?

[prhodes]

Hi all, I was recently poking around in the source and API docs for
some of the Tiles classes, and noticed there is an interface
org.apache.struts.tiles.DefinitionsFactory, and a concrete class
org.apache.struts.tiles.xmlDefinition.DefinitionsFactory.  Now, this
isn't a problem in any objective sense, and granted, they
are in different packages...

But, to a developer new to the Tiles source, it makes things just a tad
bit confusing.  Actually, a lot of the naming conventions in Tiles
are confusing to me, and maybe I'll throw some other suggestions
out later.. but for now, I wonder if there's any possibility of  renaming
one of the DefinitionsFactory types?

I'm afraid I'm not familiar enough with the code (yet) to have a full
understanding of what all the ramifications of this would be, and maybe
it's a dumb idea... but I thought I'd mention it and see what the
experienced Struts / Tiles folks had to say.


Thanks,

Phillip Rhodes
Application Designer
Voice Data Solutions
919-571-4300 x225
[EMAIL PROTECTED]

Those who are willing to sacrifice essential liberties for a little order,
will
lose both and deserve neither. - Benjamin Franklin

This country, with its institutions, belongs to the people who inhabit it.

Whenever they shall grow weary of the existing government, they can
exercise
their constitutional right of amending it, or exercise their revolutionary
right to overthrow it.  - Abraham Lincoln

No citizen shall be denied the right to bear arms, if as a last resort, to
protect themselves from tyranny in Government. - Thomas Jefferson


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

pagePattern

[Ted Husted]

I was setting up a working test for pagePattern in an application that doesn't use 
module (the Mailreader Example). It doesn't seem to recognize a pattern like 
"/pages$M$P" where it the same application it does recognize a forwardPattern like 
"/do$M$P".

I think I see where the problem might be, but I really need a baseline modules 
application to proceed.

We broke the "register" portion of MailReader out to demonstrate multiple configs and 
then wildcard actions. I'm thinking we (meaning I) should finish the job and make the 
"register" portion a separate module. Thoughts?  Objections? Alternatives?

-Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re[2]: Unable to compile the source.

[Foux]

Hello Ted,

Friday, January 2, 2004, 12:47:51 PM, you wrote:

TH> 
TH> Another shortcut would be to install Maven (maven.apache.org)
TH> and use the new Maven setup. It's still under development, but it
TH> do work. :)

TH> HTH, Ted.

Well, I tried it some days ago (and retried it just now), but the
maven building script is still stoping when trying to acquire the
commons-validator-1.1.1-dev.jar dependency.

Foux.





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25861] New: - LocaleAction not ready for prime time

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=25861

LocaleAction not ready for prime time

   Summary: LocaleAction not ready for prime time
   Product: Struts
   Version: Nightly Build
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Standard Actions
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The action is an ok example but it's not generally useful enough to
warrant promotion to the main Struts distro More importantly, the
code isn't ready for the main distro as it catches Exception and
hardcodes the "success" forward name. [David Graham]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/nested NestedPropertyTag.java

[husted]

husted  2004/01/02 03:55:39

  Modified:doc/faqs index.xml
   doc/userGuide dev_validator.xml struts-html.xml
struts-logic.xml
   src/share/org/apache/struts/taglib/bean WriteTag.java
   src/share/org/apache/struts/taglib/nested
NestedPropertyTag.java
  Log:
  Expand tinyurls.
  
  Revision  ChangesPath
  1.15  +1 -1  jakarta-struts/doc/faqs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/faqs/index.xml,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- index.xml 11 Sep 2003 21:31:24 -  1.14
  +++ index.xml 2 Jan 2004 11:55:38 -   1.15
  @@ -109,7 +109,7 @@
   
   
  
  -   http://tinyurl.com/6jnv";>Struts Validator: Validating Two Fields 
Match by Matt Raible
  +   http://www.raibledesigns.com/page/rd/20030226#struts_validator_validating_two_fields";>Struts
 Validator: Validating Two Fields Match by Matt Raible
  
   
   
  
  
  
  1.40  +1 -1  jakarta-struts/doc/userGuide/dev_validator.xml
  
  Index: dev_validator.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/dev_validator.xml,v
  retrieving revision 1.39
  retrieving revision 1.40
  diff -u -r1.39 -r1.40
  --- dev_validator.xml 1 Jan 2004 16:46:28 -   1.39
  +++ dev_validator.xml 2 Jan 2004 11:55:38 -   1.40
  @@ -786,7 +786,7 @@
   
   
   
  -http://tinyurl.com/6jnv";>
  +http://www.raibledesigns.com/page/rd/20030226#struts_validator_validating_two_fields";>
   Struts Validator: Validating Two Fields Match by Matt 
Raible.
   Howto article.
   
  
  
  
  1.67  +36 -0 jakarta-struts/doc/userGuide/struts-html.xml
  
  Index: struts-html.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-html.xml,v
  retrieving revision 1.66
  retrieving revision 1.67
  diff -u -r1.66 -r1.67
  --- struts-html.xml   13 Dec 2003 21:14:01 -  1.66
  +++ struts-html.xml   2 Jan 2004 11:55:38 -   1.67
  @@ -3139,6 +3139,18 @@
 
   
   
  +
  +  useLocalEncoding
  +  false
  +  true
  +  
  +  If set to true, LocalCharacterEncoding will be
  +  used, that is, the characterEncoding set to the HttpServletResponse,
  +  as prefered character encoding rather than UTF-8, when
  +  URLEncoding is done on parameters of the URL.
  +  
  +
  +
   
 usemap
 false
  @@ -3826,6 +3838,18 @@
 
   
   
  +
  +  useLocalEncoding
  +  false
  +  true
  +  
  +  If set to true, LocalCharacterEncoding will be
  +  used, that is, the characterEncoding set to the HttpServletResponse,
  +  as prefered character encoding rather than UTF-8, when
  +  URLEncoding is done on parameters of the URL.
  +  
  +
  +
   
   
   
  @@ -5733,6 +5757,18 @@
 in the receiving Action.
 
   
  +
  +
  +  useLocalEncoding
  +  false
  +  true
  +  
  +  If set to true, LocalCharacterEncoding will be
  +  used, that is, the characterEncoding set to the HttpServletResponse,
  +  as prefered character encoding rather than UTF-8, when
  +  URLEncoding is done on parameters of the URL.
  +  
  +
   
   
   
  
  
  
  1.17  +12 -0 jakarta-struts/doc/userGuide/struts-logic.xml
  
  Index: struts-logic.xml
  ===
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-logic.xml,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- struts-logic.xml  17 Sep 2003 18:54:25 -  1.16
  +++ struts-logic.xml  2 Jan 2004 11:55:38 -   1.17
  @@ -1732,6 +1732,18 @@
 
   
   
  +
  +  useLocalEncoding
  +  false
  +  true
  +  
  +  If set to true, LocalCharacterEncoding will be
  +  used, that is, the characterEncoding set to the HttpServletResponse,
  +  as prefered character encoding rather than UTF-8, when
  +  URLEncoding is done on parameters of the URL.
  +  
  +
  +
   
   
   
  
  
  
  1.32  +11 -10
jakarta-struts/src/share/org/apache/struts/taglib/be

cvs commit: jakarta-struts/web/validator index.jsp type.jsp

[husted]

husted  2004/01/02 03:55:06

  Modified:web/example/WEB-INF struts-config.xml
   web/validator index.jsp type.jsp
  Log:
  Add "useLocalEncoding" attribute to link to demonstrate use.
  
  Revision  ChangesPath
  1.35  +6 -5  jakarta-struts/web/example/WEB-INF/struts-config.xml
  
  Index: struts-config.xml
  ===
  RCS file: /home/cvs/jakarta-struts/web/example/WEB-INF/struts-config.xml,v
  retrieving revision 1.34
  retrieving revision 1.35
  diff -u -r1.34 -r1.35
  --- struts-config.xml 21 Dec 2003 22:43:52 -  1.34
  +++ struts-config.xml 2 Jan 2004 11:55:06 -   1.35
  @@ -46,7 +46,8 @@
   
 
 
  + type="org.apache.struts.actions.ForwardAction"
  + parameter="/welcome.jsp"/>
   
 
 
   
  -  
  -
  +
  -
  -  
   
   
 
  
  
  
  1.6   +1 -1  jakarta-struts/web/validator/index.jsp
  
  Index: index.jsp
  ===
  RCS file: /home/cvs/jakarta-struts/web/validator/index.jsp,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- index.jsp 21 Dec 2003 22:49:11 -  1.5
  +++ index.jsp 2 Jan 2004 11:55:06 -   1.6
  @@ -66,7 +66,7 @@
 
  
  
  -  Japanese | Japonais -
  +  Japanese | 
Japonais -
 
  
   
  
  
  
  1.6   +0 -1  jakarta-struts/web/validator/type.jsp
  
  Index: type.jsp
  ===
  RCS file: /home/cvs/jakarta-struts/web/validator/type.jsp,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- type.jsp  24 Sep 2003 03:43:17 -  1.5
  +++ type.jsp  2 Jan 2004 11:55:06 -   1.6
  @@ -145,7 +145,6 @@
  
   

  -

  

  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Unable to compile the source.

[Ted Husted]

On Thu, 01 Jan 2004 22:59:03 -0800, Anand Stephen wrote:
> Greetings,
> Wish you all a very happy new year!
>
> I am trying to compile the latest source of struts I have attached
> the error log.   Any help would be appreciated,   -anand
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.557 / Virus Database: 349 - Release Date: 12/30/2003

To build Struts with Ant, you need to create a build.properties file based on the 
build.properties.sample in CVS, and acquire all the dependencies it mentions.

The dependency your message complains about is a missing servlet.jar. As mentioned, 
this are shipped with your container (e.g. Tomcat). Tomcat 4 ships it in 
$TOMCAT\common\lib.

One short cut is to getting started is to use the JARS  in the lib folder from Struts 
1.1 and add the new JARs from there.

Another shortcut would be to install Maven (maven.apache.org) and use the new Maven 
setup. It's still under development, but it do work. :)

HTH, Ted.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22594] - change html:submit

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22594

change html:submit

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2004-01-02 11:34 ---
If the multiple submit buttons are leading to a DispatchAction that need to
different settings for validation, you can now use the MappingDispatchAction
instead.

Alternively, if the submit buttons are forwarding to another action, as Marcus
notes, the initial "gateway" action can have validate=false, and then other
actions can use validate=true, as appropriate.

-Ted.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25860] - html:cancel alteration to allow for default enter key form submission

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=25860

html:cancel alteration to allow for default enter key form submission

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement
   Keywords||PatchAvailable
   Priority|Other   |High



--- Additional Comments From [EMAIL PROTECTED]  2004-01-02 11:29 ---
We generate the TLDs from .xml files in the doc/userGuide folder. We apply
different stylesheets to generate the .TLD and API documents. Requiring
JavaScript would be a sticky wicket. We can use scripts optinally, as the
html:form tag does, but it can't be a requirement of the base functionality.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25860] - html:cancel alteration to allow for default enter key form submission

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=25860

html:cancel alteration to allow for default enter key form submission





--- Additional Comments From [EMAIL PROTECTED]  2004-01-02 10:11 ---
I've added another set of changes to the CancelTag.java file to accomodate jsp pages 
with already 
existing onclick events.  Now, the required javascript is appended to the current 
onclick event... 
this makes it possible to seamlessly move from the html submit button version to the 
javascript 
version w/o any jsp changes.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25860] - html:cancel alteration to allow for default enter key form submission

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=25860

html:cancel alteration to allow for default enter key form submission





--- Additional Comments From [EMAIL PROTECTED]  2004-01-02 10:09 ---
Created an attachment (id=9770)
Better patch to CVS * includes more changes

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25860] - html:cancel alteration to allow for default enter key form submission

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=25860

html:cancel alteration to allow for default enter key form submission





--- Additional Comments From [EMAIL PROTECTED]  2004-01-02 08:46 ---
Also, if this patch is rejected for requiring javascript (possible), this could
be used for a flag for the html:cancel tag such as 'javascript="true"' to use
this method or the original.

I just didn't want to mess with the TLD...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25860] - html:cancel alteration to allow for default enter key form submission

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=25860

html:cancel alteration to allow for default enter key form submission





--- Additional Comments From [EMAIL PROTECTED]  2004-01-02 08:45 ---
Created an attachment (id=9769)
CancelTag patch for javascript action

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 25860] New: - html:cancel alteration to allow for default enter key form submission

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=25860

html:cancel alteration to allow for default enter key form submission

   Summary: html:cancel alteration to allow for default enter key
form submission
   Product: Struts
   Version: 1.1 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Custom Tags
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If you use the html taglib to create the submit and cancel tags, you have to be
careful of the order, as if you are in a form and you hit the enter key, the
form will be submitted or cancelled based upon the last submit/cancel tag used.

Meaning if the order is like this:

(Submit) (Cancel)

the form will be cancelled

if the order is:

(Cancel) (Submit)

the form will be submitted.

For pure aesthetic reasons, I prefer to put the cancel button last (also, that
is how most of my users like it), but I also like to hit the enter key to submit
forms... 

I've written the following patch to org.apache.struts.taglib.html.CancelTag to
rewrite the cancel submit button to be a combination of a "button" and a hidden
form field.

This requires NO CHANGE to current jsp pages.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22594] - change html:submit

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=22594

change html:submit





--- Additional Comments From [EMAIL PROTECTED]  2004-01-02 08:37 ---
I don't know if this is still an issue or not for you, but there is no need to
change the html:submit struture to accomodate this request.

in the html:submit, you can assign an onclick event.  If you make the onclick
event "bCancel=true", no Javascript validation will be performed.  

Additionally, if you want to disable all validation, in the struts-config.xml
file, you can set the attribute 'validate="false"' and this will disable all
validation.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Unable to compile the source.

[Martin Cooper]

It looks to me like there's a problem with whatever JSP jar you're
compiling against, given the complaints about JspException not being
public. You might want to pick up a servlet/jsp jar from Tomcat or
elsewhere and compile against that. (On the other hand, if you're
compiling against your container now, you may have problems even after
Struts compiles successfully.)

--
Martin Cooper


On Thu, 1 Jan 2004, Anand Stephen wrote:

> Greetings,
> Wish you all a very happy new year!
>
> I am trying to compile the latest source of struts I have attached the error log.
>
> Any help would be appreciated,
>
> -anand
>
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.557 / Virus Database: 349 - Release Date: 12/30/2003

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tinyurl.com [was: Re: cvs commit: jakarta-stru...]

[Martin Cooper]

On Thu, 1 Jan 2004, James Mitchell wrote:

>
> Maybe its just me or I'm missing something here, but do we have to use
> tinyurl.com?  I'm not sure I like the idea of relying on a 3rd party for
> web resource address translation.
>
> If continue using this service and something happened and tinyurl.com was
> not available, we would lose many valuable references such as the
> one below.
>
> Perhaps we could utilize some other means of shortening long URLs, or at
> least something we have more control over.
>
>
> Your thoughts?

I agree. I've been seeing a lot of these tinyurl links in mail messages
recently (mostly from Ted, I think ;) and thinking about what we could do
to remove the need for them. (They're very handy, there's no doubt about
that.)

In addition to what you mention above, one other thing that bothers me
about them is that you have no indication of where you're going when you
follow one. It could be on the Apache site, but it could be anywhere, and
you don't know until you get there.

So, I'm thinking about proposing to the infrastructure folks that we run a
tinyurl work-alike at Apache. There are quite a lot of these around now -
see http://notlong.com/links/ - but I don't know if any of them are open
source. If not, I might have to write one, but it shouldn't be that hard.

Comments?

--
Martin Cooper


>
>
>
> On Thu, 1 Jan 2004 [EMAIL PROTECTED] wrote:
>
> > husted  2004/01/01 14:39:59
> >
> >   Modified:src/share/org/apache/struts/taglib/bean WriteTag.java
> >   Log:
> >   Add notes regarding discovering localized notations, per research by Jason Lea.
> >
> >   Revision  ChangesPath
> >   1.31  +12 -5 
> > jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java
> >
> >   Index: WriteTag.java
> >   ===
> >   RCS file: 
> > /home/cvs/jakarta-struts/src/share/org/apache/struts/taglib/bean/WriteTag.java,v
> >   retrieving revision 1.30
> >   retrieving revision 1.31
> >   diff -u -r1.30 -r1.31
> >   --- WriteTag.java 1 Jan 2004 19:27:19 -   1.30
> >   +++ WriteTag.java 1 Jan 2004 22:39:59 -   1.31
> >   @@ -316,7 +316,14 @@
> >/**
> > * Format value according to specified format string (as tag attribute or
> > * as string from message resources) or to current user locale.
> >   - *
> >   + *
> >   + * When a format string is retrieved from the message resources,
> >   + * applyLocalizedPattern is used. For more about localized
> >   + * patterns, see . (To obtain the correct
> >   + * value for some characters, you may need to view the file in a
> >   + * hex editor and then use the Unicode escape form in the
> >   + * property resources file.)
> >   + *
> > * @param valueToFormat value to process and convert to String
> > * @exception JspException if a JSP exception has occurred
> > */
> >
> >
> >
> >
> > -
> > 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]

Unable to compile the source.

[Anand Stephen]

Greetings,
Wish you all a very happy new year!
 
I am trying to compile the latest source of struts 
I have attached the error log.
 
Any help would be appreciated,
 
-anand
 
 
 
---Outgoing mail is certified Virus 
Free.Checked by AVG anti-virus system (http://www.grisoft.com).Version: 6.0.557 / 
Virus Database: 349 - Release Date: 12/30/2003
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\strutsel\taglib\bean\ELIncludeTag.java:64:
 cannot resolve symbol
[javac] symbol  : class JspException  
[javac] location: package jsp
[javac] import javax.servlet.jsp.JspException;
[javac]  ^
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\strutsel\taglib\bean\ELIncludeTag.java:85:
 cannot access javax.servlet.jsp.tagext.TagSupport
[javac] file javax\servlet\jsp\tagext\TagSupport.class not found
[javac] private String anchorExpr;
[javac] ^
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\strutsel\taglib\bean\ELIncludeTag.java:209:
 cannot resolve symbol
[javac] symbol  : class JspException  
[javac] location: class org.apache.strutsel.taglib.bean.ELIncludeTag
[javac] public int doStartTag() throws JspException {
[javac]^
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\strutsel\taglib\bean\ELIncludeTag.java:220:
 cannot resolve symbol
[javac] symbol  : class JspException  
[javac] location: class org.apache.strutsel.taglib.bean.ELIncludeTag
[javac] private void evaluateExpressions() throws JspException {
[javac]   ^
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\strutsel\taglib\bean\ELMessageTag.java:63:
 javax.servlet.jsp.JspException is not public in javax.servlet.jsp; cannot be accessed 
from outside package
[javac] import javax.servlet.jsp.JspException;
[javac]  ^
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\strutsel\taglib\bean\ELMessageTag.java:277:
 javax.servlet.jsp.JspException is not public in javax.servlet.jsp; cannot be accessed 
from outside package
[javac] public int doStartTag() throws JspException {
[javac]^
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\strutsel\taglib\bean\ELMessageTag.java:288:
 javax.servlet.jsp.JspException is not public in javax.servlet.jsp; cannot be accessed 
from outside package
[javac] private void evaluateExpressions() throws JspException {
[javac]   ^
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\strutsel\taglib\bean\ELPageTag.java:64:
 javax.servlet.jsp.JspException is not public in javax.servlet.jsp; cannot be accessed 
from outside package
[javac] import javax.servlet.jsp.JspException;
[javac]  ^
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\strutsel\taglib\bean\ELPageTag.java:130:
 javax.servlet.jsp.JspException is not public in javax.servlet.jsp; cannot be accessed 
from outside package
[javac] public int doStartTag() throws JspException {
[javac]^
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\strutsel\taglib\bean\ELPageTag.java:141:
 javax.servlet.jsp.JspException is not public in javax.servlet.jsp; cannot be accessed 
from outside package
[javac] private void evaluateExpressions() throws JspException {
[javac]   ^
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\strutsel\taglib\bean\ELResourceTag.java:64:
 javax.servlet.jsp.JspException is not public in javax.servlet.jsp; cannot be accessed 
from outside package
[javac] import javax.servlet.jsp.JspException;
[javac]  ^
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\strutsel\taglib\bean\ELResourceTag.java:146:
 javax.servlet.jsp.JspException is not public in javax.servlet.jsp; cannot be accessed 
from outside package
[javac] public int doStartTag() throws JspException {
[javac]^
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\strutsel\taglib\bean\ELResourceTag.java:157:
 javax.servlet.jsp.JspException is not public in javax.servlet.jsp; cannot be accessed 
from outside package
[javac] private void evaluateExpressions() throws JspException {
[javac]   ^
[javac] 
D:\Projects\Apache\jakarta-struts\contrib\struts-el\src\share\org\apache\