Future Struts evolution: look at elements of BEA Page Flows

[Karr, David]

Before I go any further, I'd like to say that I haven't had time to go
over any of the proposed future architectural ideas for Struts going
forward.  Nevertheless, as I put on my flame-retardant gloves, I'd like
to know if anyone thinking about this has examined the elements of the
BEA Page Flow architecture.  I can't call myself an expert with this,
but I've seen enough to be intrigued.

The Page Flow architecture is an extension of Struts 1.1 (it uses it
internally, and also allows build time and run time integration of pure
Struts applications).

The high-level elements that I think are intriguing, and might have some
application to the Struts architecture, would be the following:

Each "Page Flow" is represented by a Page Flow Controller class.  A Page
Flow corresponds to a Struts Module.  Every action in a Page Flow
(module) is handled in the single controller.  The routing of Forwards
to action methods is basically done through reflection, as opposed to a
configuration file mapping.  One instance of the Page Flow Controller is
created for every user session.  The properties of the controller are
read and modified to keep track of a user's progress.

ActionForms are also used as an additional way to transmit and collect
user data, although since Page Flows are easily nested, you tend to
write smaller page flows where most of the transient user data is stored
in the Page Flow Controller instead of ActionForms.

I don't really have any idea how the evolution of Struts should work
with the evolution of JavaServer Faces. I can only look a short distance
ahead.

Although BEA Page Flows are part of a commercial product, BEA has been
attempting to release several elements of their newer products as
open-source projects.  I wouldn't be at all surprised to see them
release much of the Page Flow architecture as a SourceForge project in
the very near future.

If you wanted to examine Page Flows and try it out, all the tools and
documentation are freely downloadable.  The WebLogic Platform EvalGuide
has tutorials on Page Flows (and other aspects).  It obviously requires
WebLogic for this, but the intent is that Page Flow applications that
don't use EJB elements can be deployed to Tomcat or any Servlet 2.3
container (I don't know how/if they would handle licensing for this).
The tutorials mostly focus on using the Workshop GUI to do this work,
but from our point of view, it's useful to understand the architectural
elements the GUI is operating on.

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

RE: [VOTE] 1.2.0 Release Plan

[Karr, David]

Does this involve changing the file header comment to replace the
existing license with the new license?  That's something that I can
relatively easily script in elisp macros.  If someone can confirm that's
all this is, and show me exactly what needs to change, I can get that
done this weekend.

-Original Message-
From: Joe Germuska [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 20, 2004 12:12 PM
To: Struts Developers List
Subject: Re: [VOTE] 1.2.0 Release Plan


At 1:49 PM -0600 2/20/04, Joe Germuska wrote:
>>  > Just a few things:
>>>
>>>  * What about the new Apache license? Technically, it doesn't need 
>>> to  change if we release before March 1st, but we're mighty close to

>>> that,  so
>>  > perhaps we should switch now?
>
>+1 from me too; wasn't someone offering to do it a few weeks ago?

I should amend this: + 0 from me; I don't have time to do it now, and 
probably won't soon enough that I'd want to delay 1.2.0 until it gets 
done.

Joe
-- 
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
   "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
 -- Jef Raskin

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


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

RE: Mavenising struts-el

[Karr, David]

The cactus test cases I had written for struts-el are probably out of
date, and were written before the attempt to clean up and enhance the
existing cactus tests with new strategies.  I haven't dedicated time to
rework them yet, partially because I didn't see a huge need for it.  I
believe I had no pure Junit tests.

-Original Message-
From: Joe Germuska [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 10, 2004 8:50 AM
To: Struts Developers List
Subject: Mavenising struts-el


OK, so in order to fix bug # 26788, I had to go ahead and commit the 
changes I brought up earlier for struts-el regarding removing invalid 
imports.  There are still several test classes that have all their 
test methods commented out -- if anyone has some spare time, it might 
be worth looking at those and trying to fix them up.

Since I had done that, I went ahead and also committed the Maven POM 
file.  I accidentally had a '-m' on my cvs commit so I wasn't able to 
specify this in the commit message: I set the version number at 
1.2.0-dev with the intent that it be correlated with Struts version 
numbers.  If anyone has stronger feelings or better experience than I 
do with assigning version numbers, feel free to advise, but part of 
me likes the idea of keeping the contrib version numbers tracking 
Struts version numbers.

Not all of the tests pass when maven test is run, but I suspect that 
may be related to the apparently incomplete state of the tests -- 
when I run 'ant test.junit', there are apparently no tests.  Are 
there only cactus tests in there?  I haven't looked at maven/cactus 
for struts-el and don't know when I'll be able to.

Just wanted to update folks, mostly because I biffed the commit
message...

Joe

-- 
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
   "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
 -- Jef Raskin

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


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

RE: Browser-specific attrs for html tags (was: [Bug 26795])

[Karr, David]

Simpler for who?  If we assume hypothetically for a moment that it's
reasonable to allow developers to specify "custom" attributes, then it's
obviously easier for them to just specify the syntax which adds the
custom attributes, as opposed to having them do the work of defining a
subclass and changing the TLD.

I've always been sympathetic to the goal of enforcing the HTML standard,
particularly for "internet" applications, as opposed to "intranet"
applications.  However, when it comes to supporting intranet
applications, a more effective approach might be the pragmatic one.

-Original Message-
From: Joe Germuska [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 09, 2004 9:52 AM
To: Struts Developers List
Subject: Re: Browser-specific attrs for html tags (was: [Bug 26795])


At 9:28 AM -0800 2/9/04, Hubert Rabago wrote:
>This probably won't be the last request for an attribute which turns 
>out to be browser specific.  Perhaps the html taglib can include some 
>mechanism to allow developers to add other attributes.


You can always subclass the tag and change the TLD file.  This seems 
like a much simpler solution to me.

Joe


-- 
Joe Germuska
[EMAIL PROTECTED]  
http://blog.germuska.com
   "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
 -- Jef Raskin

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


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

RE: cvs commit: jakarta-struts/contrib/struts-el/doc/userGuide struts-html-el.xml

[Karr, David]

It looks like this is the same change I committed last night.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Sunday, January 18, 2004 5:15 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-struts/contrib/struts-el/doc/userGuide
struts-html-el.xml


husted  2004/01/18 05:15:08

  Modified:contrib/struts-el/doc/userGuide struts-html-el.xml
  Log:
  Apply #26127 " tag lacks "action" attribute" suggested by
Firepica.
  
  Revision  ChangesPath
  1.25  +17 -0
jakarta-struts/contrib/struts-el/doc/userGuide/struts-html-el.xml
  
  Index: struts-html-el.xml
  ===
  RCS file:
/home/cvs/jakarta-struts/contrib/struts-el/doc/userGuide/struts-html-el.
xml,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- struts-html-el.xml18 Jan 2004 07:11:26 -  1.24
  +++ struts-html-el.xml18 Jan 2004 13:15:08 -  1.25
  @@ -2721,6 +2721,23 @@
   
   
   
  +
  +  action
  +  false
  +  true
  +  
  +  The action, starting with a slash, that will render
  +  the image to be displayed by this tag.  The rendered
  +  URL for this image will automatically prepend the
context
  +  path of this web application (in the same manner as the
  +  action attribute on the link tag works),
  +  in addition to any necessary URL rewriting.  You
  +  must specify the action,
  +  page
  +  attribute or the src attribute.
  +  
  +
  +
   
 align
 false
  
  
  

-
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 EL Distro

[Karr, David]

I don't see a problem with removing the duplicate jars from the lib
directory, but I disagree with distributing "half-baked" wars.  I like
the fact that users can deploy sample applications with little effort.

I have some spare time next week, so I could look at paring out
unnecessary jars from the lib dir, unless someone else wanted to work on
this.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Thursday, December 18, 2003 2:04 PM
To: Struts Developers List
Subject: 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]


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

RE: 1.2.0 Resurrected

[Karr, David]

I'm going to need to check for any updates to the tag interfaces and
move them to Struts-EL.  I'll make sure that's done before this weekend.

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED] 
> 
> With the long weekend coming up, I was thinking of rolling up 
> my sleeves 
> and doing whatever needs to be done to cut 1.2.0.
> 
> Anyone one aware of any serious showstoppers?
> 
> While under the current scheme, any release has the potential to make 
> the General Availability grade, I would anticipate that 1.2.0 
> will end 
> up being a simple "milestone" release, and we'll have to cut 
> a few more 
> before we get to GA. But, I'd like to start the ball rolling.

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

RE: [Vote]Disable bugs for Struts 1.0

[Karr, David]

+1

> -Original Message-
> From: Robert Leland [mailto:[EMAIL PROTECTED] 
> Sent: Monday, November 03, 2003 7:28 PM
> To: [EMAIL PROTECTED]
> Subject: [Vote]Disable bugs for Struts 1.0
> 
> 
> I would like to propose disabling filing of NEW bugs for Struts 1.0,
> I know BugZilla 2.16.3 can do this not sure about 2.14.2
> 
> Bugs filed against 1.0 are a waste of time for committers and 
> for reporters.
> Only bugs filed against 1.1 final, or the nightly builds have 
> any hope 
> in being addressed.
> If there were patches included with the reciently reported 1.0 
> enhancements, I might feel
> differently. As it is NEW Struts 1.0 BugZilla reports are just Noise 
> that I filter out.
> 
> -Rob
> 
> 
> -
> 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: EL evaluation performance...

[Karr, David]

> -Original Message-
> From: Arron Bates [mailto:[EMAIL PROTECTED] 
> 
> Peoples (Dave?),
> 
> Just curious as to how quickly the EL tag logic identifies 
> that there is in
> fact stuff to evaluate?
> 
> Any micro-benchmarks?

Sorry, I don't know of any benchmarks for this.

> If there's no real overhead, especially for properties 
> provided without
> expression, to just use them in the tags as-is. Or at least 
> the nested tags
> where the internals aren't as deep as the rest.

I'm sure there would be some overhead, but I would imagine that a simple
string search for "${" would determine whether any evaluation needs to
be done.  That couldn't be that expensive.

The principal reason why I've implemented the EL libraries as wrappers
over the regular libraries, as opposed to making the EL evaluation calls
in the regular library (like you seem to be suggesting we do for
"nested-el"), is that when JSP 2.0 is available, users can just change
their taglib directive to point back to the regular library (I now
recommend that people use the original prefix, not the "-el" prefix),
and the EL library can just be ignored.  If we integrated the EL calls
into the regular library, you'd have to go in and remove those calls and
generate new release of the regular library, because you'd want the JSP
container to handle that work.

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

RE: Looking for thoughts on html:errors with indexed properties

[Karr, David]

> -Original Message-
> From: James Turner [mailto:[EMAIL PROTECTED] 
> 
> Hi gang,
>Currently, the html:errors tag doesn't work well with
> indexed properties, because it looks for an exact match on
> the property name.  So if you have an error in
> petFish[3].species, you need to have:
> 
> 
> I'd like to propose (and will implement if people think it's
> a good idea) two new things.
> 
> First off, doing  property="species" indexed="true"> should match errors for
> the current iteration values.
> 
> Secondly, doing  property="species"> should match all errors for any
> iteration.

The first item looks like a good idea, but the second looks a little
questionable.  It might help if you showed explicitly what that would
mean.

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

RE: Struts-el: Page Tag: Why?

[Karr, David]

> -Original Message-
> From: Derek Richardson [mailto:[EMAIL PROTECTED] 
> 
> The bean:page tag is not one of the tags listed as not being 
> ported into struts-el 
> (http://jakarta.apache.org/struts/faqs/struts-el.html). This 
> means that bean:page can do something struts-el cannot. Will 
> someone point out to me what this is? I wrote a test JSP and 
> cannot find any functionality of the page tag that cannot be 
> reproduced with the JSTL set tag and the EL.

You're right, that was a mistake on my part.  I'm not aware of any
reason to use "bean:page" instead of the JSTL.  It's been pointed out to
me at least once before.

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

RE: [VOTE] Struts 1.1 Final Release

[Karr, David]

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 26, 2003 4:43 AM
> To: [EMAIL PROTECTED]
> Subject: [VOTE] Struts 1.1 Final Release
> 
> Since no significant issues have arisen in response to Struts 1.1 RC2,
I
> propose that we release the tip of the main trunk in CVS as the Struts
> 1.1 Final release. I have checked in a proposed release plan, which is
> available for review on the Struts web site:
> 
>   http://jakarta.apache.org/struts/proposals/release-plan-1.1.html
> 
> Release plans must pass by a majority vote of committers on the
project,
> but all other interested parties are welcome to cast their votes
(and/or
> make comments or suggestions on the plan) as well.
> 
>

--
>   Vote:  Struts 1.1 Final Release Plan
>   [X] +1 I am in favor of the release, and will help support it
>   [ ] +0 I am in favor of the release, but am unable to help support
it
>   [ ] -0 I am not in favor of the release
>   [ ] -1 I am against this proposal (must include a reason).
>


Hallelujah.

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

RE: Status check?

[Karr, David]

Perhaps a "-target 1.2" option should be specified on our "javac"
targets?  I would guess the number of issues with down-compilation from
1.4 to 1.2 is very small, but if we have one in our code base, the
compiler won't tell us about it.

> -Original Message-
> From: Hajratwala, Nayan (N.) [mailto:[EMAIL PROTECTED]
> 
> >-Original Message-
> > From: Martin Cooper [mailto:[EMAIL PROTECTED]
> >
> > "Ted Husted" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > > Our installation page says our dependency is J2SE 1.2 or later.
> > >
> > > Does that mean I should compile the binary distribution
> > under the latest
> > > J2SE 1.2, or should I use the latest J2SE 1.4?
> >
> > I have been building the releases using J2SE 1.4 for some
> > time now, and I
> > would recommend sticking with that. Going with 1.4 ensures we get
the
> > benefits of the latest compiler improvements. The
> > compatibility issue is
> > with the JVM rather than the compiler - we want to be able to
> > run on J2SE
> > 1.2, but we don't need to build the releases with that.
> 
> I don't believe this is correct.  I think it actually is the COMPILER
that
> can cause a compatibility issue.  There is an article over at Java
World
> that details this problem.  The first example makes it clear.
> 
> http://www.javaworld.com/javaqa/2003-05/02-qa-0523-version.html?

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

RE: Would a fix be useful

[Karr, David]

I would point out a couple things about this issue, however.  If you
inspect the code in "Double.parseDouble()" and "Long.parseLong()", it
becomes clear that a complete implementation of this is not trivial.
Also note that the "commons-lang" project apparently addresses some of
this, but I don't how well it avoids exceptions for normal processing.

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> 
> Put your function in the compare tag code.  Submit a patch in cvs diff
-u
> format to the bug report you opened.
> 
> David
> 
> >From: [EMAIL PROTECTED]
> >
> >I created bug http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18583
> >
> >If I coded a fix would that be useful?
> >
> >What should my expectations around getting a fix validated and
commited
> be?
> >
> >Given that a fix would involve some utility type functionality
> >(isLong,isDouble)),
> >is there a place where that should go (org.apache.struts.util)?
> >
> >Or should I just shove it in the Compare class file?
> >
> >Or is there a related project this should go in?

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

RE: is missing a "readonly" attribute

[Karr, David]

The Struts tags support, either directly or indirectly, the attributes
supported in the underlying HTML 4.01 specification.  The HTML "select"
tag doesn't specify a "readonly" attribute, so neither does Struts.

> -Original Message-
> From: Raible, Matt [mailto:[EMAIL PROTECTED]
> 
> The  tag is missing a "readonly" attribute - is this as
> designed?
> 
> http://jakarta.apache.org/struts/userGuide/struts-html.html#select

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

RE: Using tiles def in global forwards broken?

[Karr, David]

You said "does not work".  It would be a challenge for anyone to figure
out what might be wrong if we don't know what happened.

> -Original Message-
> From: White, Joshua A (CASD, IT) [mailto:[EMAIL PROTECTED]
> 
> Would you mind helping me out?  Could you compare my information with
> yours?
> 
> Struts Version: jakarta-struts-1.1-rc1
> In Welcome page (default page):
> <%@ taglib uri="struts-logic" prefix="logic"%>
> 
> 
> In Struts config:
> ...
>   
> 
>   
> 
> ...
> 
> 
>  value="/WEB-INF/tiles-defs.xml"/>
> 
> 
>  value="true"/>
> 
> 
> 
> 
> In tiles-defs.xml:
> ...
> 
>  path="/WEB-INF/jsp/layouts/defaultLayout.jsp">
>   
>   
>value="/WEB-INF/jsp/common/body-content.jsp"/>
>   
> 
> 

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

RE: Short term plans

[Karr, David]

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]
> 
> My plans are to finish up html this weekend, and tiles, upload, and
> validator by the end of next week.  After that I hope to get all the
> nested tags done between 3/15 and 3/22, then move on to the struts-el
> tags.
> 
> The only thing that might delay things is the fact that my contract is
> almost up and I'm desperately looking for another job.
> 
> Does anyone object or is there a special focus that anyone wants to
get
> covered quickly?
> 
> Also, are there any volunteers out there wanting to help me get this
> stuff nailed?

Sigh.

If your new testing setup is reasonably straightforward, I wouldn't
imagine it could be very difficult for me or someone else to clone them
(and remove some) for the Struts-EL tests.  There already is a set of
Cactus tests for Struts-EL which covered more than the original base
Struts tests did, but your new work has very likely jumped well past
that.

In short, if you've finished everything you need to do for bean, logic,
and html, and you have some doors to knock on, then give me what I need
to know and I'll implement the Struts-EL tests (or someone else, if they
wanted to do this).  If Aaron has time, he could probably do the same
for the nested tags.


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

RE: Should html:file tag have a value attribute?

[Karr, David]

I would change "... by most browsers" to "... by most browsers (for
security reasons)", just for a little more background.

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 28, 2003 12:05 PM
> To: 'Struts Developers List'
> Subject: RE: Should html:file tag have a value attribute?
> 
> Here's what I've come up with so far.anyone want to add anything
> before I commit this?
> 
> 
> 
>   NOTE: When setting this to some value, whether
>   intentional or as the result (for example) of validation errors
>   forcing the user back to the original jsp, this value is ignored
> 
>   by most browsers.
>   This means that your users will have to re-select any previously
>   selected file(s) when submitting the form.  The Opera web
> browser
>   will prompt the user so they have a chance to abort the submit.
> 
>   Value to which this field should be initialized. [Use the
>   corresponding bean property value or body content (if any) if
>   property is not specified]
> 
> 
> 
> 
> --
> James Mitchell
> Web Developer/Struts Evangelist
> http://jakarta.apache.org/struts/
> 
> 
> 
> > -Original Message-
> > From: Karr, David [mailto:[EMAIL PROTECTED]
> > Sent: Friday, February 28, 2003 1:58 PM
> > To: Struts Developers List
> > Subject: RE: Should html:file tag have a value attribute?
> >
> >
> > There's definitely a C&P error in the doc.  The HTML
> > specification says
> > that the value of the "value" attribute MAY be used as the
> > default file
> > name presented in the FileChooser.  My favorite web site for
> > interpreting the spec, HTMLHelp, says that most browsers ignore this
> > value for security reasons.  I wonder what Opera does with this?
> >
> > Based on this, I would say we should correct the doc for the
> > attribute,
> > but not remove it.
> >
> > > -Original Message-
> > > From: James Mitchell [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, February 28, 2003 10:53 AM
> > > To: 'Struts Developers List'
> > > Subject: RE: Should html:file tag have a value attribute?
> > >
> > > I'm setting up Cactus tests for that tag and while Struts will put
> > > value="Some Value" if you specify it, it is completely ignored by
> > > Mozilla and IE.
> > >
> > > I am assuming that it was just a copy and paste error since our
docs
> > > state..."Value of the label to be placed on this button. This
value
> > will
> > > also be submitted as the value of the specified request parameter.
> > [Body
> > > of this tag (if any), or "Cancel"]  (RT EXPR)".  Notice that it
says
> > > 'button' and since it matches
> > >
> > > I realize that "Cancel" was probably a copy and paste error
> > > (html:password has it as well).  I think we need to remove it or
> > > document it better.
> > >
> > > Your thoughts?
> > >
> > >
> > > --
> > > James Mitchell
> > > Web Developer/Struts Evangelist
> > > http://jakarta.apache.org/struts/
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Karr, David [mailto:[EMAIL PROTECTED]
> > > > Sent: Friday, February 28, 2003 12:51 PM
> > > > To: Struts Developers List
> > > > Subject: RE: Should html:file tag have a value attribute?
> > > >
> > > >
> > > > Say what?  What makes you think it's ignored?  It doesn't
> > appear to
> > be
> > > > ignored in Struts (handled in BaseFieldTag.doStartTag()).
> >  The HTML
> > > > specification describes it, although another source
> > > > (HTMLHelp) says that
> > > > "most browsers" ignore it for security reasons.
> > > >
> > > > > -Original Message-
> > > > > From: James Mitchell [mailto:[EMAIL PROTECTED]
> > > > > Sent: Friday, February 28, 2003 9:36 AM
> > > > > To: Struts Developers List
> > > > > Subject: Should html:file tag have a value attribute?
> > > > >
> > > > >
> > > > > Setting a value for html:file is ignored.  (or is it an error
in
> > the
> > > > > spec???)
> > > > >
> > > > > I wanted to bounce this off someone before I remove it from
the
> > xml
> > > > > file.
> > > >
> > > >
> >
-
> > > > 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]
> >
> 
> 
> -
> 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: Should html:file tag have a value attribute?

[Karr, David]

There's definitely a C&P error in the doc.  The HTML specification says
that the value of the "value" attribute MAY be used as the default file
name presented in the FileChooser.  My favorite web site for
interpreting the spec, HTMLHelp, says that most browsers ignore this
value for security reasons.  I wonder what Opera does with this?

Based on this, I would say we should correct the doc for the attribute,
but not remove it.

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 28, 2003 10:53 AM
> To: 'Struts Developers List'
> Subject: RE: Should html:file tag have a value attribute?
> 
> I'm setting up Cactus tests for that tag and while Struts will put
> value="Some Value" if you specify it, it is completely ignored by
> Mozilla and IE.
> 
> I am assuming that it was just a copy and paste error since our docs
> state..."Value of the label to be placed on this button. This value
will
> also be submitted as the value of the specified request parameter.
[Body
> of this tag (if any), or "Cancel"]  (RT EXPR)".  Notice that it says
> 'button' and since it matches
> 
> I realize that "Cancel" was probably a copy and paste error
> (html:password has it as well).  I think we need to remove it or
> document it better.
> 
> Your thoughts?
> 
> 
> --
> James Mitchell
> Web Developer/Struts Evangelist
> http://jakarta.apache.org/struts/
> 
> 
> 
> > -Original Message-
> > From: Karr, David [mailto:[EMAIL PROTECTED]
> > Sent: Friday, February 28, 2003 12:51 PM
> > To: Struts Developers List
> > Subject: RE: Should html:file tag have a value attribute?
> >
> >
> > Say what?  What makes you think it's ignored?  It doesn't appear to
be
> > ignored in Struts (handled in BaseFieldTag.doStartTag()).  The HTML
> > specification describes it, although another source
> > (HTMLHelp) says that
> > "most browsers" ignore it for security reasons.
> >
> > > -Original Message-
> > > From: James Mitchell [mailto:[EMAIL PROTECTED]
> > > Sent: Friday, February 28, 2003 9:36 AM
> > > To: Struts Developers List
> > > Subject: Should html:file tag have a value attribute?
> > >
> > >
> > > Setting a value for html:file is ignored.  (or is it an error in
the
> > > spec???)
> > >
> > > I wanted to bounce this off someone before I remove it from the
xml
> > > file.
> >
> >
-
> > 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: Should html:file tag have a value attribute?

[Karr, David]

Say what?  What makes you think it's ignored?  It doesn't appear to be
ignored in Struts (handled in BaseFieldTag.doStartTag()).  The HTML
specification describes it, although another source (HTMLHelp) says that
"most browsers" ignore it for security reasons.

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 28, 2003 9:36 AM
> To: Struts Developers List
> Subject: Should html:file tag have a value attribute?
> 
> 
> Setting a value for html:file is ignored.  (or is it an error in the
> spec???)
> 
> I wanted to bounce this off someone before I remove it from the xml
> file.

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

RE: Investigating adding custom ant task to valid TLD attributes bean mappings

[Karr, David]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]
> 
> On Thu, 27 Feb 2003, Karr, David wrote:
> 
> > From: "Karr, David" <[EMAIL PROTECTED]>
> >
> > I don't like the fact that it's so easy to mess up my BeanInfo
mapping
> > in Struts-EL, as it's all validated at runtime through
introspection.
> > After 1.1 is released, I plan to do some minor rearrangement inside
the
> > BeanInfo classes and add a custom task to the build which uses a
class I
> > just wrote which parses a TLD (using Digester) and tries to verify
that
> > all the tag attributes have valid setter methods in the tag class.
> 
> Is this tool specific in any way to struts-el?  It sounds like a
generally
> useful tool that would work on any TLD.  One possible distribution
channel
> would be to propose it as an add-on utility to Tomcat (or even
something
> that could be enabled at context startup time -- from bug reports it
seems
> that WebLogic does this sort of checking).  Another avenue would be to
> package it as a commons library that could be used by apps relying on
> custom tag libraries (like we do), so that anyone could integrate it
into
> their build process.

No, it's not specific to Struts-EL.  It's just easier to mess up the
mapping in a library that uses BeanInfo.

> > The introspection mechanics of this class are relatively
> > straightforward, but really putting this into the build presents
some
> > questions in my mind, mostly Ant-related:
> >
> > Where should I put the Ant task class?  Obviously, it would go in
the
> > "struts-el" tree, but I'm not sure of the logistics of this.  The
task
> > can only be performed after the library is built, but I guess the
task
> > class has to be available when ant starts.
> 
> There's a similar chicken-and-egg issue with the custom Ant tasks for
> Tomcat integration.  What I do is just copy catalina-ant.jar from my
most
> recent Tomcat build and stick it in $ANT_HOME/lib.  I don't try to
build
> the Ant tasks and immediately use them.  (This would be another
argument
> for releasing this kind of library separately, even if it was struts
or
> struts-el specific.)

I'm convinced that this has wider applicability than Struts-EL, but I
don't think the Struts build should be directly dependent on Tomcat
(even though I hardly use anything else).  This points to a separate
"commons-jspantsupport" library, but the scope of that is awfully small.
I would guess there are no other tools at this scope.  It would look
pretty silly to just have the one task in the library.

One implementation detail I'm wondering about: When I use the Digester,
I apparently need to register a local copy of the taglib DTD (my
firewall here is brutal).  I guess one of the optional task parameters
would be the path to the TLD DTD.  Then, there's the question of whether
I use the 1.1 or 1.2 DTDs.  For the elements this tool is looking at, it
doesn't matter, but my "register" call has to match the DTD with the
public identifier.

Now that I'm thinking about this, perhaps the best place for a tool like
this (and others like it) would be in the JSTL implementation?  That
would muddle the issue for the people still hanging on to Servlet 2.2,
but it might be the most appropriate place for it.


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

Investigating adding custom ant task to valid TLD attributes bean mappings

[Karr, David]

I don't like the fact that it's so easy to mess up my BeanInfo mapping
in Struts-EL, as it's all validated at runtime through introspection.
After 1.1 is released, I plan to do some minor rearrangement inside the
BeanInfo classes and add a custom task to the build which uses a class I
just wrote which parses a TLD (using Digester) and tries to verify that
all the tag attributes have valid setter methods in the tag class.

The introspection mechanics of this class are relatively
straightforward, but really putting this into the build presents some
questions in my mind, mostly Ant-related:

Where should I put the Ant task class?  Obviously, it would go in the
"struts-el" tree, but I'm not sure of the logistics of this.  The task
can only be performed after the library is built, but I guess the task
class has to be available when ant starts.

I'd be glad to avoid writing an Ant task and just execute "java" in the
build, but I can't figure out how I can make what happens in the
execution of my class to cause the build to fail.

Note that I'm only referring to the Struts-EL build, although it's
conceivable we could also do this in the main build.  It's still
possible to mess up the "property name"->"setter" mapping, even if you
just use the standard mapping.  Catching the error at build time might
save someone a few minutes.

Testing for this could be done in unit testing, but the entire unit test
suite is not normally done as part of the build, because it takes too
long.  This task would go pretty quickly, so it wouldn't be painful to
have it as part of the default build.



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

RE: committers attention - just a few moments...

[Karr, David]

Failing responses from people who are actually familiar with the nested
tags and your changes, then I think you'll just have to use your own
judgment.  I had to make a similar decision recently wrt the Struts-EL
tags.  Test your changes as much as possible, and try to get some
feedback from people who are using your tags.  If you think it's safe to
commit, then do it (but don't quote me on that :) ).

> -Original Message-
> From: Arron Bates [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, February 25, 2003 3:03 PM
> To: [EMAIL PROTECTED]
> Subject: committers attention - just a few moments...
> 
> Peoples,
> 
> I'm waiting on a call in the post below about the nested tags. I know
> they're
> not everyone's favorite component, but I do need committer attention
to
> form
> the game plan as it's not the typical "bug fix".
> 
> It's hard to form a consensus opinion on the one response I have.
> 
> Copied below for convenience.
> 
> 
> Arron.
> 
> 
> 
> Original
> Post___
>

--
> --
> 
> Defenders of the faith,
> 
> Just a small one to say the problem of of not being able to run the
nested
> tag
> apps in Tomcat 4.1.18's funky Jasper engine has been tackled.
> 
> I'd commit it, but the codebase being under release conditions, and
for
> the
> fact that it's no simple few line "bug fix". The internals have
changed to
> leverage the request object more completely (was originally just used
to
> enable the recursive JSP markup). The NestedPropertyHelper has been
gutted
> and
> mostly re-implemented, and all the nested tags have been touched to
> accomodate the change. Instead of walking the tag hierarchy, all the
child
> tags now pick up on the nested reference within the request object
> directly.
> The property handling is now more pessimistic, and resets everything
it
> touches. All effort was made to respect all the minor changes the tags
> have
> undergone in fixing past bugs.
> 
> The fact that most of it has changed means that I don't want it in
this
> release, but the fact that it allows people to deploy in the latest
tomcat
> release is important, something blocking an upgrade path for a lot of
> people.
> 
> What about, once the release is out, then the update to the tags
> committed,
> and release a bug-fix release for the new nested tags (1.1.1)?... kind
of
> like
> 1.0.2 was to 1.0.1?...
> 
> Too unstable for 1.1 so close to release, but too important to let it
slip
> for
> over a year for it to come out.
> 
> Needless to say it works on my apps :), but I'm asking the nested tags
> user
> base to jump onto it and give it a test run to see if it works for
them.
> For
> those nesters looking on, there's a jar at...
> 
>http://www.keyboardmonkey.com/downloads/km-nested-v2.jar
> 
>  ...just throw it into the WEB-INF/lib directory, your classloader
should
> pick them up before struts.jar. If not, delete the tags from
struts.jar
> and
> give it another bash.
> 
> Anyways, just thought I'd put it forward.
> 
> Arron.
> 
> 
> 
> -
> 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: New Tests

[Karr, David]

Interesting.  I like this approach, but I think it's also useful to directly test the 
code by using mock objects.  In my Struts-EL tests, I did a little more than what was 
in the existing base tests.  I ended up setting header parameters for required 
attribute values, and I read the headers on the "other end", and used JTidy to help 
verify that I got required attribute values, and attribute values had the values I 
expected.  The drawback to having the mock object tests for Struts-EL (as opposed to 
using your "complete jsp" test) is that I have to remember to call the "setFooExpr()" 
setters, as opposed to the "setFoo()" setters (from the base class). I definitely like 
the JSP approach, as that tests the TLD also, which the mock objects cannot test.

-Original Message- 
From: James Mitchell [mailto:[EMAIL PROTECTED]] 
Sent: Wed 02/12/2003 9:22 AM 
To: Struts Developers 
Cc: 
Subject: New Tests



Lately, I've been focusing on building tests that cover the entire core
struts taglibs.  I've completed logic and I'm now hacking away on the bean
tags.

I don't claim to be expert with Cactus, but there seem to be 2 different
approaches with respect to testing taglibs.  (There are probably more, but
these 2 really seem to stick out in my mind)

The existing logic tags use the first approach which is programmatically
mimicing what the container will do wrt life cycle calls, the testing the
output or (in the case of boolean results) tag.condition(0, 0).

The second approach is to actually use a jsp to test the tag (this seems
more natural to me, and tests more peices of the puzzle IMHO).  But this
comes at the cost of time for page compilation.  Personnally, I can live
with that cost, for the benefits of using the real thing.  Doing it this way
also covers a long time bullet item that I've been wanting to complete for a
quite some time. (Complete examples of every tag, with every conceivable
configuration)


For example:
When building the tests for the o.a.s.t.b.TestCookieTag, a typical test
looks like this:

...
...
//
public void beginCookieName(WebRequest testRequest) {
   testRequest.addCookie(COOKIE_KEY, COOKIE_VAL);
}

public void testCookieName()
 throws ServletException,  JspException, IOException {

CookieTag tag = new CookieTag();
  tag.setPageContext(pageContext);
tag.setName(COOKIE_KEY);
tag.setId("theId");
tag.doStartTag();

Cookie cookie = (Cookie)pageContext.getAttribute("theId");
assertEquals("Verify that the cookie was defined properly as a
scripting variable",
   COOKIE_VAL,
   cookie.getValue());




I rewrote this test to call a jsp instead:
   //
public void beginCookieName(WebRequest webRequest) {
webRequest.addCookie(COOKIE_KEY, COOKIE_VAL);
webRequest.addParameter("cacheId", "1");
}

public void testCookieName()
throws ServletException,  JspException, IOException {

request.setAttribute("runTest", "testCookieName");

pageContext.forward("/test/org/apache/struts/taglib/bean/TestCookieTag.jsp")
;

}


then in the jsp, I do this:
-
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ page import="junit.framework.Assert"%>
<%@ taglib uri="/WEB-INF/struts-logic.tld" prefix="logic" %>
<%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>





 
 
 <% Assert.assertEquals(COOKIE_VAL, cookieId); %>




I wanted to know if any of you have a preference to how we do this.

Comments?



--
James Mitchell







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

RE: DO NOT REPLY [Bug 16749] New: - Struts EL tag handlers cannot be reused by containers

[Karr, David]

That's ok.  I can read my mail, from this account, at least.  Unfortunately, that's 
all I can do.  You'll still have to wait until Saturday for me to get anything to you. 
 It would probably be best if I provided an entire Struts dsitribution built locally.  
I can probably make that available to you by Saturday afternoon.

-Original Message- 
From: Mark Abbott [mailto:[EMAIL PROTECTED]] 
Sent: Tue 02/11/2003 8:21 AM 
To: Struts Developers List 
Cc: 
Subject: Re: DO NOT REPLY [Bug 16749] New: - Struts EL tag handlers cannot be 
reused by containers



Hi David - you are, of course, already out of town.
Sorry I could not respond earlier.  I can test with
a nightly build or even just a built struts-el.jar
and the tld files if they've changed, if this would
help you, once you return.

 Cheers - Mark

At 05:51 PM 2/8/2003, you wrote:
>Also, if I do commit these changes, I'd like to know if someone, especially
>including the person who reported the problem with Resin (perhaps unlikely on
>Saturday), would be able to get the latest changes and run their test case, 
as
>soon as possible, before the end of this day (say, 10pm PST).  As much as I'd
>like to release this in 1.1 so containers using this optimization can use
>Struts-EL effectively, I will not commit this today unless I get a good
>response before this evening.


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

RE: Bug 16685

[Karr, David]

That would be 16885, I assume?

> -Original Message-
> From: James Turner [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 07, 2003 4:00 PM
> To: [EMAIL PROTECTED]
> Subject: Bug 16685
> 
> In reference to Ted's note on the latest release plan, Dr. Validator
has
> looked at 16685 and it appears to be invalid based on my test.

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

RE: DO NOT REPLY [Bug 16749] - Struts EL tag handlers cannot be reused by containers

[Karr, David]

> -Original Message-
> From: Wendy Smoak [mailto:[EMAIL PROTECTED]]
> 
> David wrote:
> > I'll also have to build a little test case that clearly demonstrates
the
> > symptom.  Is this easily demonstratable in Tomcat?
> 
> (Just a user lurking on the dev list here...) I have not seen this
> behavior
> in Tomcat 4.1.18.  Has anyone written a tiny webapp that demonstrates
the
> problem?  I'm trying not to panic, but I've got a project that depends
on
> Struts-EL and JSTL.  I was hoping to see Struts-EL in the final
release,
> but

Based on what I understand, if you had a logic-el:iterate loop (or even
"c:forEach", now) containing a single "html-el:text" component whose
"value" attribute used an EL expression based on the index variable, the
first iteration would use the value of the first index, and the second
iteration would unexpectedly use the value from the first iteration
(because it wouldn't call the setter).  Is it really this simple?

> > I'll start to put this together, but I won't plan on committing it
in
> > the 1.1 timeframe unless we are motivated to want it sooner.
> 
> As soon as possible, please!  Is there a consensus on how to fix it
yet?

As you can see, we're still thinking about it.


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

RE: DO NOT REPLY [Bug 16749] - Struts EL tag handlers cannot be reused by containers

[Karr, David]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> 
> On Tue, 4 Feb 2003 [EMAIL PROTECTED] wrote:
> >
> > Struts EL tag handlers cannot be reused by containers
> >
> 
> It sounds like these tags definitely have a problem.  There's been
some
> recent discussion on TOMCAT-USER about designing tags that work
reusably
> as well.
> 
> The bottom line:
> 
> * When a tag handler instance is reused, the JSP page
>   compiler can decide if it has already set a particular
>   property on that instance, and omit the second set call.
>   For example, in:
> 
>   The second setA() call can be omitted, since the container
>   knows that it already called setA("1") the first time.

Does the value of the "rtexprvalue" attribute have any control over this
process, at least in common practice?

> * If a tag instance is going to be reused, the doEndTag()
>   call on the first use is going to be followed by the
>   doStartTag() call of the second use.  Any per-use cleanup
>   activity needs to happen at the end of doEndTag().

Or in doFinally, for for tags implementing TryCatchFinally.

> * The net effect of all this is an important restriction -- it's
>   not legal for a tag handler to modify the values stored by
>   the setter calls from the page, *anywhere* in the path from
>   doStartTag() through doEndTag().

Sigh.  I can see this now.  For reference, section 10.1 (Simple Tag
Handlers) of the JSP specification, in the section "Properties", has
this statement:

"Once properly set, all properties are expected to be persistent, so
that if the JSP container ascertains that a property has already been
set on a given tag handler instance, it needs not set it again. User
code can access property information and access and modify tag handler
internal state starting with the first action method (doStartTag) up
until the last action method (doEndTag or doFinally for tag handlers
implementing TryCatchFinally)."

If we want to release Struts-EL with 1.1, I guess we'll have to advise
users to turn off tag pooling in their containers.  Will that work?

If I now clearly understand how this works (we'll see), I think I know
how to fix this, but it will take considerable manual labor.  In short,
I'll have to change the source code for every EL tag class, and every EL
tag BeanInfo class, adding "shadow" attributes and getters/setters for
every tag attribute.  Although this will be a lot of typing, it's very
straightforward.

I'll also have to build a little test case that clearly demonstrates the
symptom.  Is this easily demonstratable in Tomcat?

I'll start to put this together, but I won't plan on committing it in
the 1.1 timeframe unless we are motivated to want it sooner.


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

RE: [PATCH] for 13279

[Karr, David]

His comment about the web page statement is valid, however.  Is it an
apache-wide policy to only use patches attached in bugzilla (despite
what the page says), or is it inconsistent?  If we (Struts) are varying
from the convention, then perhaps we should have a little statement on
the Struts page that mentions our variance from the convention.

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]] 
Sent: Monday, February 03, 2003 1:20 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] for 13279

I know that's what it says but we don't follow that convention.  I 
personally never save any patches that come through the mail.  I *only* 
consider patches attached to a bugzilla ticket.

David



>From: Jay <[EMAIL PROTECTED]>
>Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
>To: Struts Developers List <[EMAIL PROTECTED]>
>Subject: Re: [PATCH] for 13279
>Date: 03 Feb 2003 16:17:07 -0500
>
>David:
>
>Thanks, I will do so. But you should know that I simply followed the
>instructions posted on the bug database home page
>(http://jakarta.apache.org/site/bugs.html):
>
>"If you have a patch to submit, please mail it to the appropriate
>developer mailing list. Use the prefix "[PATCH]" on your message
>subject. Please include any relevant bug numbers . ."
>
>Does this page need updating given your practice and perhaps the
>practice of other Apache projects?
>
>Jay
>
>
>
>On Mon, 2003-02-03 at 15:50, David Graham wrote:
> > Please post this to the bugzilla ticket.  We don't accept patches 
>through
> > the mailing list because they tend to get lost.
> >
> > David
> >
> >
> >
> > >From: Jay <[EMAIL PROTECTED]>
> > >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> > >To: Struts Development <[EMAIL PROTECTED]>
> > >Subject: [PATCH]  for 13279
> > >Date: 03 Feb 2003 15:49:10 -0500
> > >
> > >Cedric et.al;
> > >
> > >Enclosed are two proposed patches for the "swallowing exception"
> > >behavior of taglib/tiles/InsertTag.java (Bugzilla #13279).  The
first,
> > >"InsertTagNoFuncChange.txt", does what I originally suggested:
merely
> > >move the real handling of processException to a method outside of
the
> > >inner class to a protected method in InsertTag where sub-classing
and
> > >overriding the default behavior can easily be done.
> > >
> > >The second patch ("InsertTagFuncChange.txt") does change the
behavior 
>by
> > >only "swallowing" the exception when the log4j debug level is
enabled
> > >for the class.  If debug is not enabled, the exception will be
wrapped
> > >and "re-thrown" as the root cause of a JspException.
> > >
> > >I think the second alternative is the better one because a default
> > >behavior of broadcasting exceptions on the web page is not
particularly
> > >desirable.  However, I will be happy if either alternative is
applied
> > >
> > >I have provided complete javadoc comments for both alternatives
that 
>you
> > >may change as required.
> > >
> > >Thank you,
> > >Jay
> > >
> > >
> > ><< InsertTagNoFuncChange.txt >>
> > ><< InsertTagFuncChange.txt >>
> >
>-
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > _
> > The new MSN 8: advanced junk mail protection and 2 months FREE*
> > http://join.msn.com/?page=features/junkmail
> >
> >
> >
-
> > 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]


_
Protect your PC - get McAfee.com VirusScan Online  
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


-
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]

Plans for the upcoming 2/14 soft deadline?

[Karr, David]

What are anyone's intentions for the deadline I heard about for 2/14,
for some step in the release cycle?  I only ask this because I will be
out of town from 2/9-2/14.  I probably won't even be able to get to
email, much less do any last minute changes for the release.  I hope no
tag attribute changes are made just before the release like they were
for 1.1b3.  Any changes in that area should also be made in Struts-EL at
the same time.

Also, what is the status of the idea of separating the contrib libraries
out of the release?  I'm not certain what the result was of any vote on
this, but I had the impression there wasn't enough response to make a
decision.

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

RE: LogFactory.release(classloader)

[Karr, David]

This method was added to the commons-logging source in December, and
it's not in a release yet, just in the nightly build.

-Original Message-
From: Mohan Kishore [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, January 30, 2003 3:16 PM
To: [EMAIL PROTECTED]
Subject: LogFactory.release(classloader)


Hi,

Just joined in... Was trying to build from the sources in CVS. The call
to LogFactory.release(classloader) in the destroy method of the class
org/apache/struts/action/ActionServlet.java was not compiling. 

The call was introduced in revision 1.136, trying to fix a memory leak
problem. But, none of the commons-logging versions (1.0, 1.0.1,1.0.2)
seem to support this signature (they have a release() method...). 

Have a perfect build after I commented the line out...

regards,
Mohan.


Mohan Kishore
732 Marlin Ave, Apt 4
Foster City, CA 94404
[EMAIL PROTECTED]


-
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now

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

RE: Action question

[Karr, David]

Wouldn't those properties be set on the ActionMapping object, not the
Action?  That should be created before the Action object.

-Original Message-
From: Travis Chase [mailto:[EMAIL PROTECTED]] 
Sent: Friday, January 24, 2003 1:56 PM
To: Struts Developers List
Subject: RE: Action question

I would have to disagree because it looks like the RequestProcessor
loads a new Action if it does not exist in the actions HashMap.  Yet,
when I follow the loading of the class down to the RequestUtils class I
see it creating a new instance but do not see it populating that
instance with the dynamic properties that could be in setup using the
set-property element.  I see the use of BeanUtils.populate() for loading
the datasources, but fail to see where the dynamic properties of the
action is getting loaded.  Is this feature not implemented yet?


-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 24, 2003 3:07 PM
To: Struts Developers List
Cc: [EMAIL PROTECTED]
Subject: Re: Action question


This is a question best asked on the USER list.

http://jakarta.apache.org/struts/using.html

Though, the answer is that the ActionServlet loads everything.

-Ted.

Travis Chase wrote:
> I am a newbie to the source base and was wondering what class loads
the Action class with is properties defined in the action element as
well as the dynamic properties defined in the set-property element that
would be a child of the action element.
> 
> thanks
> 
> *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~
> Travis L. Chase
> Senior Programmer Analyst
> Leggett & Platt, Inc.
> [EMAIL PROTECTED]
> 417-358-8131 ext.3865
> ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
> 
> "A dead thing can go with the stream, but only a living 
>  thing can go against it." - G. K. Chesterton
> 
> "Impartiality is a pompous name for indifference, which 
>  is an elegant name for ignorance." - G. K. Chesterton
> 
>  
> 
> 
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:

> 
> 


-- 
Ted Husted,
Struts in Action 


--
To unsubscribe, e-mail:

For additional commands, e-mail:



--
To unsubscribe, e-mail:

For additional commands, e-mail:



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Link to current bugs we're focusing on for 1.1rc1?

[Karr, David]

Could someone repost the link for the current list of bugs we're
focusing on for 1.1rc1?  I just subscribed on this address, and I can't
find it in the archives.

Has there been any activity posted this morning about when we're going
to tag rc1?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: options collection problem

[Karr, David]

If you don't put the form bean into the session, the values won't be
there on the next request.  Do you have the "scope" of the action set to
"session" or "request"?

> -Original Message-
> From: Jain, Vikas [mailto:[EMAIL PROTECTED]]
> Sent: Monday, December 30, 2002 10:36 AM
> To: Struts Developers List
> Subject: RE: options collection problem
> 
> 
> You are right. But here is the confusing part,
> 
> When getters are called (getNoticeStatus()) on the form associated 
> with the page which has 'noticeStatus', they have null values. So, 
> on the page i use session object to get my values and display them. 
> While submitting the form the setters are called appropriately and 
> sets the value.
> 
> And now i am wondering, i am NOT benefitting from the getters at 
> all. How do i put them to use. So that i dont have to use session 
> values on the page.
> 
> 
> 
> --On Monday, December 30, 2002 9:36 AM -0800 "Karr, David" 
> <[EMAIL PROTECTED]> wrote:
> 
> > The setter and getter for the "noticeStatus" property on your
> > form bean are the key to this.  The setter is used when you
> > submit the form, and the getter is used to populate the selected
> > item.  It would be useful to set a breakpoint in your getter
> > method, to first verify it is getting there, and then to verify
> > what value it is retrieving.  It's possible the form bean is just
> > in request scope, which would mean the form bean used to set the
> > value at submit time would be a different object from the bean
> > used to populate the form.
> >
> >> -Original Message-
> >> From: Jain, Vikas [mailto:[EMAIL PROTECTED]]
> >>
> >> I am having trouble in displaying default or previous stored
> >> value  while using the following:
> >>
> >> 
> >>   >> labelProperty="noticeStatusStrKey"
> >> property="noticeStatusStrValue"/> 
> >>
> >>
> >> Value is selected and set properly but next time it does not
> >> show  the previous stored value. ??
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]> For additional
> > commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >
> 
> 
> 
> ---
> Jain, Vikas
> Vanderbilt University
> Email: [EMAIL PROTECTED]
> 
> --
> To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>

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

RE: options collection problem

[Karr, David]

The setter and getter for the "noticeStatus" property on your form bean
are the key to this.  The setter is used when you submit the form, and
the getter is used to populate the selected item.  It would be useful to
set a breakpoint in your getter method, to first verify it is getting
there, and then to verify what value it is retrieving.  It's possible
the form bean is just in request scope, which would mean the form bean
used to set the value at submit time would be a different object from
the bean used to populate the form.

> -Original Message-
> From: Jain, Vikas [mailto:[EMAIL PROTECTED]]
> 
> I am having trouble in displaying default or previous stored value 
> while using the following:
> 
> 
>   labelProperty="noticeStatusStrKey" property="noticeStatusStrValue"/>
> 
> 
> 
> Value is selected and set properly but next time it does not show 
> the previous stored value. ??

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [OT] Re: Why are people are up on Struts

[Karr, David]

Many years ago, it took me about five minutes after starting to use
Emacs with a PC keyboard that I had to get the Ctrl and CapsLock keys
switched.  It's much easier once you get that done.

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]]
> 
> On Fri, 13 Dec 2002, Eddie Bush wrote:
> 
> > I can live with vi if it's forced upon me, but I much prefer Emacs.
> >  'Course nowadays, assuming you're using an x terminal (or are on
> > windows) both of them are fairly easily used through their 
> toolbars ...
> > at least, I think vim has one now (or can perhaps - nearly 
> certain).  I
> > suppose that's for the "mortals" among us ;-O  I just go 
> for the "arcane
> > key sequences" personally - so much more efficient.
> 
> Not so good on the wrists, though. A guy I work with just 
> switched from
> emacs to vi, after many years as a happy emacs user, because of acute
> tendonitis from all those C-/M-/... key sequences.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: nightly build still missing struts-el?

[Karr, David]

The only reference I can find to "${struts.home}/lib" is in the
"prepare.library" target, which is used to copy in the struts.jar and
related files into the struts-el build:

  
   
   
  

I can build the distribution fine locally, without any changes, so I
don't know what the problem would be.  Perhaps the "jstl.jar" is not
available?  There is a check in the top-level build.xml that would
prevent struts-el from building if "jstl.jar" wasn't present.

> -Original Message-
> From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 12, 2002 4:47 PM
> To: Struts Developers List
> Subject: Re: nightly build still missing struts-el?
> 
> 
> One thing I noticed was that the build file for struts-el refers to 
> ${struts.home}/lib -- which I believe should point to 
> ${struts.home}/target/library.
> 
> Karr, David wrote:
> 
> >So does anyone know why the nightly build is still missing 
> the struts-el distribution?  It's been missing since about 
> 12/8.  Is there any place that I can look at the build output 
> or configuration?
> >
> -- 
> Eddie Bush
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: 
> <mailto:[EMAIL PROTECTED]>
> 

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

nightly build still missing struts-el?

[Karr, David]

So does anyone know why the nightly build is still missing the struts-el distribution? 
 It's been missing since about 12/8.  Is there any place that I can look at the build 
output or configuration?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts Taglibs

[Karr, David]

First of all, questions like this are better asked on the "struts-user" list.  This 
list is for issues related to the internal development of the Struts framework, not 
how to use it.

I would guess you would be looking for the "Validator" framework, which is a standard 
part of Struts (and has pieces that come from other packages).  Read the online user 
guide and associated resources for information on using the Validator framework.

> -Original Message-
> From: Herval Freire [mailto:[EMAIL PROTECTED]]
> 
>  Hello everyone,
> 
>  This is my first message on the struts list, so I 
> ask everyone to 
> be kind :)
> 
>  I've recently being using the Struts framework and 
> the Struts 
> Validator plugin for the first time. Greate boost on 
> productivity, but I 
> missed one thing:
>  Is there any taglib/attribute which allows me to generate 
> Javascript masks for textboxes? If no, is it on the scope of 
> Struts project?
> 
> 
>  Thanks!
> 
> 
> -
> --- Herval Freire de A. Júnior --
> - mailto:[EMAIL PROTECTED] ---
> - http://www.herval.hpg.com.br --
> - UIN: 2067270 --
> -
> --[The adepts are everywhere... awake! v0.666a]--
> -
> 
> "Erros graves: julgar-se mais do que se é e estimar-se menos 
> do que se 
> merece".
>-- Goethe 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts without taglib ?

[Karr, David]

Yes, you can use Struts without the tag library, and you can use CSS in
JSP pages.  The two things have no dependence on each other.

Questions like these are better asked on the "struts-user" list.

> -Original Message-
> From: Rajendra Yadav [mailto:[EMAIL PROTECTED]]
> 
> Thanks Andrew, So, if we can use them without the taglib, 
> then I assume we can use CSS in the jsp page. Is that correct ?
> - Raj
>  
>  Andrew Hill <[EMAIL PROTECTED]> wrote:Yes
> 
> -Original Message-
> From: Rajendra Yadav [mailto:[EMAIL PROTECTED]]
> 
> Hi All,
> 
> Is it possible to use Struts without the taglib ?
> 
> Thanks,
> 
> - Raj
> 
> 
> 
> -
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now
> 
> --
> To unsubscribe, e-mail: 
> For additional commands, e-mail: 
> 
> 
> 
> -
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Enhancement Request - add label and labelKey to form elements

[Karr, David]

This may not have any effect on the implementation, but also note that
another legal form of the "label" component is to NOT specify a "for"
attribute, but assume that the nested content is the component the label
is for.

It looks like the only way adding this tag could be of any benefit is if
we added something like the "key" attribute for the label, which would
at least save them the trouble of adding the nested "bean:message" tag.
I think that's probably not worth the trouble.

> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]]
> 
> Yes, it would create more confusion.  It's better to present 
> a consistent 
> view of the taglibs to users instead of using various 
> non-standard names.
> 
> David
> 
> >From: "Matt Raible" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Developers List" <[EMAIL PROTECTED]>
> >To: "'Struts Developers List'" <[EMAIL PROTECTED]>
> >Subject: RE: Enhancement Request - add label and labelKey to 
> form elements
> >Date: Mon, 25 Nov 2002 12:40:27 -0700
> >
> >I agree, and does require more work, considering:
> >
> >
> > 
> >
> >
> >Is more typing than:
> >
> >
> >...
> >
> >
> >Maybe something like this would make it more useful:
> >
> >
> >
> >I was thinking of reducing the prefixes in my struts-xdoclet 
> app from:
> >
> >  html -> h
> >  logic -> l
> >  bean -> b
> >  tiles -> t
> >  nested -> n
> >
> >Would this create too much confusion (even though it would 
> require less
> >typing?)?
> >
> >It much rather type 
> >
> >Matt
> >
> > > -Original Message-
> > > From: David Graham [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, November 25, 2002 12:25 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Enhancement Request - add label and labelKey to
> > > form elements
> > >
> > >
> > > I don't see what advantage the  tag has over hand
> > > coding the
> > > html.  Looks like the same amount of work to me.
> > >
> > > David
> > >
> > >
> > >
> > >
> > >
> > >
> > > >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> > > >Reply-To: "Struts Developers List" 
> <[EMAIL PROTECTED]>
> > > >To: Struts Developers List <[EMAIL PROTECTED]>
> > > >Subject: Re: Enhancement Request - add label and labelKey to form
> > > >elements
> > > >Date: Mon, 25 Nov 2002 11:14:10 -0800 (PST)
> > > >
> > > >On Mon, 25 Nov 2002, Matt Raible wrote:
> > > >
> > > > > Date: Mon, 25 Nov 2002 11:10:33 -0700
> > > > > From: Matt Raible <[EMAIL PROTECTED]>
> > > > > Reply-To: Struts Developers List 
> <[EMAIL PROTECTED]>
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Enhancement Request - add label and labelKey to form
> > > > > elements
> > > > >
> > > > > I thought I'd run this idea by the development team
> > > before entering
> > > > > it into Bugzilla.
> > > > >
> > > > > One of the items that is required with 508 compliance is
> > > a 
> > > > > value for each form element:
> > > > >
> > > > > For example:
> > > > >
> > > > > Name:
> > > > > 
> > > > >
> > > > > More information at: 
> http://www.csuohio.edu/uctl/508/forms.html
> > > > >
> > > > > This would typically be rendered with Struts tags using:
> > > > >
> > > > > Name:
> > > > > 
> > > > >
> > > > > To make it easier, we could do:
> > > > >
> > > > >  > > label="Name:"/> OR
> > > > >  > > > > labelKey="prompt.name"/>
> > > > >
> > > > > The problems I see with this are that you lose some
> > > control over the
> > > > > presentation (i.e. a  after the label or labels in
> > > a separate
> > > > > ).  However, it might be useful for rapid prototyping and
> > > > > code-generating tools.  My hope someday is that the JSP simply
> > > > > renders XML, and then an XSL stylesheet is applied, 
> and in this
> > > > > case, the presentation issues would disappear?
> > > > >
> > > > > What does everyone think?  Would anyone use it?
> > > > >
> > > >
> > > >I think a way to create  elements would be very
> > > useful.  I just
> > > >don't think we should embed it in the existing UI element
> > > tags (for the
> > > >reasons that others have articulated.
> > > >
> > > >How about a new  tag instead.  Then, you 
> could do things
> > > >like this on the logon page in struts-example:
> > > >
> > > >   ...
> > > >   
> > > > 
> > > >   
> > > > 
> > > >   
> > > > 
> > > > 
> > > >> > >maxlength="18"/>
> > > > 
> > > >   
> > > >   ...
> > > >
> > > >(I thought you tied labels to elements with the "id" ???)
> > > >
> > > >The above approach assumes that it's not necessary to 
> localize the
> > > >element id itself (which would really complicate attempts to
> > > generate
> > > >JavaScript event handlers), but you do (of course) need to
> > > localize the
> > > >text of the label.
> > > >
> > > >This also imposes no restrictions on the mechanisms by which
> > > you manage
> > > >layout, and can be easily retrofitted onto existing pages.
> > > >
> > > > > Thanks,
> > > > >
> > > > > Matt
> > > > >
> > > >
> > > >Craig
> > > >
> > > >
> > > >--
> > > >To unsubscribe, e-mail:
> >

RE: Enhancement Request - add label and labelKey to form elements

[Karr, David]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> 
> I think a way to create  elements would be very useful.  I just
> don't think we should embed it in the existing UI element 
> tags (for the
> reasons that others have articulated.
> 
> (I thought you tied labels to elements with the "id" ???)

Uh, yes, that's what the specification says.  That sort of makes my
comment about tricky ways to engineer the "name" property sort of dumb.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Enhancement Request - add label and labelKey to form elements

[Karr, David]

It would be good to provide some sort of automated support for this
component, but I don't see how we can possibly assume where the label
component will be placed.  Yes, it could be used for prototypes, but I'd
rather not build a framework that people use to build throwaway code.

The annoying part of this would be forcing them to build the same
resulting "name" attribute as the associated component.  This gets
annoying with indexed tags, and even worse, manually indexed or mapped
properties.  I wonder whether it's feasible to have the Struts tags
point in the OTHER direction, from the pointed-to component to the label
component, so the resulting "name" attribute can be reliably rendered in
the associated "label" component.  I don't think we've done anything
like this before, however.  The text of the label could be specified
"raw" or as a "key" attribute, either in the pointed-to component, or in
the "label" component.

> -Original Message-
> From: Matt Raible [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 25, 2002 10:11 AM
> To: [EMAIL PROTECTED]
> Subject: Enhancement Request - add label and labelKey to form elements
> 
> 
> I thought I'd run this idea by the development team before entering it
> into Bugzilla.
> 
> One of the items that is required with 508 compliance is a 
>  value
> for each form element:
> 
> For example:
> 
> Name: 
> 
> 
> More information at: http://www.csuohio.edu/uctl/508/forms.html
> 
> This would typically be rendered with Struts tags using:
> 
> Name: 
> 
> 
> To make it easier, we could do:
> 
>  OR
>  labelKey="prompt.name"/>
> 
> The problems I see with this are that you lose some control over the
> presentation (i.e. a  after the label or labels in a separate
> ).  However, it might be useful for rapid prototyping and
> code-generating tools.  My hope someday is that the JSP simply renders
> XML, and then an XSL stylesheet is applied, and in this case, the
> presentation issues would disappear?
> 
> What does everyone think?  Would anyone use it?
> 
> Thanks,
> 
> Matt
> 
> 
> 
> --
> To unsubscribe, e-mail:   

For additional commands, e-mail:


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Adding doc to user guide on indexed/mapped properties/tags

[Karr, David]

Acknowledged.  I've finished writing what I was going to put into the
user guide, but I'll move that to a "howto" section and replace it with
a short paragraph in both the "Model" and "View" sections in the user
guide which will just refer to the howto section.

> -Original Message-
> From: Ted Husted [mailto:[EMAIL PROTECTED]]
> 
> Personally, I'm finding that the user guide format is becoming a 
> pain to maintain. I'd like to start moving some material out into 
> their own HOWTO sections, especially anything that includes a 
> significant amount of code. Some of the sections I was looking at 
> include 
> 
> 4.2.1 => how to write an DynaAtionForm 
> 
> 4.2.2 => how to write a map-backed ActionForm
> 
> 4.6.4 
> -> How to configure your web.xml 
> 
> -> How to setup the Struts taglibs
> 
> The goals being 
> 
> * to turn the user guide back into high-level overview of the 
> archtechture that helps people get the big picture, 
> 
> * to make it easier to add and maintain sections that include 
> implementation details, and 
> 
> * to avoid "pigeonholing" articles under "model", "view", or 
> "controller", since many implementation strategies include 
> building components on either side of a fence.
> 
> So, personally, I would suggest starting with a paragraph or two 
> that introduced index and mapped properties from an arcitechtural 
> pespective, and then link to a separate article with more details 
> that we could also put into the faq/howto area. (Something like 
> the preface, but with the links point to our own material.)
> 
> -Ted.
> 
> 11/24/2002 6:28:06 PM, [EMAIL PROTECTED] (David M. Karr) wrote:
> 
> >I believe that the current user guide doesn't cover indexed 
> properties, mapped
> >properties, or indexed tags, very well.  The API docs at least 
> mention indexed
> >tags.
> >
> >Over the last few days I've been writing something about these 
> areas that I
> >hope can go into the user guide.  I consider what I have to be a 
> reasonable
> >first draft.  Despite it being a draft, I think I'd like to 
> commit it in close
> >to its present form, as I doubt I'm going to get a great deal of 
> useful
> >feedback until it gets into the user guide.  It's sort of 
> longish, almost 350
> >lines of 80-column text.  Much of this length is from several 
> versions of a
> >simple JSP page showing usage of this.
> >
> >I'd like to add this as section 3.3.6, in the "Forms and FormBean 
> Interactions"
> >section, titled "Indexed & Mapped Properties".

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Velocity vs. JSP: objective tests?

[Karr, David]

One thing that should be considered is not a technical issue.  It's
clear that the number of JSP developers is much larger than Velocity
developers.  That doesn't mean JSP is "better" than Velocity, but it
means that people and training will be more portable when using JSP.
Assuming that same population disparity, however, you can also assume
that many Velocity developers will be at least somewhat familiar with
JSP, but not as much the other way around.

> -Original Message-
> From: micael [mailto:[EMAIL PROTECTED]]
> 
> I have settled on Struts as my application framework, 
> assuming that there 
> will continue to major shifts in the future (like the shift 
> to 1.1 has 
> been, which I like).  However, I have not decided on the scripting 
> language, if that is what you want to call it, viz. JSP vs. 
> Velocity or 
> some other choice.  At the risk of engendering the passions of the 
> committed, does anyone know an especially reliable guide to 
> the pros and 
> cons of the various choices?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE:

[Karr, David]

I actually did notice that when I did the Struts-EL port.
Unfortunately, I don't remember what I concluded about it.  It's
entirely possible I concluded something about "meddling in the affairs
of wizards" and ignored it.

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]]
> 
> On Mon, 18 Nov 2002, David Graham wrote:
> 
> > The  tag only renders in xhtml if the locale 
> attribute is also
> > set to true.  Users are confused by this and I'm not sure 
> why it was coded
> > that way.  Can anyone enlighten me?
> 
> It looks to me like it's simply a bug that's been there since 
> the class
> was first created. Probably a cut/paste mistake when adding 
> in the XHTML
> handling.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts 1.0.2 + Xerces 2.2.0

[Karr, David]

This is not a bug.  It's part of the XML specification.

http://www.w3.org/TR/REC-xml#sec-comments

> -Original Message-
> From: Jeanfrancois Arcand [mailto:jfarcand@;apache.org]
> 
> we (the Tomcat dev team) are experiencing some problem with 
> Struts 1.0.2 
> and Xerces 2.2.0 in Tomcat. When starting Tomcat, a wrong 
> exception is 
> thrown (see below). Is somedoby aware of a similar problem? 
> I'm trying 
> to produce a smaller test case for the Xerces-J team (they 
> will not fix 
> the bug until I produce a smaller test case :-( ). I have make some 
> tests and the problem doesn't seems to come from the Digester, but 
> directly from Xerces.
> 
> Any help will be appreciated.
> 
> -- Jeanfrancois
> 
> Parse Fatal Error at line 551 column 44: The string "--" is not 
> permitted within comments
> .
> org.xml.sax.SAXParseException: The string "--" is not 
> permitted within 
> comments.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] How to implement XHMTL support

[Karr, David]

Neither am I.  Absolutely correct naming is almost impossible, it's just
a good goal.  If you can't make it perfect, the documentation should
take you the rest of the way.  Make sure that the documentation for the
"html" and "xhtml" tags refer to each other.  A boilerplate comment
about this in each HTML tag might be useful also.

> -Original Message-
> From: Martin Cooper [mailto:martinc@;apache.org]
> 
> On Wed, 13 Nov 2002, David Graham wrote:
> 
> > Ok, I think I agree with the non-body tag setting a page 
> scoped attribute.
> > I really like the style of  over 
> .  The "is"
> > part indicates that it's a question rather than stating 
> that we're using
> > xhtml.
> 
> I'm not that fussed about the name - isXhtml, useXhtml, or 
> just xhtml. I
> do agree with David Karr that just xhtml is rather subtle, but I'm not
> going to veto it. ;-)

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] How to implement XHMTL support

[Karr, David]

> -Original Message-
> From: Craig R. McClanahan [mailto:craigmcc@;apache.org]
> 
> The presumption of storing the "outer" xhtml setting 
> (independent of *how*
> you do so) is to let the included page automatically adapt to 
> the outer
> page's choice - presumably, that lets you use the same 
> included page in an
> XHTML and non-XHTML environment with no changes.
> 
> But, in reality, that's only true if 100% of the content of 
> the included
> page is struts-html tags -- if the developer has any static 
> HTML elements,
> for example, they *must* have selected one style or the 
> other, and that
> style won't get affected.  You're going to end up with a mishmash.

This is my primary objection to passing the xhtml flag "through" the
jsp:include unconditionally.  The included page needs to have control
over this.

> Maybe what we really need is a way for the included page to 
> tell its own
> Struts tags whether or not to be XHTML formatted or not.  Perhaps a
> specialized version of  that was 
> searched for the
> same way that the standard version is, but does *not* actually emit an
>  element?

I don't think it would be a "variation" of the "html:html" element, it
would have to be a separate tag, whose only purpose (AFAICS) is to set
this flag.

Would anyone have a reason to specify that the page should NOT use
xhtml?  I could envision a "html:useXhtml" tag (bleah), but should it
have an attribute that specifies a "true" or "false" value, or can it be
attribute-less?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [VOTE] How to implement XHMTL support

[Karr, David]

Just so I understand, you're experimenting with making tags generated
from a jsp:include be xhtml-compliant even if the original page wasn't
specified as being xhtml-compliant?  It seems to me that XHTML
compliance is an attribute of an "html" element and its nested elements
(including the associated DOCTYPE), and not an attribute of an HTTP
request.  This would mean that a page that was jsp:included would
generate different output depending on what page included it.

I'd say that choice 1 (only affecting the elements nested in the "html"
element), which I assume is what you've already done, is preferable to
choice 2 (runtime determination).

> -Original Message-
> From: David Graham [mailto:dgraham1980@;hotmail.com]
> 
> I've updated that html taglib tags to output xhtml when they 
> are nested in a 
>  tag.  This was very simple to do and 
> resulted in 
> minor code changes.  Users have suggested this approach:
> 
> 1.  Add Globals.XHTML_KEY which is a boolean request scoped attribute
> 2.  html tags check for that request attribute being true and output 
> accordingly.
> 3.  The html:html tag sets this request attribute when it's 
> xhtml attribute 
> is true.
> 
> The second approach allows the tags to output xhtml without 
> relying on the 
>  tag.  This allows people to construct pages with 
> jsp includes.  
> The first approach is logically clearer (to me) and you can 
> use tiles to 
> modularly construct the pages like includes.  Approach 2 may 
> be confusing 
> because you would have to remember all the places you may 
> have set that 
> request attribute.
> 
> So, do we go with 1, 2 or both?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Unclear semantics on form use for "wizards"

[Karr, David]

> -Original Message-
> From: Derek Lin [mailto:dereklin@;hotmail.com]
> 
> "
> Clearly, the page number is the crux of the problem.  That's all I was
> trying to address in that fantasy syntax I was suggesting.
> 
> What if each "form-property" element had an optional "page" attribute,
> holding an integer value (or range)?  At "reset" time, the only
> attributes that would be reset would be the ones without a "page"
> attribute, and the ones with a "page" attribute value that matches the
> current "page" value.  This might call for an attribute on the
> "form-bean" named "pageAttribute" or "pageProperty".
> "
> 
> I thought of that.   One problem with having "page" in 
> "form-property" is
> that you are restricting the "form-property" to the "page".  
> What if you
> want to use that "form-property" field in a different "page" for other
> functions of your site?  The same problem applys to the 
> current validator's
> "page" and "field"

Certainly.  You could easily find more complex needs that would make a simple 
declarative form not sufficient.  At that point, you should be considering a 
non-dynamic subclass.  It's impossible to satisfy everyone with a single solution.  
The goal is to find some solution that will make a considerable number of people 
mostly happy.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Unclear semantics on form use for "wizards"

[Karr, David]

At end.

> -Original Message-
> From: Craig R. McClanahan [mailto:craigmcc@;apache.org]
> Sent: Monday, November 11, 2002 3:02 PM
> 
> On Mon, 11 Nov 2002, Karr, David wrote:
> 
> > Date: Mon, 11 Nov 2002 12:22:44 -0800
> > From: "Karr, David" <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: RE: Unclear semantics on form use for "wizards"
> >
> > This may seem far out, but what if the "reset" 
> functionality could be
> > entirely specified in the "form-bean" element?
> 
> You could make a case that it already is :-).
> 
> If you use DynaActionForm or DynaActionValidatorForm, the 
> default reset()
> method has well-defined semantics already (including the fact 
> that it sets
> boolean properties to false).  In addition, it supports 
> setting the value
> to which most properties are set with the "initial" attribute on
> .  The only cases you typically need to 
> override reset() in
> this case are for mapped properties -- the initial expression 
> supports a
> subset of Java's array initializer syntax for array based properties:
> 
>   initial='{ "foo", "bar" }'/>
> 
> The missing link for a multi-page form is some way to tie 
> which page got
> submitted to the set of properties that live on that page 
> (and therefore
> need to be reset.

Clearly, the page number is the crux of the problem.  That's all I was
trying to address in that fantasy syntax I was suggesting.

What if each "form-property" element had an optional "page" attribute,
holding an integer value (or range)?  At "reset" time, the only
attributes that would be reset would be the ones without a "page"
attribute, and the ones with a "page" attribute value that matches the
current "page" value.  This might call for an attribute on the
"form-bean" named "pageAttribute" or "pageProperty".

--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

RE: Unclear semantics on form use for "wizards"

[Karr, David]

Well, there's the tradeoff.  If you have the logic in code, then you'll
likely need a subclass for each "instance".  I would think it would be
annoying to build almost all of a DynaActionForm in XML, then have to
associate it with a subclass for the "reset" functionality.  I believe,
in general, the "logic" involved here is relatively simple.  In most
cases, you would have a "test" element for each "page" of your wizard,
each of which would reset different fields.  As your form bean starts to
get larger, with more fields to reset, the value of even using
DynaActionForm by itself starts to decrease, and would point you to a
"static" form bean class.

> -Original Message-
> From: David Graham [mailto:dgraham1980@;hotmail.com]
> Sent: Monday, November 11, 2002 12:57 PM
> 
> Interesting, but then you're creating a programming language 
> in XML.  I 
> think this logic should be in code.
> 
> David
> 
> >From: "Karr, David" <[EMAIL PROTECTED]>
> >
> >This may seem far out, but what if the "reset" functionality 
> could be 
> >entirely specified in the "form-bean" element?
> >
> >For instance, the "reset" element could contain a set of 
> elements named 
> >"test", each of which would have attributes "field" and 
> "value".  The 
> >"test" element would have "field" subelements, which take a "name" 
> >attribute, and an optional "value" attribute.
> >
> >The "reset" and "test" elements would work like a "switch" 
> statement (or 
> >if-elseif).  It would "evaluate" each of the "test" 
> elements, comparing the 
> >value of the "field" (which has to be a "form-property" of 
> the form) with 
> >the "value".  If they are equal, then the encapsulated 
> "field" elements 
> >would all be "reset", either to a standard "zero" value for 
> each type, or 
> >to the optional "value" attribute of the "field" element.
> >
> >The names of these elements and attributes aren't important, but the 
> >structure is.  This solution would require no application-specific 
> >subclasses.

--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

RE: Unclear semantics on form use for "wizards"

[Karr, David]

This may seem far out, but what if the "reset" functionality could be entirely 
specified in the "form-bean" element?

For instance, the "reset" element could contain a set of elements named "test", each 
of which would have attributes "field" and "value".  The "test" element would have 
"field" subelements, which take a "name" attribute, and an optional "value" attribute.

The "reset" and "test" elements would work like a "switch" statement (or if-elseif).  
It would "evaluate" each of the "test" elements, comparing the value of the "field" 
(which has to be a "form-property" of the form) with the "value".  If they are equal, 
then the encapsulated "field" elements would all be "reset", either to a standard 
"zero" value for each type, or to the optional "value" attribute of the "field" 
element.

The names of these elements and attributes aren't important, but the structure is.  
This solution would require no application-specific subclasses.

> -Original Message-
> From: Jason Rosen [mailto:JRosen@;yvimail.com]
> Sent: Monday, November 11, 2002 12:05 PM
> 
> The reset() method lives in the ActionForm class.  In order 
> to have reset() evaluate what to do means overriding reset() 
> by subclassing ActionForm (or some child of ActionForm).  So 
> to have all these different reset() evaluations means having 
> different ActionForm subclasses.  
> 
> Then if you wanted to use a different ActionForm 
> implementation like DynaActionForm or DynaValidatorForm, you 
> start duplicating your reset() code around because Java 
> doesn't allow for multiple inheritance.  This is the mess I 
> started finding myself in - some of my Actions were using 
> DynaActionForms, some were using DyanValidatorForms, and some 
> were ActionForms but I needed similar reset() functionality 
> in all of them.  So the reset() code was getting hard to maintain. 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: FW: Struts 1.0.2, Nested 1.0 and Standard Tags 1.0.2

[Karr, David]

I'll provide some information at the end.  If you have any more
questions about this, please ask on the "struts-user" list.

> -Original Message-
> From: edgar [mailto:edgar@;blue-moose.net]
> Sent: Wednesday, November 06, 2002 8:20 AM
> 
> My apologies for not posting more information.  This was such a basic
> issue I assumed that someone would know about it.  The real 
> question is
> are people actively doing such things with the JSTL / Struts
> combination?
> 
> As you can see I have also modified some of the tags so I assumed
> someone would assume I botched them.  In this trace I have modified
> NestedWriteTag (the only change was to make it a subclass of my
> WriteTag, which I have heavily modified) but that has not 
> been executed.
> 
> A sample piece of code which fails.
> 
> 
>   
>   
>   
>   
>   
>   
>   
>   
>  name='<%=(String)
> request.getAttribute(myChoiceValue)%>'
>   labelName='<%=(String)
> request.getAttribute(myChoiceValue)%>'
>   />
>   
>   
> 

This is why showing the exact code sample is important.  Part of your
problem is obvious from this code sample.

The result of the "c:set" tag is not a JSP scripting variable, just a
scoped attribute.  That is, you can't reference "myChoiceValue" as a
scripting variable as you're doing.

This sort of thing would be easier if you used the Struts-EL library, as
you can do something like this:

  

Note that I changed the scoped attribute you're referencing for the
"labelName" attribute to what you probably meant, being "myChoiceLabel"
instead of "myChoiceValue" as you had.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Attribute "lowsrc" of "html:img" is non-compliant?

[Karr, David]

What is the "lowsrc" attribute of the "html:img" tag?  Is that supposed to render a 
lower-precision version of the image?  This attribute is not defined in the HTML 4.01 
spec.  I don't even find this in the description at  which 
often lists some attributes that it states are browser-dependent.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: DynaActionFormClass

[Karr, David]

> -Original Message-
> From: James Mitchell [mailto:jmitchtx@;telocity.com]
> Sent: Friday, November 01, 2002 1:07 PM
> 
> Why don't you just set the value in the action prior to 
> forwarding to your
> jsp?  You can easily do that using a value from the bundle.

I could be wrong, but his problem is not setting the properties dynamically, but 
configuring which properties are defined.  From a short glance at the class, I don't 
see an easy way to do that.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Building Struts

[Karr, David]

> -Original Message-
> From: Craig R. McClanahan [mailto:craigmcc@;apache.org]
> Sent: Thursday, October 31, 2002 11:08 AM
> 
> On Thu, 31 Oct 2002, Karr, David wrote:
> 
> > Date: Thu, 31 Oct 2002 10:11:38 -0800
> > From: "Karr, David" <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> > To: Struts Developers List <[EMAIL PROTECTED]>
> > Subject: RE: Building Struts
> >
> > I think it might be feasible to build a zip file containing all the
> > distributions that are needed, but not the Struts "build.properties"
> > file.  That would at least make part of the process easier.
> 
> But which versions would you include?  For example, I build Struts
> nightlies against the nightly builds of the commons packages (so it
> changes every day) -- but you'd want to use released versions 
> if you were
> building a formal Struts distribution.

The only purpose of this is a "quick start".  It would be good enough to
just contain the jar files from the released distributions.  I have a
feeling this shouldn't even be stored in the Struts distribution.

--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

RE: Building Struts

[Karr, David]

> -Original Message-
> From: David Graham [mailto:dgraham1980@;hotmail.com]
> Sent: Thursday, October 31, 2002 9:42 AM
> 
> This is my first time using Ant so I'm ignorant of all the 
> details.  I was 
> thinking we could zip up a build environment with all the 
> required jars in 
> it and a build.properties that was configured for that.  You 
> could modify 
> the build.properties if you wanted.  I didn't think any 
> changes would have 
> to happen to build.xml.

I think it might be feasible to build a zip file containing all the
distributions that are needed, but not the Struts "build.properties"
file.  That would at least make part of the process easier.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Accessing DynaActionForm objects in JSTL tags?

[Karr, David]

At end.

> -Original Message-
> From: Craig R. McClanahan [mailto:craigmcc@;apache.org]
> Sent: Tuesday, October 29, 2002 11:44 PM
> 
> > > "David" == David Karr  writes:
> > David> Presently JSTL tags can't easily access 
> DynaActionForm objects.  I haven't
> > David> used these much, but I would assume they're 
> reasonably widely used.  How
> > David> important do you think it is for JSTL tags to be 
> able to access properties
> > David> of these objects?
> >
> > As a proof of concept, I've verified that just by adding 
> the following to the
> > DynaActionForm class:
> >
> > public  Map   getMap() {
> > return (dynaValues);
> > }
> >
> > along with the following pre-Action code:
> >
> > dynaActionForm.set("foo", "alpha");
> > dynaActionForm.set("bar", "beta");
> >
> > The following JSP code:
> >
> >   / value="${dynabean.map.bar}"/>
> >
> > prints out "alpha/beta".
> 
> Therefore, I'm +1 to adding a getMap() method to 
> ActionDynaForm in Struts,
> to make it possible for DynaBeans to interoperate with *standard* JSTL
> tags (and, by the same token, with the standard capabilities 
> of JSP 2.0
> containers).  This won't be invisible, because the expression 
> will have to
> be different, but at least it will be possible.
> 
> However, I don't believe this change should be done in the underlying
> commons-beanutils APIs, because if you are using commons-beanutils
> already, you have transparent access (via BeanUtils and 
> PropertyUtils) out
> of the box, and need nothing more.  And there might well be 
> environments
> where DynaBean is implemented using techniques other than an 
> internal Map
> -- it is not fair to constrain those possible implementations 
> by requiring
> them to implement a potentially costly getMap() method.

This is one of the few times I've wondered whether multiple class
inheritance would be useful.  Oh, well.

Does anyone else want to chime in on this?

If I commit this, I plan on also adding something to the paragraphs in the
user guide, along with something in the Struts-EL top-level "package.html"
description.

With respect to the user guide information on DynaActionForm, I noticed that
section 4.2.1 is titled "DynaActionForm Classes", and 4.2.2 is titled
"Map-backed ActionForms".  Adding this new "map" information will require a
little clarification of those different "map" dimensions.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Accessing DynaActionForm objects in JSTL tags?

[Karr, David]

I'm asking this here first, to discuss the technical issues.  If it appears
to be feasible, I'll ask a similar question on the user list, and then
perhaps write a bug report.

Presently JSTL tags can't easily access DynaActionForm objects.  I haven't
used these much, but I would assume they're reasonably widely used.  How
important do you think it is for JSTL tags to be able to access properties
of these objects?

I believe there's a simple change we could make to DynaActionForm to allow
access to them from JSTL tags.  Since DynaActionForm doesn't present a
strict JavaBeans interface to its properties, you can't access them
normally.  However, the property values are stored in a HashMap in the
DynaActionForm.  The JSTL EL syntax can access hashmap entries.  So, if we
simply added a standard JavaBeans accessor for the HashMap, then the JSP
programmer could access these properties through a syntax like this:

  value='${actionForm.dyna["foo"]}'

for the "foo" property of the "actionForm" DynaBean.

Note that this now provides an additional access path to the DynaBean
properties.  I don't know if that creates a problem.

I have not completely analyzed the current code in DynaActionForm, wrt how
it currently retrieves and sets values, to see if there's anything
inconsistent with accessing the values as direct values from the HashMap.  I
have also not yet written a line of code to implement or test this.

The first question is can this be done?  Second, should it be done?  And
third, should it be done pre- or post-1.1?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [struts-el] HTML taglib

[Karr, David]

At end.

> -Original Message-
> From: Eddie Bush [mailto:ekbush@;swbell.net]
> Sent: Thursday, October 24, 2002 8:21 AM
> 
> David M. Karr wrote:
> 
> >>"Eddie" == Eddie Bush <[EMAIL PROTECTED]> writes:
> >Eddie> Ok - you asked for it.  Note that this error 
> *only* arises if I try to use the
> >Eddie> html tag (ELHtmlTag class).  It occurs during 
> page compilation -
> >
> >Eddie> not during execution.
> >
> >Eddie> index.jsp [-1:-1] java.lang.ExceptionInInitializerError
> >Eddie> at java.lang.Class.forName0(Native Method)
> >Eddie> at java.lang.Class.forName(Class.java:130)
> >
> >Eddie> Caused by: java.lang.NullPointerException
> >Eddie> at
> >Eddie> 
> org.apache.struts.util.MessageResources.getMessageResources(Me
> ssageResources.java:577)
> >
> >Eddie> at 
> org.apache.struts.taglib.html.HtmlTag.(HtmlTag.java:91)
> >
> >Ok, I've thought about this a bit, but I only have a minute 
> now.  I have a
> >couple of wild guesses to make.
> >
> >Are you using Tomcat, and just using the Manager to "reload" 
> your application,
> >after you added the references to "html-el:html"?  If so, do 
> a "remove" on the
> >application and reinstall it.  If that works, I think this might be a
> >bug/feature in Tomcat, wrt reflection, classloading, and 
> BeanInfo classes.
> >
> Impossible.  Recall (did I not mention this?  maybe I didn't ...) I 
> build an absolutely new app - very small - which includes 
> that one tag. 
>  If I use the struts-html set all is good.  If I use 
> struts-html-el it 
> ... pukes :-(
> 
> It's not a matter of running.  It's *compiling* (hasn't run at this 
> point) when the error occurrs.  I do run Tomcat though, but 
> this doesn't 
> happen as part of a reload.  This happens in Netbeans.  It 
> happens only 
> if I use ELHtmlTag.  It happens only during compilation.  
> I'll move the 
> app over to a webapp folder and see if it pukes under TC.

I'm not certain how compiling in Netbeans works.  I just use it as a
debugger and do a remote attach.

I believe your problem may be related to the fact that the BeanInfo class is
only loaded by reflection, and not by a direct reference.

In Netbeans, will it only compile and load the source files you explicitly
add to the project, or will it compile all the source files in a directory?
If it is somehow not compiling and loading the BeanInfo classes, you might
see this problem.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: [struts-el] HTML taglib

[Karr, David]

Tell us what happened, Eddie.

> -Original Message-
> From: Eddie Bush [mailto:ekbush@;swbell.net]
> Sent: Wednesday, October 23, 2002 1:41 PM
> To: Struts Developers List
> Subject: [struts-el] HTML taglib
> 
> 
> Is anyone else unable to compile JSPs which make use of the 
> struts-html-el:html tag?  I was changing some struts-html 
> stuff over to 
> use struts-html-el so I could just remove all references to 
> struts-html 
> (one less thing to refer to and I don't have to think about whether I 
> can use EL or not - just use it if I need to [later]), and started 
> noticing pages weren't compiling.  I tracked it down to (so far just) 
> the ELHtmlTag class.
> 
> I can provide the listing for the error if need be.
> 
> -- 
> Eddie Bush
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts-EL - BUILD FAILED

[Karr, David]

Dunno.  I've never tried to use relative paths myself.

> -Original Message-
> From: Eddie Bush [mailto:ekbush@;swbell.net]
> Sent: Monday, October 21, 2002 11:46 AM
> To: Struts Developers List
> Subject: Re: Struts-EL - BUILD FAILED
> 
> 
> Ok - exploring that path.  I need to know how the directory 
> structure is 
> on the machine nightlies run on (Craig's machine?).  Does he have the 
> different servlet APIs out there on the same level as the 
> Struts directory?
> 
> Either all paths have to be specified as relative or they must be 
> absolute (duh!).  Currently they're relative - but incorrect 
> (at least 
> in my updated checkout they are).  Should we stay relative and expect 
> there will be checkouts of the dependencies on the same level as the 
> "jakarta-struts" directory (ie jakarta-taglibs, etc), or move to 
> specifying those base directory names independently?
> 
> Any preference?  Which is "best"?  I'm thinking that the 
> least painful 
> approach would be to stick with relative paths and expect 
> people would 
> have the dependencies checked out on the "same level" as 
> struts.  Sound 
> good?
> 
> When I say "same level", I mean:
> 
> someDirectory/
> jakarta-struts/
> jakarta-taglibs/
> somethingElse/
> 
> they all share the same parent directory.
> 
> Karr, David wrote:
> 
> >You don't really need to build the JSTL, just use the binary package.
> >
> 
> -- 
> Eddie Bush
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

RE: [BUGS] CheckboxTag with value property

[Karr, David]

> -Original Message-
> From: Franco Caponi [mailto:franco.caponi@;tin.it]
> Sent: Tuesday, October 22, 2002 12:12 PM
> 
> There is a suspicious bug on the CheckboxTag. Infact i can 
> specify a value
> that is rendered as  attribute on the INPUT html tag, to overwrite the
> default "on" value.
> But if i specify a value, check box is not rendered correctly.
> 
> In the doStartTag method, to render the checkbox as checked, 
> are tested
> condition for "yes", "true" and "on" values, but not for the "value"
> instance variable.
> original code is:
> 
> if (checked.equalsIgnoreCase("true")
> || checked.equalsIgnoreCase("yes")
> || checked.equalsIgnoreCase("on"))
> results.append(" checked=\"checked\"");
> 
> I think that correct code is :
> 
> if (checked.equalsIgnoreCase("true")
> || checked.equalsIgnoreCase("yes")
> || checked.equalsIgnoreCase("on")
> || checked.equalsIgnoreCase(this.value))
> results.append(" checked=\"checked\"");

Look at the corresponding block of code in "MultiboxTag.java".  I have a
feeling there isn't a concise statement about this in the documentation, but
you use "checkbox" if you want to check for boolean values, and you use
"multibox" if you want to check for "symbols" (can't think of a better way
to say that).  The other difference is that "checkbox" compares against a
single value, and "multibox" checks against an array of values.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts-EL - BUILD FAILED

[Karr, David]

> -Original Message-
> From: Eddie Bush [mailto:ekbush@;swbell.net]
> Sent: Monday, October 21, 2002 12:17 PM

> So far as testing:  Wouldn't it be good of us to have a "struts-test" 
> app which we could exercise things in?  ... or "struts-regressions"? 
>  ... something we target our tests on specifically?  It wouldn't 
> necessarily be aimed at showing the users a functional 
> application as it 
> would be at testing struts - though there would undoubtedly 
> be some good 
> examples in it too.

Well, the "exercise-taglib" is supposed to do some of this.  Over time, I've
been adding several things to the "strutsel-exercise-taglib" that aren't in
the base app.  Every time I write an example that I realize isn't covered, I
add it to the app.  Some of these could be added to the base app, with
modifications.

There's also the unit tests, which are convenient in that they can be run
automatically (as opposed to the exercise app), but they test the tag code
directly, and bypass the TLD and the JSP compilation process.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts-EL - BUILD FAILED

[Karr, David]

> -Original Message-
> From: Eddie Bush [mailto:ekbush@;swbell.net]
> Sent: Monday, October 21, 2002 1:56 PM
> 
> Karr, David wrote:
> 
> >Perhaps it might be useful to add checks in the build script 
> for whether it
> >finds a "build.properties" file, and emits a warning if it 
> does not?  It's
> >something, at least.
> >
> Actually ... is there some reason the struts-el build script 
> chose not 
> to inherit property definitions?  Things like beanutils and 
> commons-logging should be inherited.  If we change servlet.jar to be 
> servlet23.jar then we don't have to worry about that one case 
> where we 
> don't want to inherit - and it should probably be 
> servlet23.jar anyway 
> for consistency with other things.

Because when I first wrote it, it was outside of the Struts distribution.  I
have no qualms with making any changes that will make it more convenient to
build.

> Or am I incorrect in believing that inheritAll="false" (in the main 
> script) is the thing causing the need for redefinition?

Dunno.

--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

RE: Struts-EL - BUILD FAILED

[Karr, David]

You don't really need to build the JSTL, just use the binary package.

> -Original Message-
> From: Eddie Bush [mailto:ekbush@;swbell.net]
> Sent: Monday, October 21, 2002 11:21 AM
> To: Struts Developers List
> Subject: Re: Struts-EL - BUILD FAILED
> 
> 
> It appears to be using incorrect relative paths to reference 
> dependencies.  I'm trying to build the jstl right now - 
> checked it out 
> etc - and I'm trying to update the paths to be "more 
> correct".  I don't 
> care much for the way the jstl build is setup.  It basically 
> requires a 
> full taglibs checkout.  Maybe that's intentional, but I'd 
> think each of 
> the taglibs would have more independent build scripts...
> 
> Karr, David wrote:
> 
> >>-Original Message-
> >>From: Eddie Bush [mailto:ekbush@;swbell.net]
> >>Sent: Monday, October 21, 2002 10:55 AM
> >>To: Struts Developers List
> >>Subject: Struts-EL - BUILD FAILED
> >>
> >>The build script for struts-el seems to not be working for me.  I'm 
> >>fixing it right now.  Anyone else experiencing difficulties?
> >>
> >
> >I haven't updated in a few days, but I haven't seen any 
> problems with my
> >local build.  What is happening?
> >
> 
> -- 
> Eddie Bush
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

RE: Struts-EL - BUILD FAILED

[Karr, David]

Again, you don't need to build the JSTL for this.  The top-level properties
file should have "jstl.jar" and "jstl-standard.jar" entries, pointing into
the JSTL binary distribution.

Unfortunately, I don't have the latest source here at work.  If you haven't
gotten through this by the time I get home, I'll check my source.

> -Original Message-
> From: Eddie Bush [mailto:ekbush@;swbell.net]
> Sent: Monday, October 21, 2002 11:27 AM
> To: Struts Developers List
> Subject: Re: Struts-EL - BUILD FAILED
> 
> 
> David - where does it dump out the JARs for the standard taglib?  Do 
> they really go in "Destination JAR for tag library", or are my 
> properties maybe not configured well?  The build went fine (for the 
> standard taglib), but I sure have some odd directory names ...
> 
> Karr, David wrote:
> 
> >>-Original Message-
> >>From: Eddie Bush [mailto:ekbush@;swbell.net]
> >>Sent: Monday, October 21, 2002 10:55 AM
> >>To: Struts Developers List
> >>Subject: Struts-EL - BUILD FAILED
> >>
> >>The build script for struts-el seems to not be working for me.  I'm 
> >>fixing it right now.  Anyone else experiencing difficulties?
> >>
> >
> >I haven't updated in a few days, but I haven't seen any 
> problems with my
> >local build.  What is happening?
> >
> 
> -- 
> Eddie Bush
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

RE: Struts-EL - BUILD FAILED

[Karr, David]

> Solutions:
> 1. Comment out those 2 lines so as not to cause confusion.

I guess that would make it so that the default build doesn't build
struts-el.  Craig was trying to ensure that it was built in the default
build.  I don't know whether this matters.

> 2. Leave them 'as is' and add comments 'in order to build 
> struts-el, you
> must create your own build.properties file there' as well as 
> here.  For,
> without it, ${user.home} is not picked up and consequently
> 
>   
> 
> points to nothing, so your base properties file is useless.

Perhaps it might be useful to add checks in the build script for whether it
finds a "build.properties" file, and emits a warning if it does not?  It's
something, at least.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts-EL - BUILD FAILED

[Karr, David]

> -Original Message-
> From: Eddie Bush [mailto:ekbush@;swbell.net]
> Sent: Monday, October 21, 2002 10:55 AM
> To: Struts Developers List
> Subject: Struts-EL - BUILD FAILED
> 
> The build script for struts-el seems to not be working for me.  I'm 
> fixing it right now.  Anyone else experiencing difficulties?

I haven't updated in a few days, but I haven't seen any problems with my
local build.  What is happening?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Suggestions for placement of Struts-EL information in the user gu ide?

[Karr, David]

Ok, I'll proceed with writing those.

Will there be a straightforward (even if somewhat messy) way for me to
generate a link from these pages to the package descriptions for the base
library?  That is, in my "html-el" package description, I would like to see
a link that would go directly to the package description for the "html"
package.  If in the final documentation, the "html" directory is in the same
directory as the "html-el" directory, then that will probably work.

I believe that the nature of this library as a simple "integration" of two
complex pieces implies that the unique information in the package
descriptions should be relatively short, with several usage examples, but
with a link to the package description for the base library.  It would have
been nice to also have a link to an HTML page that directly shows
documentation for the JSTL, but I guess the best we can do is point them to
the PDF specification download.

> -Original Message-
> From: Ted Husted [mailto:husted@;apache.org]
> Sent: Friday, October 18, 2002 7:15 AM
> To: Struts Developers List
> Subject: Re: Suggestions for placement of Struts-EL information in the
> user gu ide?
> 
> 
> If you can put the high-level usuage documentation 
> ("narrative") in a package.html for each of the taglibs, 
> following the example of the other taglibs, I'll can sort out 
> the mechanics of getting the package description, 
> Javadoc, and API guide into the documentation/website (somehow).
> 
> I'm very glad you were able to put this library together, 
> David. I'm sure it will of great use to a great many 
> people =:o) 
> 
> -Ted.
> 
> 10/18/2002 10:02:39 AM, [EMAIL PROTECTED] (David M. Karr) wrote:
> >Yes, the API part is automatic, for the "struts-*.xml" files 
> in the main Struts
> >distribution, which also generates the TLD files.  The 
> "struts-*-el.xml" files
> >for Struts-EL are in "contrib/struts-el".  How do we 
> automatically generate the
> >API documentation for Struts-EL so it is inserted into the 
> user guide in the
> >main distribution?
> >
> >Similarly, we'll have to figure out what to do about the 
> javadoc for Struts-EL.
> >
> >Ted> So, for the narrative you mentioned, follow the 
> example of the other package.html files 
> >Ted> (taglib/bean/package.html), and it will be compiled 
> into the JavaDocs. 
> >
> >Ted> Once that is done, I can setup the rest of the 
> Struts-EL Developer guide, if you like. 
> >
> >That would be fine.
> >
> >Ted> Pzst 1.1, I'd like to try and do more of the 
> "Developer Guide" kid of thing, and link more into the 
> JavaDocs. 
> >Ted> Right now, we're getting into a lot of dual 
> maintenance. But first things first.
> >
> >I'm not sure what you mean here.
> >
> >-- 
> >===
> >David M. Karr  ; Java/J2EE/XML/Unix/C++
> >[EMAIL PROTECTED]
> >
> >
> >--
> >To unsubscribe, e-mail:   

>For additional commands, e-mail:

>
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Tiles Refactorings for 1.1 compatability

[Karr, David]

> -Original Message-
> From: Eddie Bush [mailto:ekbush@;swbell.net]
> Sent: Thursday, October 17, 2002 9:10 AM
> To: Struts Developers List
> Subject: Re: Tiles Refactorings for 1.1 compatability
> 
> Ted Husted wrote:
> 
> >I posted a starter version of the roadmap so we'd have 
> something to patch :0)
> >
> >http://jakarta.apache.org/struts/status.html
> >
> >-Ted.
> >

Just so I understand, is there a desire to not have Struts-EL in the 1.1
release?  I know this document is extremely preliminary, but the omission of
it from the phrase about contrib libraries makes me think that's the intent.
If that's the case, I take no offense, I just want to be clear on our
direction.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Suggestions for placement of Struts-EL information in the user guide?

[Karr, David]

I'm planning on putting some information about Struts-EL into the user
guide.  I haven't delved into that yet.  Are there any guidelines I should
know about?  Is there an obvious place in the user guide I should put this?
It might be a section in the "Building View Components" chapter, but I'm
wondering if it should be outside of there.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Tiles Refactorings for 1.1 compatability

[Karr, David]

> -Original Message-
> From: Eddie Bush [mailto:ekbush@;swbell.net]
> Sent: Thursday, October 17, 2002 11:29 AM
> To: Struts Developers List
> Subject: Re: Tiles Refactorings for 1.1 compatability
> 
> Byrne, Steven wrote:
> 
> >Here's the draft roadmap  that I wrote up.

> >Struts 1.2   January 2003 [duration: 2 months? ]  
> >  * tiles JSTL aware
> >
> ? What is the problem with Tiles' JSTL awareness?

At the least, I would assume this refers to the fact that there is no
"tiles-el" library yet.  If that's all that means, I don't expect any
problem with building a "tiles-el" sublibrary by the January timeframe (not
to mention "nested-el", or any other existing "sub-libraries").

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Tiles Refactorings for 1.1 compatability

[Karr, David]

> -Original Message-
> From: Byrne, Steven [mailto:sbyrne@;dorado.com]
> Sent: Thursday, October 17, 2002 11:56 AM
> To: Struts Developers List
> Subject: RE: Tiles Refactorings for 1.1 compatability
> 
> 
> I was given to understand that Struts-el needed Servlet 2.3, and so
> that's why I suggested having it in 1.2.   But my main purpose was to
> create a common definition of what was going to be in each 
> release (and
> have it track as things change), so it should reflect the 
> shared belief
> of the developers. 
> 
> David Karr -- care to chime in on whether Struts-el needs Servlet
> 2.3/JSP 1.2?

Yes, Struts-EL needs the JSTL, which needs Servlet 2.3.  Thus, Struts-EL
can't be "integrated" into Struts until the release where we require Servlet
2.3.  However, there's nothing wrong with it being in the "contrib" section
of the "pre-required-Servlet 2.3 release", even if the jar file is
distributed next to the "struts.jar" file in the binary release.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Tiles Refactorings for 1.1 compatability

[Karr, David]

I guess I don't know what that means.  The "David" obviously refers to David
Geary, not me, but I don't know what the "JSTL" reference is for.  I would
have assumed they would first build something that combines the best of
"regions" and "tiles", without incorporating the JSTL EL engine, and that
something like "regionstiles-el" would be implemented separately.

> -Original Message-
> From: Byrne, Steven [mailto:sbyrne@;dorado.com]
> Sent: Thursday, October 17, 2002 12:26 PM
> To: Struts Developers List
> Subject: RE: Tiles Refactorings for 1.1 compatability
> 
> What I meant was essentially tiles-el, which is what I thought this
> message from Cedric was referring to:
> 
>   Martin Cooper wrote:
> 
>   >
>   >Meanwhile, David Geary, who was the original author of the template
> library,
>   >went on to develop the Regions library, which he describes in his
> book,
>   >"Advanced JavaServer Pages". At one point, there was some 
> discussion
> of
>   >David and Cedric working together to combine the best of 
> Regions and
> Tiles,
>   >but as far as I'm aware, nothing came of that.
>   >
>   We, David and me, are in contact.  We should soon start 
> working on a 
>   common proposal for a next major version of JSTL.
> 
> > -Original Message-
> > From: Karr, David [mailto:david.karr@;attws.com]
> > Sent: Thursday, October 17, 2002 11:50 AM
> > To: 'Struts Developers List'
> > Subject: RE: Tiles Refactorings for 1.1 compatability
> > 
> > 
> > > -Original Message-
> > > From: Eddie Bush [mailto:ekbush@;swbell.net]
> > > Sent: Thursday, October 17, 2002 11:29 AM
> > > To: Struts Developers List
> > > Subject: Re: Tiles Refactorings for 1.1 compatability
> > > 
> > > Byrne, Steven wrote:
> > > 
> > > >Here's the draft roadmap  that I wrote up.
> > 
> > > >Struts 1.2   January 2003 [duration: 2 months? ]  
> > > >  * tiles JSTL aware
> > > >
> > > ? What is the problem with Tiles' JSTL awareness?
> > 
> > At the least, I would assume this refers to the fact that 
> there is no
> > "tiles-el" library yet.  If that's all that means, I don't 
> expect any
> > problem with building a "tiles-el" sublibrary by the January 
> > timeframe (not
> > to mention "nested-el", or any other existing "sub-libraries").
> > 
> > --
> > To unsubscribe, e-mail:   
> > <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
> > For additional commands, e-mail: 
> > <mailto:struts-dev-help@;jakarta.apache.org>
> > 
> > 
> 
> --
> To unsubscribe, e-mail:   
<mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>

RE: [VOTE] How should Tiles be refactored?

[Karr, David]

Nope, I was just in a time warp.  EOT.

> -Original Message-
> From: David Derry [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 16, 2002 4:49 PM
> To: Struts Developers List
> Subject: Re: [VOTE] How should Tiles be refactored?
> 
> 
> Having a tough week David?
> 
> - Original Message - 
> From: "Karr, David" <[EMAIL PROTECTED]>
> 
> 
> > Oh.  Sheesh, it's not even Thursday.
> > 
> > > -Original Message-
> > > From: James Mitchell [mailto:[EMAIL PROTECTED]]
> > > 
> > > 
> > > You sure about that?  ;)
> > > 
> > > 
> > > 
> > > 
> > > > -Original Message-
> > > > From: Karr, David [mailto:[EMAIL PROTECTED]]
> > > >
> > > >
> > > > Could we have a ruling on this, please?  As far as I can 
> > > tell, it's still
> > > > Thursday, in all parts of the world.
> > > >
> > > > ;)
> > > >
> > > > > -Original Message-
> > > > > From: James Mitchell [mailto:[EMAIL PROTECTED]]
> > > > >
> > > > > Well, I know I'm not a committer and all , but
> > > > > for what its
> > > > > worth...
> > > > >
> > > > >
> > > > >  [ x ] I DON'T think we should allow naked pictures of the
> > > > > committers on the
> > > > >main pageDOH  HAHAHAHA
> > > > >
> > 
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

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

RE: [VOTE] How should Tiles be refactored?

[Karr, David]

Oh.  Sheesh, it's not even Thursday.

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 16, 2002 3:22 PM
> To: Struts Developers List
> Subject: RE: [VOTE] How should Tiles be refactored?
> 
> 
> You sure about that?  ;)
> 
> James Mitchell
> Software Engineer/Struts Evangelist
> http://www.open-tools.org
> 
> 
> 
> 
> > -Original Message-
> > From: Karr, David [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, October 16, 2002 6:18 PM
> > To: 'Struts Developers List'
> > Subject: RE: [VOTE] How should Tiles be refactored?
> >
> >
> > Could we have a ruling on this, please?  As far as I can 
> tell, it's still
> > Thursday, in all parts of the world.
> >
> > ;)
> >
> > > -Original Message-
> > > From: James Mitchell [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, October 16, 2002 3:14 PM
> > > To: Struts Developers List
> > > Subject: RE: [VOTE] How should Tiles be refactored?
> > >
> > >
> > > Well, I know I'm not a committer and all , but
> > > for what its
> > > worth...
> > >
> > >
> > >  [   ] I want Tiles to have an independent (non-shared) 
> configuration
> > > for each module.  No future change is required IMHO.
> > >
> > >  [   ] I want Tiles to have an independent (non-shared) 
> configuration
> > >for each module.  I think we should revisit this
> > > decision after 1.1F.
> > >
> > >  [ x ] I DON'T think we should allow naked pictures of the
> > > committers on the
> > >main pageDOH  HAHAHAHA
> > >
> > >  [   ] I want tiles to have a (possibly) dependent (shared)
> > > configuration
> > >for each module in the 1.1F release.
> > >  - modules would chain lookup from the current
> > > module to the
> > >default module (or something else)
> > >  - could be turned on/off by a switch which
> > > defaults to off
> > >
> > >  [   ] I want tiles to have a different configuration (Elaborate).
> > >
> > >
> > >
> > > James "...and you thought I was serious for a sec huh?" Mitchell
> > > Software Engineer/Struts Evangelist
> > > http://www.open-tools.org
> > >
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> > > > Sent: Wednesday, October 16, 2002 3:49 PM
> > > > To: Struts Developers List
> > > > Subject: [VOTE] How should Tiles be refactored?
> > > >
> > > >
> > > > There's been a lot of discussion on how 1.1 final 
> should look, and I
> > > > think it's good to have such discussions.  We (commiters
> > > and non), being
> > > > tasked with implementing everything that "is" Struts 1.1,
> > > need to have a
> > > > clear picture of exactly what that means.  Now, when it
> > > gets right now
> > > > to brass tacks, it's irrelevant to me which way we go on
> > > this (right now
> > > > - I think my position is well-known).  Something has to be
> > > done though.
> > > >  Progress needs to be made, and to make progress we must
> > > have a clear
> > > > understanding of how we should proceed.
> > > >
> > > > Tiles will not work as expected with modules and that needs
> > > to be fixed.
> > > >  What form should it take?  I'm tired of speculation.  
> I'm happy to
> > > > study Tiles and determine what needs to change, but I will
> > > not take the
> > > > decision of how to implement it upon myself.
> > > >
> > > > Please bear in mind that we have folks waiting on 1.1F very
> > > anxiously
> > > > and that any behavior can be rectified in a later release.
> > > Also note
> > > > that refactoring to support a dependent configuration 
> would not undo
> > > > (that I can see) any change which would be required to make the
> > > > configurations entirely independent.  That is a 
> necessary step.  The
> > > > only question is if/when the next step of allowing 
> sharing across
> > > > modules should occur.
> > > >
> > > > Cast your vote.
> > > >
> &

RE: [VOTE] How should Tiles be refactored?

[Karr, David]

Could we have a ruling on this, please?  As far as I can tell, it's still
Thursday, in all parts of the world.

;)

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 16, 2002 3:14 PM
> To: Struts Developers List
> Subject: RE: [VOTE] How should Tiles be refactored?
> 
> 
> Well, I know I'm not a committer and all , but 
> for what its
> worth...
> 
> 
>  [   ] I want Tiles to have an independent (non-shared) configuration
> for each module.  No future change is required IMHO.
> 
>  [   ] I want Tiles to have an independent (non-shared) configuration
>for each module.  I think we should revisit this 
> decision after 1.1F.
> 
>  [ x ] I DON'T think we should allow naked pictures of the 
> committers on the
>main pageDOH  HAHAHAHA
> 
>  [   ] I want tiles to have a (possibly) dependent (shared) 
> configuration
>for each module in the 1.1F release.
>  - modules would chain lookup from the current 
> module to the
>default module (or something else)
>  - could be turned on/off by a switch which 
> defaults to off
> 
>  [   ] I want tiles to have a different configuration (Elaborate).
> 
> 
> 
> James "...and you thought I was serious for a sec huh?" Mitchell
> Software Engineer/Struts Evangelist
> http://www.open-tools.org
> 
> 
> 
> 
> > -Original Message-
> > From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, October 16, 2002 3:49 PM
> > To: Struts Developers List
> > Subject: [VOTE] How should Tiles be refactored?
> >
> >
> > There's been a lot of discussion on how 1.1 final should look, and I
> > think it's good to have such discussions.  We (commiters 
> and non), being
> > tasked with implementing everything that "is" Struts 1.1, 
> need to have a
> > clear picture of exactly what that means.  Now, when it 
> gets right now
> > to brass tacks, it's irrelevant to me which way we go on 
> this (right now
> > - I think my position is well-known).  Something has to be 
> done though.
> >  Progress needs to be made, and to make progress we must 
> have a clear
> > understanding of how we should proceed.
> >
> > Tiles will not work as expected with modules and that needs 
> to be fixed.
> >  What form should it take?  I'm tired of speculation.  I'm happy to
> > study Tiles and determine what needs to change, but I will 
> not take the
> > decision of how to implement it upon myself.
> >
> > Please bear in mind that we have folks waiting on 1.1F very 
> anxiously
> > and that any behavior can be rectified in a later release.  
> Also note
> > that refactoring to support a dependent configuration would not undo
> > (that I can see) any change which would be required to make the
> > configurations entirely independent.  That is a necessary step.  The
> > only question is if/when the next step of allowing sharing across
> > modules should occur.
> >
> > Cast your vote.
> >
> > [   ] I want Tiles to have an independent (non-shared) 
> configuration
> > for each module.  No future change is required IMHO.
> > [   ] I want Tiles to have an independent (non-shared) 
> configuration
> > for each module.  I think we should revisit this decision 
> after 1.1F.
> > [   ] I want tiles to have a (possibly) dependent (shared)
> > configuration for each module in the 1.1F release.
> > - modules would chain lookup from the current 
> module to the
> > default module (or something else)
> > - could be turned on/off by a switch which 
> defaults to off
> > [   ] I want tiles to have a different configuration 
> (Elaborate).
> >
> > --
> > Eddie Bush
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> 
> For additional commands, e-mail: 




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Constructing Binary Distribution

[Karr, David]

Sorry if I missed one of your issues.  I remember someone asking about
whether the "jstl.jar" value had to be empty or nonexistent.  I thought it
was you.  If you ensure that "jstl.jar" is not defined, it will not build
the struts-el distribution.

> -Original Message-
> From: Robert Leland [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 16, 2002 8:32 AM
> To: Struts Developers List
> Subject: RE:Constructing Binary Distribution
> 
> 
>  > Anyone else having trouble running the dist target?
> 
>  > Mine is failing on the struts-el stuff (not compile error, 
> but ant task
>  > errors due to path settings and such), and I am working 
> through it, but
>  > wondering if I missed an email somewhere ?!?!?!?
> 
> It's a bug. I emailed the list but David didn't respond.
> If the jstl.jar variable is not defined the struts-el stuff
> is supposed to be skilled. At home I use Tomcat 3.X,
> so that is where I hit the problem.
> 
> At work I use tomcat 4.X and so I have no problem
> compiling the latest distribution as of 11:30 Eastern time
> 
> -Rob
> 
> 
> --
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: LabelTag

[Karr, David]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 15, 2002 10:32 AM
> To: Struts Developers List
> Subject: RE: LabelTag

> backwards compatibility in this way).  The W3C spec for  is the
> about the worst example of a spec definition that I've never 
> seen, because
> many of the specified elements are relevant for only some of the input
> subtypes, and the relationships are not always clearly 
> defined. We'd just
> end up with a single tag that had 100 or so optional 
> attirbutes, with no
> clue to the poor user about which ones are relevant for which uses.

For an example of this, consider type "hidden".  The HTML 4.01 spec defines
several attributes of the "input" element which really are only relevant to
elements which take visible space on the screen.  The specification doesn't
specify (somewhat understandably) that concrete "subclasses" of input
shouldn't use certain attributes, so as a result the Struts implementation
of the "html:hidden" tag implements several attributes that are only there
to provide compliance to the specification, but no useful value.  If the
specification allocated responsibilities to these elements more rationally,
the "input" element would have been divided into more than one real element.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/tiles UseAttributeTag.java

[Karr, David]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 07, 2002 8:44 AM
> To: [EMAIL PROTECTED]
> Subject: cvs commit:
> jakarta-struts/src/share/org/apache/struts/taglib/tiles
> UseAttributeTag.java
> 
>   Log:
>   Correct a bug where the property "id" is not set properly 
> when the tag is reused.

>  public int doStartTag() throws JspException
>{
>   +  // Do a local copy of id
>   +String id=this.id;
>if( id==null )
>  id=attributeName;

Would you mind elaborating on this a bit, Cedric?  Why do you need to to do
this?

I also noticed that the "release()" method is resetting the "id" field,
apparently due to a bug in TagSupport?  Is this really a bug in the base JSP
api?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Nested taglib with EL?

[Karr, David]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 9:30 AM
> To: Struts Developers List
> Subject: Re: Nested taglib with EL?

> Personally, I'd suggest not trying to support "partial 
> references" in the
> struts-el library similar to what the nested taglib can do.  
> We would have
> to define the semantics of this ourselves, which is unlikely to be
> compatible with whatever does finally happen on the 
> standardization front.

If you're referring to what I think you are, I would unfortunately agree.  I
started down this path when I started thinking about Struts-EL, when I
thought about how I could "replace" the "name/property" system with pure EL
references.  I discovered that the JSTL support library allowed me to
evaluate expressions in a "context" which I could somewhat define.  However,
I ultimately concluded that this was impractical, and the best thing that
Struts-EL could do was simply to evaluate individual attribute values
through the EL engine, and not modify the semantics of the underlying tag.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Applying patches

[Karr, David]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 9:24 AM
> To: Struts Developers List; [EMAIL PROTECTED]
> Subject: Re: Applying patches

> In addition, I want committers to start adding unit tests 
> that will help
> avoid regressions from later changes in the same code area.  This is
> something that we've got down pretty well in the Commons 
> packages (nearly
> every patch to fix something comes with a new or updated unit test to
> validate the updated behavior.  This gets pretty tricky in 
> some parts of
> Struts, but is something we've been quite woefully lacking in, and it
> increases the risk of applying patches because we don't know 
> what will get
> broken until someone tries the updated version out in their apps.

Just for information (Craig knows about most of this), the unit tests that I
built for the Struts-EL tags go a little further than the existing tag unit
tests in Struts, but I still have more to do, in my mind.  These go so far
as actually comparing the HTML output from the tag with what we expect,
using Cactus, HttpUnit, JTidy, and Xalan (although figuring out what we
"expect" is somewhat annoying in some cases).  I believe we should
eventually move the Struts tag unit tests in this direction, and this is
something I have on my internal task list, although I don't know when I'll
get to it.

In addition, it might be useful to modify the "exercise-taglib" so that the
demonstrated tags use more of the attributes supported by those tags, even
the ones which won't produce any obvious functionality in the application.

These two things just cover testing the tags themselves, and don't address
the MVC features of the framework.  It would be a worthwhile project for
someone to design an infrastructure for building regression tests for more
parts of the framework, especially outside of the tag library.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: HTML-EL

[Karr, David]

> -Original Message-
> From: V. Cekvenich [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 02, 2002 2:22 PM
> To: [EMAIL PROTECTED]
> Subject: HTML-EL
> 
> 
> I am lazy, so feel free not to answer since I can loook it up 
> in source.
> It is easier to ask I say as a "newbie":
> 
> Did the html-el tag extend html tag so changes in html tag are 
> propogated or did it fork?

Every tag class in the Struts-EL library is a subclass of the Struts tag.
The TLD has to be separate, as they haven't designed inheritance into the
TLD yet :) .

All of the tag classes are very similar, in that the "doStartTag()" method
calls a method called "evaluateExpressions()", and then calls
"super.doStartTag()".  The "evaluateExpressions()" method processes all the
string-valued attributes through the EL, and then calls the attribute
setters.  If you looked at all the tag classes, you'd start to wonder where
all the code is :) .  All Struts-EL does is replace the attribute value
evaluation process.

Otherwise, the subclasses use the base classes for all functionality.

The only thing that I can't automatically track (without changing the code
and TLD) is if the base tag adds or removes attributes, or changes their
types.  I seriously considered writing a code generator to generate the
library, to avoid this problem, but I decided it wasn't worth it.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Nested taglib with EL?

[Karr, David]

> -Original Message-
> From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 02, 2002 11:04 AM
> To: Struts Developers List
> Subject: Re: Nested taglib with EL?
> 
> I don't believe it will - that functionality (as I recall 
> David having 
> said) is entirely replaced by the JSTL - use that instead ;-)
> 
> Brandon Goodin wrote:
> 
> >Does anyone know if the Nested taglib will implement el?
> >

Uh, I don't believe I said that.  You could easily build deeply nested
references in the EL, but the nested tag library provides the ability to
avoid those deeply nested references.  I could implement a "nested-el"
library (and I probably will, just for completeness), but the implementation
would simply allow using the EL to evaluate the attribute values, it
wouldn't really be changing the functionality of the library.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Nested taglib with EL?

[Karr, David]

> -Original Message-
> From: Brandon Goodin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 02, 2002 10:39 AM
> To: Struts Developers List
> Subject: Nested taglib with EL?
> 
> 
> Does anyone know if the Nested taglib will implement el?

If you mean whether it's covered in the Struts-EL library, my initial
implementation didn't cover the nested taglib.  I don't expect it to be very
difficult.  It's on the task list in my mind.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: cvs commit: jakarta-struts/contrib/struts-el build.xml

[Karr, David]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, October 02, 2002 8:12 AM
> To: Struts Developers List
> Subject: Re: cvs commit: jakarta-struts/contrib/struts-el build.xml
> 
> On 1 Oct 2002, David M. Karr wrote:
> 
> > >> Also, if Struts-EL is being built by default, what 
> will happen if someone tries
> > >> to build it with a 2.2 servlet.jar?
> >
> > Craig> Good point ... it should probably be made 
> conditional based on the
> > Craig> presence of Servlet 2.3 (and the JSTL jars, for 
> that matter).
> >
> > Correct me if I'm wrong, but doesn't this mean that it 
> can't be provided in the
> > nightly build, unless we do both a Servlet 2.2 and Servlet 
> 2.3 build?
> 
> The nightly builds are created against Servlet 2.3 already.  If you
> download and use the nightly build in a Servlet 2.2 
> environment, you can't
> use the struts-el stuff, but it doesn't change anything else that is
> created -- so I don't see a need to create two different versions.
> 
> > I've tested a change to the top-level build.xml to only 
> build it if "jstl.jar"
> > is set (and I put my "jstl.jar" setting in my top-level 
> build.properties file),
> > but I didn't try to do anything with a Servlet 2.2 build.
> >
> > I've got my announcement note written, and ready to send, 
> but I have a feeling
> > I may have to delay/change it, based on this.
> 
> If you want to go ahead and check in the conditional change to the
> "dist.contrib" target, that would be great.

I'll do that, but I won't be able to commit it until tonight.  I don't have
my Jakarta CVS environment set up here at work (and I hesitate trying to
manage more than one CVSROOT on one box).

On the nightly build, I noticed that the build did eventually complete,
including the struts-el.jar, so I assume the issue with the Catalina ant
tasks was worked around?  I committed the change to my build.xml to remove
those soon after I saw the build failure this morning.

If this morning's nightly build (I'll just have to get used to that not
sounding right :) ) is a go, I'll send in my announcement note in a few
minutes.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts-EL: Finished with copyright header and javadoc

[Karr, David]

> -Original Message-
> From: Martin Cooper [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 01, 2002 4:05 PM
> To: 'Struts Developers List'
> Subject: RE: Struts-EL: Finished with copyright header and javadoc
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, September 30, 2002 10:56 PM
> > To: [EMAIL PROTECTED]
> > Subject: Struts-EL: Finished with copyright header and javadoc
> > 
> > In several tag classes in the HTML library, I have some 
> > attribute evaluations
> > commented out, as I've discovered that these are attributes 
> > which the HTML 4.01
> > spec defines, but which are not covered in the current Struts 
> > tag, either
> > because their TLD doesn't specify them, or the Struts tag 
> > doesn't properly emit
> > them.  I've noticed some of these have had bugs reported 
> > against them (some by
> > me), but probably not all.  One thing I want to do in the 
> > very near future is
> > make sure all of these are logged (and maybe even fix them :) ).
> 
> Is there an easy way to find these comments? A Bugzilla report listing
> what's missing would be very helpful. I've wanted to get this 
> cleaned up,
> but haven't had the time to go through and check all the tags myself.

If you want a head start, you can grep for "//.*evalAttr" in ".java" files
in the "contrib/struts-el" tree.

I was planning on rechecking each one that I found (checking the spec, the
tld, and the tag code), just to make sure, before I submitted bug reports
(for each tag), but it doesn't matter who does that.  If you have time now,
have at it.  Otherwise, that was going to be on my evening work task list,
after I write and submit the announcement tonight, assuming I'm granted time
by my social director :) .

> > Is there some point where it would be worthwhile for me to write an
> > "[ANNOUNCEMENT]" note in struts-user about Struts-EL, or 
> > should that wait until
> > we get to a Struts release (1.1-b3, or 1.1)?
> 
> Feel free to make an announcement whenever you are 
> comfortable doing so. It
> would be a good idea to mention the earliest nightly build in 
> which people
> should expect the tags to be available.

I submitted my last changes (so far) yesterday evening.  I assume then, that
indicating the nightly build of 9/30 would be correct?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts-EL: Finished with copyright header and javadoc

[Karr, David]

> -Original Message-
> From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 01, 2002 10:58 AM
> To: Struts Developers List
> Subject: Re: Struts-EL: Finished with copyright header and javadoc
> 
> 
> Karr, David wrote:
> 
> >Or even better, create a file "$HOME/.cvsrc" that sets your "always"
> >options, that might look like this (make sure you understand 
> all of these
> >options before you store this):
> >
> >--
> >cvs -r
> >update -dP
> >checkout -P
> >diff -c
> >--
> >
> Shouldn't that be diff -u?

I'd say that's one of those "personal preference" issues.  The "-c" option
does a "context diff", and "-u" does a "unified diff".  Either one is better
than the default, for human consumption.

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

RE: Struts-EL: Finished with copyright header and javadoc

[Karr, David]

> -Original Message-
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 01, 2002 10:36 AM
> To: Struts Developers List
> Subject: Re: Struts-EL: Finished with copyright header and javadoc
> 
> 
> Use the following command to pick up everything new that's 
> checked in (as
> well as pruning empty directories):
> 
>   cvs update -dP

Or even better, create a file "$HOME/.cvsrc" that sets your "always"
options, that might look like this (make sure you understand all of these
options before you store this):

--
cvs -r
update -dP
checkout -P
diff -c
--

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts-EL: Finished with copyright header and javadoc

[Karr, David]

> -Original Message-
> From: Eddie Bush [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, October 01, 2002 7:08 AM
> To: Struts Developers List
> Subject: Re: Struts-EL: Finished with copyright header and javadoc
> 
> Announce it as soon as it as committed so people (like me) 
> know they can 
> just update CVS to have the latest copy.

It should update and build fine from CVS right now.  The sample application
and unit tests appear to work (although I've only run the unit tests with TC
4.0.4 and the sample app with TC 4.1.0).  I'll write an announcement when I
get home tonight, which will include some elements from the top-level
"README" file.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Unit testing taglibs?

[Karr, David]

> -Original Message-
> From: Davor Cengija [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 25, 2002 12:34 AM
> To: Struts Developers List
> Subject: Unit testing taglibs?
> 
> How to unit-test taglibs, possibly without servlet container?
> 
> I'm writing wml-related taglib for struts and my code is craving for
> some unit-tests. I found tagunit but it requires servlet 
> container, it's
> executed in a jsp page etc. I'd like to have automated unit testing on
> each build.
> 
> How does Cactus fit in? I recently discovered it but haven't 
> downloaded
> it yet.

If you look in the current unit tests for Struts, you'll find very minimal
usage of Cactus.  You might get a feeling for how this can work for you.
Note that this doesn't really test your TLD file, or how the page might
interact with the JSP compiler, but it does test the actual tag code and
what it does.

When I actually finish committing the Struts-EL code (hopefully in the next
couple of days), you can inspect the unit tests in there, which are based on
what is in Struts, but which are much more extensive (although I still have
more to write).  These use Cactus, but they also use HttpUnit, Xalan, and
JTidy (and AspectJ, under the covers, by JTidy).  Some of these tag tests
were a little nasty to write, especially for the tags that need the Struts
configuration set up, and which use somewhat complex algorithms to generate
their output.

You'll have to inspect the Struts build process to see how Cactus is really
set up.  Since I just copied that stuff, I didn't have to figure it out :) .

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts-EL: Status and moving forward

[Karr, David]

> -Original Message-
> From: V. Cekvenich [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 17, 2002 8:07 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Struts-EL: Status and moving forward
> 
> I think this is great that you did this and a great contribution.!!!
> 
> I would like to test it in basicPortal.sf.net when you have something 
> that can deploy.
> 
> How best to get your work?
> I am sure you could host CVS/files anywhere but basicPortal.sf.net is 
> one place, or if you are a commiter here (which he should be).

Until it's put into the "contrib" tree, you can just download the attachment
that I added to the enhancement request (#12365), which is the entire
distribution of the project.  When you build it, you will likely see one
error due to the fact that I didn't create a "conf/share" directory (first
noticed by Eddie Bush).  If you manually create that directory and rebuild,
it should build ok.  It doesn't have much documentation yet, but the
top-level README provides useful information.  The
"doc/userGuide/struts-*-el.xml" files contain the documentation for each tag
and attribute, although not quite in a friendly form yet.  The
"strutsel-exercise-taglib" application provides a useful demonstration of
many of the tags.

If you do download directly from the attachment, you should also know that
it will probably be tweaked somewhat when it's stored into "contrib", but
it's hard to tell exactly what will change.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Figuring out which commons library versions to get source for

[Karr, David]

> -Original Message-
> From: James Mitchell [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 15, 2002 12:41 PM
> To: Struts Developers List
> Subject: RE: Figuring out which commons library versions to get source
> for
> 
> Hey David,
> 
> I don't remember what IDE you are using, but I use NetBeans 
> and I can step
> attach to tomcat remotely and step all the way down to 
> java.lang.Object.
> It's interesting getting the correct directories mounted for 
> the project,
> but once I'm there I can just set break points, attach, and 
> then dive into
> the bowels of my application.
> 
> Anyway, if you find it necessary, I can help you get there.

I'm using JDeveloper at work, but I use NetBeans at home, and I'm set up to
debug Tomcat there.  At this point, for my current problem, I don't know
that tracing into the Tomcat code will do me much good.  I'm only tracing
through the Struts/Commons code, and I'm already horribly confused :) .

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Figuring out which commons library versions to get source for

[Karr, David]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 15, 2002 12:47 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Figuring out which commons library versions to get source
> for
> 
> 
> In the CVS Repository viewable at cvs.apache.org you can 
> notice which version
> was used for struts by looking at the CVS Tag STRUTS_1_1_B2
> 
> for example in beanutils DynaProperty the log is available 
> via this link
> http://cvs.apache.org/viewcvs.cgi/jakarta-commons/beanutils/sr
c/java/org/apache/commons/beanutils/DynaProperty.java

Ok, that's useful.  I also happened to notice that the MANIFEST.MF of each
of the commons jar files have a "Implementation-Version:" field.  The value
of this field seems to correspond to versions of each of the commons
libraries.  The value for "collections" was "2.0".  However, the value for
"beanutils" was "1.4-dev".  Does that mean "1.4", or something before "1.4"?
Your link to the CVS log seems to indicate that beanutils 1.4 was used for
Struts 1.1b2, but this label in the manifest makes me wonder a bit.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: