Future Struts evolution: look at elements of BEA Page Flows
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
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
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])
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
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 html:img 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 @@ /info +attribute + nameaction/name + requiredfalse/required + rtexprvaluetrue/rtexprvalue + info + pThe 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 + codeaction/code attribute on the link tag works), + in addition to any necessary URL rewriting. You + strongmust/strong specify the codeaction/code, + codepage/code + attribute or the codesrc/code attribute./p + /info +/attribute + attribute namealign/name requiredfalse/required - 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
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
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: EL evaluation performance...
-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
-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: html:errors property=petFish[3].species I'd like to propose (and will implement if people think it's a good idea) two new things. First off, doing html:errors name=petFish property=species indexed=true should match errors for the current iteration values. Secondly, doing html:errors name=petFish 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?
-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
-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?
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
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: select is missing a readonly attribute
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 html:select 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?
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% logic:forward name=test/ In Struts config: ... global-forwards forward name=test path=test.defaultLayout/ /global-forwards ... plug-in className=org.apache.struts.tiles.TilesPlugin set-property property=definitions-config value=/WEB-INF/tiles-defs.xml/ set-property property=definitions-debug value=2/ set-property property=definitions-parser-details value=2/ set-property property=definitions-parser-validate value=true/ /plug-in In tiles-defs.xml: ... tiles-definitions definition name=test.defaultLayout path=/WEB-INF/jsp/layouts/defaultLayout.jsp put name=header value=/WEB-INF/jsp/common/header.jsp/ put name=menubar value=/WEB-INF/jsp/common/menubar.jsp/ put name=body-content value=/WEB-INF/jsp/common/body-content.jsp/ put name=footer value=/WEB-INF/jsp/common/footer.jsp/ /definition /tiles-definitions - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
RE: Should html:file tag have a value attribute?
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? info p strongNOTE/strong: 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. /p Value to which this field should be initialized. [Use the corresponding bean property value or body content (if any) if property is not specified] /info -- 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 CP 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: Short term plans
-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]
Investigating adding custom ant task to valid TLD attributes bean mappings
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: Investigating adding custom ant task to valid TLD attributes bean mappings
-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]
RE: committers attention - just a few moments...
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
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 %
bean:define id=COOKIE_KEY
value=org.apache.struts.taglib.bean.COOKIE_KEY/
bean:define id=COOKIE_VAL value=Testing/
logic:equal name=runTest value=testCookieName
bean:cookie id=cookie name=org.apache.struts.taglib.bean.COOKIE_KEY/
bean:define id=cookieId name=cookie property=value/
% Assert.assertEquals(COOKIE_VAL, cookieId); %
/logic:equal
I wanted to know if any of you have a preference to how we do this.
Comments?
--
James Mitchell
RE: DO NOT REPLY [Bug 16749] New: - Struts EL tag handlers cannot be reused by containers
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
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
-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: foo:bar a=1 b=2/ foo:bar a=1 b=3/ 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: DO NOT REPLY [Bug 16749] - Struts EL tag handlers cannot be reused by containers
-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]
Plans for the upcoming 2/14 soft deadline?
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: [PATCH] for 13279
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]
RE: LogFactory.release(classloader)
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
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Struts in Action http://husted.com/struts/book.html -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Link to current bugs we're focusing on for 1.1rc1?
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: options collection problem
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: html:select property=noticeStatus html:options collection=someList labelProperty=noticeStatusStrKey property=noticeStatusStrValue/ /html:select 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]
RE: options collection problem
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: html:select property=noticeStatus html:options collection=someList labelProperty=noticeStatusStrKey property=noticeStatusStrValue/ /html:select 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: [OT] Re: Why are people are up on Struts
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
nightly build still missing struts-el?
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: nightly build still missing struts-el?
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:
copy todir=${build.home}/library
fileset dir=${jstl.home}/tld includes=*.tld/
fileset dir=${struts.home}/lib includes=*.tld/
/copy
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]
RE: Struts without taglib ?
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Adding doc to user guide on indexed/mapped properties/tags
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Enhancement Request - add label and labelKey to form elements
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 label value for each form element: For example: label for=nameName:/label input type=text id=name size=50 name=name / More information at: http://www.csuohio.edu/uctl/508/forms.html This would typically be rendered with Struts tags using: label for=nameName:/label html:text name=name styleId=name size=50/ To make it easier, we could do: html:text name=name styleId=name size=50 label=Name:/ OR html:text name=name styleId=name size=50 labelKey=prompt.name/ The problems I see with this are that you lose some control over the presentation (i.e. a br / after the label or labels in a separate td). 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: 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: Enhancement Request - add label and labelKey to form elements
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] I think a way to create label 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Enhancement Request - add label and labelKey to form elements
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: html:label for=name bean:message key=prompt.username/ /html:label Is more typing than: label for=name ... /label Maybe something like this would make it more useful: html:label key=prompt.username / 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 h:label key=prompt.username / 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 html:label 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 label value for each form element: For example: label for=nameName:/label input type=text id=name size=50 name=name / More information at: http://www.csuohio.edu/uctl/508/forms.html This would typically be rendered with Struts tags using: label for=nameName:/label html:text name=name styleId=name size=50/ To make it easier, we could do: html:text name=name styleId=name size=50 label=Name:/ OR html:text name=name styleId=name size=50 labelKey=prompt.name/ The problems I see with this are that you lose some control over the presentation (i.e. a br / after the label or labels in a separate td). 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 label 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 html:label tag instead. Then, you could do things like this on the logon page in struts-example: ... tr th align=right html:label for=name bean:message key=prompt.username/ /html:label /th td align=left html:text styleId=name property=username size=16 maxlength=18/ /td /tr ... (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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Velocity vs. JSP: objective tests?
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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: html:html locale=true xhtml=true
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 html:html 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] How to implement XHMTL support
-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 html:html xhtml=... that was searched for the same way that the standard version is, but does *not* actually emit an html 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: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How to implement XHMTL support
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 html:xhtml/ over html:isXhtml/. 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: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Struts 1.0.2 + Xerces 2.2.0
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: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [VOTE] How to implement XHMTL support
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 html:html xhtml=true 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 html:html 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: 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
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: 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
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: FW: Struts 1.0.2, Nested 1.0 and Standard Tags 1.0.2
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.
html:form action='myaction' method='post'
nested:iterate property='myarraylist'
c:set var=myChoiceValue scope='request'
nested:write property='myNestedChoiceValue'
/c:set
c:set var=myChoiceLabel scope='request'
nested:write property='myNestedChoiceLabel'
/c:set
nested:select property='myChoice'
html:options
name='%=(String)
request.getAttribute(myChoiceValue)%'
labelName='%=(String)
request.getAttribute(myChoiceValue)%'
/
/nested:select
/nested:iterate
/html:form
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:
html-el:options name=${myChoiceValue} labelName=${myChoiceLabel}
/
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: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Attribute lowsrc of html:img is non-compliant?
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 http://www.htmlhelp.com which often lists some attributes that it states are browser-dependent. -- 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
-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: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Building Struts
-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: Accessing DynaActionForm objects in JSTL tags?
At end.
-Original Message-
From: Craig R. McClanahan [mailto:craigmcc;apache.org]
Sent: Tuesday, October 29, 2002 11:44 PM
David == David Karr 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:
c:out value=${dynabean.map.foo}//c:out
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: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: [struts-el] HTML taglib
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.clinit(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: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Struts-EL - BUILD FAILED
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: [struts-el] HTML taglib
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: 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
-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: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Struts-EL - BUILD FAILED
-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: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Struts-EL - BUILD FAILED
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
property file=${user.home}/build.properties/
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: mailto:struts-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Struts-EL - BUILD FAILED
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
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
-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
-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: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Tiles Refactorings for 1.1 compatability
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: Tiles Refactorings for 1.1 compatability
-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: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
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
RE: Tiles Refactorings for 1.1 compatability
-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: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Suggestions for placement of Struts-EL information in the user gu ide?
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: 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: Constructing Binary Distribution
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: 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?
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 hanging-head, 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: 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] How should Tiles be refactored?
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 hanging-head, 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: 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] -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] How should Tiles be refactored?
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 hanging-head, 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: LabelTag
-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 input 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/tiles UseAttributeTag.java
-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: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Applying patches
-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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Nested taglib with EL?
-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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: cvs commit: jakarta-struts/contrib/struts-el build.xml
-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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Nested taglib with EL?
-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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Nested taglib with EL?
-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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts-EL: Finished with copyright header and javadoc
-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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Unit testing taglibs?
-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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts-EL: Status and moving forward
-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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Figuring out which commons library versions to get source for
-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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Figuring out which commons library versions to get source for
-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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
