Re: Nested-EL
struts == struts [EMAIL PROTECTED] writes: struts Back in September, David Karr was threatening to do Tiles-EL and Nested-EL. I struts see that the Tiles-EL has been committed, sweet. Nested-EL seems to be struts missing. David, have you started working on Nested-EL? If so, how far off is struts it from being complete? If not, do you have any tips, because I am getting struts started on it tonight. No, I haven't started on it yet. However, realize that the library that I would build might not be what you're looking for. The only result of building an -el library is that any tag attribute values can use the EL to specify the value, as opposed to JSP expression scriptlets. In general, the EL library would not add or delete any attributes, or add any basic architectural functionality. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD; SCBCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: alt attribute on HTML Tag Library tags
James == James Holmes [EMAIL PROTECTED] writes: James I noticed that many of the HTML Tag Library tags have alt and altKey James attributes available. Correct me if I'm wrong, but I think only the James img tag in HTML has that option. Any reason not to remove them from James tags whose HTML counterpart doesn't support it? The HTML 4.01 specification says the alt attribute is available on the applet, area, img, and input tags. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD; SCBCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why are ImportAttributeTag and UseAttributeTag final classes?
Is there a good reason for the tiles classes ImportAttributeTag and UseAttributeTag to be final classes? I can't implement tiles-el if those are final classes. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD; SCBCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles-el and nested-el tags (was Re: Support for non-JSTL tags)
David == David M Karr [EMAIL PROTECTED] writes: Sgarlata == Sgarlata Matt [EMAIL PROTECTED] writes: Sgarlata Speaking of EL, I noticed we don't have EL versions of the Tiles tags. I would Sgarlata be happy to provide the implementations, but I know it will be tedious so I Sgarlata only want to proceed if there's a reasonably good chance they will be added to Sgarlata the Struts distribution. Thoughts anyone? Sgarlata In a private conversation Steve Raeburn indicated he would be interested in Sgarlata these tags. Steve also pointed out we are missing the Nested tags, but since Sgarlata I've never used those before I leave that tedious task to someone else ;) David I've been intending to produce at least a tiles-el library, and possibly a David nested-el library, but I've been trying to watch for a significant level of David interest for this. I very occasionally see a mention of a desire for David tiles-el, and less so for nested-el. I haven't looked at those libraries David for a while, so I'm not certain how much value there will be for this. If David there's really significant interest in this, I could proceed with this, first David doing tiles-el, and then nested-el. I'm planning on committing the tiles-el library this weekend, but I won't have any unit or integration tests for it by the time I commit it. I'll proceed down that path once it's committed, but that process will be slow. I'd appreciate it if motivated Tiles/JSTL users could test it as much as possible once I've put it into the nightly build. I'll also start looking at the nested-el library, just for completeness. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiles-el and nested-el tags (was Re: Support for non-JSTL tags)
Sgarlata == Sgarlata Matt [EMAIL PROTECTED] writes: Sgarlata Speaking of EL, I noticed we don't have EL versions of the Tiles tags. I would Sgarlata be happy to provide the implementations, but I know it will be tedious so I Sgarlata only want to proceed if there's a reasonably good chance they will be added to Sgarlata the Struts distribution. Thoughts anyone? Sgarlata In a private conversation Steve Raeburn indicated he would be interested in Sgarlata these tags. Steve also pointed out we are missing the Nested tags, but since Sgarlata I've never used those before I leave that tedious task to someone else ;) I've been intending to produce at least a tiles-el library, and possibly a nested-el library, but I've been trying to watch for a significant level of interest for this. I very occasionally see a mention of a desire for tiles-el, and less so for nested-el. I haven't looked at those libraries for a while, so I'm not certain how much value there will be for this. If there's really significant interest in this, I could proceed with this, first doing tiles-el, and then nested-el. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/contrib/struts-el build.xml
craigmcc == craigmcc [EMAIL PROTECTED] writes:
craigmcc craigmcc2003/08/09 18:21:43
craigmcc Modified:contrib/struts-el build.xml
craigmcc Log:
craigmcc Modify the build.xml for struts-el to have a hard-coded reference to
the
craigmcc struts.jar in the parent Struts source tree (i.e. output of ant
dist).
craigmcc This makes it possible to compile struts-el even when the user has a
craigmcc ${user.home}/build.properties file that defines a struts.jar property
craigmcc (as I do, because I *use* Struts in lots of different packages).
I assume this is to address the issue with compile errors?
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED] ; SCJP; SCWCD
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/contrib/tag-doc build.xml
craigmcc == craigmcc [EMAIL PROTECTED] writes: craigmcc craigmcc2003/08/09 12:29:30 craigmcc Modified:.build.xml craigmcc ELFormTag.java ELHtmlTag.java craigmcc ELJavascriptValidatorTag.java craigmcc Log: craigmcc Also fixed some compile errors in struts-el -- I don't know how that code craigmcc could have compiled for anyone. Could someone more familiar with that craigmcc library make sure I did the changes correctly? Huh? What compile errors were you getting? I just re-updated and changed it back to the way it was (in ELFormTag, at least), and it compiles fine (with both 1.4.1 and 1.3.1). It can't work the way you changed it, because it has to call the base class setter, which takes a boolean, not a string. craigmcc -if ((bool = EvalHelper.evalBoolean(scriptLanguage, getScriptLanguageExpr(), craigmcc - this, pageContext)) != null) craigmcc -setScriptLanguage(bool.booleanValue()); craigmcc +if ((string = EvalHelper.evalString(scriptLanguage, getScriptLanguageExpr(), craigmcc +this, pageContext)) != null) craigmcc +setScriptLanguageExpr(string); -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building contrib packages WAS Re: cvs commit: jakarta-struts/contrib/tag-doc build.xml
David == David Graham [EMAIL PROTECTED] writes: David While we're somewhat on this topic I'd like to get some clarification on David the build process. Why do struts-el and struts-legacy get built with the David standard Struts build file? Struts-EL has *never* built on my machine and David I have just taken it on faith the rest of Struts built properly. Also, David after struts-legacy was added I've had to run my builds twice. The first David one always fails and the second succeeds (well, not really succeeds David because struts-el fails). So what compile errors are you getting in Struts-EL and Struts-Legacy? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/contrib/tag-doc build.xml
Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig On Sat, 9 Aug 2003, David M. Karr wrote: Date: 09 Aug 2003 16:01:52 -0700 From: David M. Karr [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-struts/contrib/tag-doc build.xml craigmcc == craigmcc [EMAIL PROTECTED] writes: craigmcc craigmcc2003/08/09 12:29:30 craigmcc Modified:.build.xml craigmcc ELFormTag.java ELHtmlTag.java craigmcc ELJavascriptValidatorTag.java craigmcc Log: craigmcc Also fixed some compile errors in struts-el -- I don't know how that code craigmcc could have compiled for anyone. Could someone more familiar with that craigmcc library make sure I did the changes correctly? Huh? What compile errors were you getting? I just re-updated and changed it back to the way it was (in ELFormTag, at least), and it compiles fine (with both 1.4.1 and 1.3.1). It can't work the way you changed it, because it has to call the base class setter, which takes a boolean, not a string. Craig I was getting cannot resolve method errors for the cases that were Craig changed. Can you go ahead and commit your reversions so I can reproduce Craig the errors? Done. I made these changes a few days ago to match very recent changes to the base tags. If you're getting cannot resolve method errors, I would assume the struts.jar you're referencing is before those changes. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with exercise-taglib, link tag, or modules?
adam == adam kramer [EMAIL PROTECTED] writes: adam On Wed, 22 Jul 2003, David M. Karr wrote: I've been working on some minor updates to Struts-EL, to match recent changes to the base tag library, so I've been running through some tests. I'm using WebLogic 8.1 for these tests. I first noticed that the strutsel-exercise-taglib application dies with the following stack trace: - java.lang.NullPointerException at org.apache.struts.util.RequestUtils.pageURL(RequestUtils.java:1591) - Line 1591 is the following (after I added a couple of debugging lines): String pagePattern = moduleConfig.getControllerConfig().getPagePattern(); I found that moduleConfig is null here, but I don't know why. adam Actually, I noticed computeURL has a backward compatibility hack that adam gets the default app module config and stores it in the request scope if adam one isn't already there. If you do have a recent version of struts built, adam perhaps the webapp has an older version of struts installed. Maybe adam replacing it with a fresh struts.jar would work. It looks as though this adam should not be happening. It doesn't happen when requesting html-link.jsp adam in struts exercise-taglib webapp, but i havent installed struts-el. My copy of struts.jar is built from CVS latest. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problems with exercise-taglib, link tag, or modules?
I've been working on some minor updates to Struts-EL, to match recent changes to the base tag library, so I've been running through some tests. I'm using WebLogic 8.1 for these tests. I first noticed that the strutsel-exercise-taglib application dies with the following stack trace: - java.lang.NullPointerException at org.apache.struts.util.RequestUtils.pageURL(RequestUtils.java:1591) at org.apache.struts.util.RequestUtils.computeURL(RequestUtils.java:536) at org.apache.struts.util.RequestUtils.computeURL(RequestUtils.java:431) at org.apache.struts.taglib.html.LinkTag.calculateURL(LinkTag.java:495) at org.apache.struts.taglib.html.LinkTag.doStartTag(LinkTag.java:353) at org.apache.strutsel.taglib.html.ELLinkTag.doStartTag(ELLinkTag.java:675) - Line 1591 is the following (after I added a couple of debugging lines): String pagePattern = moduleConfig.getControllerConfig().getPagePattern(); I found that moduleConfig is null here, but I don't know why. Before I submit a bug for this, does anyone have an idea what might be happening here? In addition, I also found a problem in the base struts-exercise-taglib. The link for the html:link page dies with the following stack trace: - javax.servlet.jsp.JspException: Cannot find ActionMappings or ActionFormBeans collection at org.apache.struts.taglib.html.FormTag.lookup(FormTag.java:805) at org.apache.struts.taglib.html.FormTag.doStartTag(FormTag.java:513) at jsp_servlet.__html_45_link._jspService(__html_45_link.java:226) at weblogic.servlet.jsp.JspBase.service(JspBase.java:33) at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6291) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317) at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:97) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3575) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2573) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:178) - I hope this isn't something that only happens in WebLogic. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Close to RC2?
Ted == Ted Husted [EMAIL PROTECTED] writes: Ted A frequent comment about RC1 is that it did not use the released versions of Ted the Commons packages. Ted I think for RC2 to be a likely release candidate and enable us to go from Ted there to a final release, we will need to lock down the Commons dependencies Ted first. Ted Otherwise, I believe we would just be preordaining a RC3 that deployed the Ted final versions of the Commons packages. Ted So, I would say that as soon as the requisite Commons packages are released, we Ted would be good to go to RC2 (assuming that we have kept our own tickets trimmed, Ted as we have so far). +1 on that amendment. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to debug problem in TestDynaActionForm class?
I just decided to start looking at the unit tests, in order to look into updating the Struts-EL test cases. After just doing an update, and executing test.tomcat.41 (with Tomcat-4.1.18 on Win2k), I get the following (I added a println of the form property, just in case): - Testsuite: org.apache.struts.action.TestDynaActionForm Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.391 sec - Standard Output --- stringProperty[This is a string] - --- - Standard Error - Mar 9, 2003 4:26:32 PM org.apache.struts.util.PropertyMessageResources init INFO: Initializing, config='org.apache.struts.util.LocalStrings', returnNull=true - --- Testcase: testBeanCreate took 0.381 sec Caused an ERROR junit.framework.Assert.assertEquals(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V at org.apache.struts.action.TestDynaActionForm.testBeanCreate(TestDynaActionForm.java:217) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) - So, I'm first trying to understand why this failing, but I'd also like to be able to set up my debugger so that I can look at these issues a little closer. My basic problem is that I can't figure out which java command line to change to add the -Xdebug flag (and others). For this, I thought it might be the java task in the start.tomcat.41 target in the build-tests.xml script. This doesn't appear to be it, however, as my breakpoints in the test class go unbroken, even though it hit my added println statement. I know it got to the java command line that I changed, because it paused, waiting for a debugger to connect to it. Once I had my debugger connect, it went on, but it never hit my breakpoints in the test class. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 17728] - EvalHelper should not throw NullAttributeException, it's too slow
bugzilla == bugzilla [EMAIL PROTECTED] writes: bugzilla DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG bugzilla RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT bugzilla http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17728. bugzilla ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND bugzilla INSERTED IN THE BUG DATABASE. bugzilla http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17728 bugzilla EvalHelper should not throw NullAttributeException, it's too slow bugzilla [EMAIL PROTECTED] changed: bugzillaWhat|Removed |Added bugzilla bugzilla Status|REOPENED|RESOLVED bugzilla Resolution||FIXED bugzilla --- Additional Comments From [EMAIL PROTECTED] 2003-03-09 05:55 --- bugzilla Fixed performance problem by removing usage of NullAttributeException for normal bugzilla processing flow. It now will just not call the setter method if the original bugzilla expression or resulting value is null. Note that I successfully committed this change, along with changes to the structure of the BeanInfo classes, but both commit emails bounced, for being too large. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Some taglibs are missing a few common attributes.
James == James Mitchell [EMAIL PROTECTED] writes: James We allow titleKey for the html:frame, altKey and titleKey for James html:button, and a few others, but do not allow a way to specify the James bundle or args. James Besides the obvious... James bean:define id=myMessage James bean:message key=my.title/ James bean:define James html:sometag title=%=myMessage%/ James ...work-around, I'm wondering if we should add this. James I think we shouldn't. I think the work-around is a much more flexible James and generally better solution given the options available with James bean:message. James Your thoughts? If I understand this correctly, it's certainly possible to do it with bean:message, but it would make the resulting JSP code less maintainable (many more lines of code). It might be worthwhile examining exactly which tags and attributes we're looking at changing if we added this. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts-EL package
David == David Graham [EMAIL PROTECTED] writes: David Currently, the struts-el tags live in the org.apache.strutsel.taglib.* package. David At some point, I think they need to be moved to org.apache.struts.taglib.el.* David to match the rest of the taglibs. Maybe they could even be under their David respective non-el taglibs (ie. org.apache.struts.taglib.bean.el). I could go either way (I spent some time agonizing over this at the start), but then again, why bother changing it? Nevertheless, if people think it would be better this way, that's fine. I could easily put it on my list of post-1.1 changes. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
When to commit Struts-EL changes for #16749 (setter/reuse problem)
As I said earlier, I have finished making the changes locally for #16749 (the problem with incorrect use of attribute setters wrt to tag handler reuse), and I've tested them in Tomcat. Mark Abbott, the original reporter for this bug, has tested the fix in Resin, where he saw the problem. A vote was taken for the disposition of this bug and it was decided to commit these changes post 1.1. What should I do here? If I truly need to wait until post 1.1 to commit these changes, do we have an estimate of when the 1.1 tag will be dropped? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Release Candidate 1 Release Plan
Martin == Martin Cooper [EMAIL PROTECTED] writes: Martin -- Martin Vote: Struts 1.1-rc1 Release Plan Martin [X] +1 I am in favor of the release, and will help support it Martin [ ] +0 I am in favor of the release, but am unable to help support it Martin [ ] -0 I am not in favor of the release Martin [ ] -1 I am against this proposal (must include a reason). Martin -- Hopefully not too many people will be inconvenienced by #16749 (the problem with attribute setters in Struts-EL) not being fixed in 1.1. That's my only hesitation, but it's not enough to vote against the release at this time. I'll be glad to see it, and will do what little I can to help. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 16749] New: - Struts EL tag handlers cannot be reused by containers
I wanted to give a little status on this and query the committers on how they would like me to proceed. I've finished the changes for this, but I haven't checked anything in, as the consensus was that we wanted to delay a fix for this until after 1.1. The change simply required making sure every attribute of every tag was represented by an instance variable of the ELTag class (all suffixed with Expr), along with associated getters and setters for each attribute. The BeanInfo class maps each plain attribute name to the setattrExpr() setter method. In the evaluateExpressions() methods, it calls getattrExpr() to get the current expression value, evaluates the expression through the EL engine, and calls setattr() on the result. Although the number of lines changed and added represent a huge percentage of the existing code, all of these changes were very straightforward. So straightforward that I performed most of the changes with an Emacs Elisp script. With this setup, even if the setter method associated with the attribute is only called once (because the container saw it using a static value), the correct value will be retrieved inside the doStartTag() call, to evaluate the expression in the context of the reused tag. Again, the fault with the previous code is that many of the getter methods associated with the tag attributes were set to use the base class getter method. If the setter method wasn't called again to set the EL expression, the value pulled out of the getter would be the evaluated value, not the expression. With this change, the expression string is preserved so it could be used when the tag handler is reused. I've run through my existing Cactus tests, and I've manually displayed all the pages in the strutsel-exercise-taglib. I have ONLY used Tomcat 4.1.10 and 4.1.18 for my testing, and neither the Cactus tests or the exercise taglib tests every aspect of the library. In fact, the Cactus tests don't test all of the tags, and neither does the exercise taglib. Nevertheless, based on my understanding of the problem and the change I've made, I'm reasonably confident this will work in Resin, or any other container that takes advantage of this optimization defined in the JSP specification. I don't know of any other containers besides Resin that uses this optimization. I asked about this on one of the WebLogic newsgroups, but I haven't gotten a response yet. Along the way, I discovered another problem that caused me to remove a line of code from every expression evaluation. When expressions are evaluated, if the attribute expression was null, it causes a call to setattr(null). This caused problems in cases where an unset attribute in a base class has a non-null default value (like the name attribute in several tags). I fixed this by removing the call to setattr(null) if the expression was null. I realized this could be more efficient, by just not evaluating it if the expression was null. I'll look at enhancing that in a later release. Again, I've finished these changes and done some testing, but I don't have Resin or other containers installed to test on any other containers. I'd like to make this fix available for the 1.1 release, but I admit there's some risk involved. Even worse, tomorrow morning (Sunday) I'm going out of town until very late Friday evening. I won't be able to check my email until somewhat late on Saturday morning. As a risk mitigation strategy, is it reasonable/practical to tag all the current versions of the files in the struts-el directory with a label like BEFORE_ATTR_FIX? If I do commit these changes and they create unexpected problems, someone might be able to back up the versions to that tag. 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. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - 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
David == David Karr Karr writes: -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED]] David wrote: I'll also have to build a little test case that clearly demonstrates David 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 David the problem? I'm trying not to panic, but I've got a project that depends David on Struts-EL and JSTL. I was hoping to see Struts-EL in the final David release, but David Based on what I understand, if you had a logic-el:iterate loop (or even David c:forEach, now) containing a single html-el:text component whose David value attribute used an EL expression based on the index variable, the David first iteration would use the value of the first index, and the second David iteration would unexpectedly use the value from the first iteration David (because it wouldn't call the setter). Is it really this simple? After trying to set up a test case for this, I'm finding I cannot repeat it with Tomcat. I already had a test case for this, unknowingly. I'm using Tomcat 4.1.18(LE/JDK14). Is there something I have to do to enable this feature of reusing tag handlers? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need help deciphering screw-case for PR 15799
James == James Turner [EMAIL PROTECTED] writes: James I've taken a look at the code for 15799, but I'm still not exactly sure James what problem was being reported. I don't feel comfortable applying a James patch for a problem that isn't properly documented. Anyone got a clue? If the reporter doesn't reply to the request for more information, I would leave it alone for now. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why is TestRequestUtils.testAbsoluteURL() failing?
I'm having trouble understanding why one of the unit tests is failing. The failure is in TestRequestUtils.testAbsoluteURL(). It builds a URL from RequestUtils.absoluteURL() and compares it with the value it expects. It says the computed value is not equal to the expected value. The weird thing is, after I saw this I edited the method to first store the expected value into a variable, so I can compare against that instead of the hardcoded value. I then added System.out.println calls for both the computed and expected strings. I also printed the result of a call to String.equals(), comparing them. The strings are identical, and it prints true for the equals call, and then proceeds to throw an Error from the assertEquals call. I'm running this test with jdk 1.4.1_01, TC 4.1.10, and junit 3.8.1. If it matters, here's the stack trace (note that I added 4 lines for the variable assignment and print statements): Testcase: testAbsoluteURL took 0.421 sec Caused an ERROR junit.framework.Assert.assertEquals(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V at org.apache.struts.util.TestRequestUtils.testAbsoluteURL(TestRequestUtils.java:153) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Ted == Ted Husted [EMAIL PROTECTED] writes: Ted As it stands, struts-el has been documented as a contribution and does not Ted appear with the other developer guides (mea culpa). Making it a standalone Ted distribution is just a matter of changing the build script. This would then Ted allow David to make a new release of struts-el without forcing a new release of Ted the core framework. You certainly can't take all the blame for the lack of Struts-EL documentation, I haven't given you very much to integrate. Ted So, I will have to join David Karr in casting a negative vote as to promoting Ted the beta to a release candidate as it is now built, on the grounds that Ted struts-el should be distributed separately. I guess my only problem with this argument is that Struts-EL releases have to be closely tied to Struts releases. It doesn't just use Struts, like other contributions, it's interface has to exactly mirror the Struts interface. Except for some occasional minor bugs I've found in Struts-EL, the only real changes I've had to make were to reflect changes to tag attributes in the base library. Once Struts 1.1 is released with Struts-EL, I'm not sure I'd want to make any more releases of Struts-EL, until the next Struts release (unless I find any non-interface problems). If I made a Struts-EL release reflecting changes to the Struts nightly build (after 1.1), then we'd have the situation of a Struts-EL release which had to be used with a nightly build of Struts, and not the latest release. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE (RESTATED FOR CLARITY]: Release Nightly Build as RC1
James == James Turner [EMAIL PROTECTED] writes: James Everyone getting tired of this yet? :-) James Ok, at the request of those who want to know what they're voting on, James here's the vote restated. I think there's general consensus that the James patches since 1.1b3 are important enough to use a nightly build instead James of the beta directly. James Question 1: James +1 means you want to take the latest nightly build for RC1. James +0 Who cares James -1 You want another beta before RC1 James Question 2: James +1 means you want struts-el included in RC1 and the final release. James +0 Who cares James -1 You want struts-el packages seperates with it's own release cycle Q1: +1 Q2: +1 -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
Ted == Ted Husted [EMAIL PROTECTED] writes: Ted Is the struts-el taglib now actually broken because html:link gained a missing Ted property? Or does it simply fail to meet one of our expectations for the taglib? No, I certainly wouldn't call it broken, just that it wouldn't support an attribute that is supported in the base library. Ted I am of the opinion that all the taglibs should be packaged separately. In this Ted way, that fixes and enhancements that do not affect the core Action and Config Ted packages could be released more easily. The conventional taglibs have stayed Ted put so far since they arguably do no harm and provide a convenience to a great Ted many users. I suppose if core Struts was separated from the tag library, then both tag libraries could be released together in a single package. Ted But we now have the situation where you would be obligated to vote against a Ted release because changes to one package where not reflected in another package, Ted which at this time lives in the contrib folder. I submit this that this is the Ted type of coupling that MVC was invented to defeat, and that we not taking our Ted own advice =:0) The problem is that Struts-EL is not coupled with the MVC parts, just with the tag library. Ted Craig plans on releasing the Struts-JSF tablib separately, why can't we do the Ted same with Struts-EL? I don't know enough about what exactly Struts-JSF will be doing to really compare it, but I would guess that it won't be as intimately tied to the Struts MVC core or to the Struts tag library, which would make it logical to be released separately. My other concern about doing this is that we'll be changing the packaging structure of Struts, just before a release. I think I see some of your point about packaging the MVC core separately from the tag libraries, but I think the Struts tag library should be packaged with Struts-EL. In any case, I'm concerned about changing the release and packaging structure so close to a release. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
David == David Graham [EMAIL PROTECTED] writes: David The only added attribute was cdata that defaults to true on the javascript David tag. I'd like to see this included in the release because it rounds out the David xhtml functionality. David We have yet to hear back from Martin if he is vetoing this change. If he does, David then I'll remove the attribute and always put a cdata section around the David javascript in xhtml mode. Obviously, I and other xhtml users would be David dissapointed. And on that note, remember that we need to make sure that any attribute changes in the base library get into Struts-EL. There were some attribute changes made right before the 1.1b3 tagging, which was during a five day period when my house was without power for 79 hours, so I wasn't able to get the associated Struts-EL changes in until after 1.1b3 was tagged. I don't think that is a real problem, but it will be a real problem if something like this happens for the real release. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
David == David M Karr [EMAIL PROTECTED] writes: David == David Graham [EMAIL PROTECTED] writes: David The only added attribute was cdata that defaults to true on the javascript David tag. I'd like to see this included in the release because it rounds out the David xhtml functionality. David We have yet to hear back from Martin if he is vetoing this change. If he does, David then I'll remove the attribute and always put a cdata section around the David javascript in xhtml mode. Obviously, I and other xhtml users would be David dissapointed. David And on that note, remember that we need to make sure that any attribute changes David in the base library get into Struts-EL. There were some attribute changes made David right before the 1.1b3 tagging, which was during a five day period when my David house was without power for 79 hours, so I wasn't able to get the associated David Struts-EL changes in until after 1.1b3 was tagged. I don't think that is a David real problem, but it will be a real problem if something like this happens for David the real release. I'm not sure this matters at this point, but if we're really voting on taking the 1.1b3 tag as rc1, I guess I'd -1 that, based on my previous comment. If we used 1.1b3, The html:link tag will have an action attribute, but the html-el:link tag will not. Is there an easy way to get the diffs or comments of all elements with commits since the 1.1b3 tagging? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Declare Struts 1.1b3 as Struts 1.1 RC1
David == David Graham [EMAIL PROTECTED] writes: David Is that a -1 for 1.1 or -1 for any release? David Dave I very much want to see a 1.1 release very soon, I just don't think the release candidate should be the 1.1b3 release. From: [EMAIL PROTECTED] (David M. Karr) I'm not sure this matters at this point, but if we're really voting on taking the 1.1b3 tag as rc1, I guess I'd -1 that, based on my previous comment. If we used 1.1b3, The html:link tag will have an action attribute, but the html-el:link tag will not. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts and JMX
Jerome == Jerome Ernsberger [EMAIL PROTECTED] writes: Jerome Hallo, Jerome do you think it make sense to use struts and JMX You'd be better off asking questions like this on the struts-user list. The answer depends on what you mean by that. I assume you ask whether they should be used together. From one point of view, they don't have anything to do with each other. From another POV, they could easily be part of the same sub-application. It's entirely conceivable to consider building a Struts-based application which interfaces with MBeans to control server characteristics. I believe that's exactly what the Tomcat Manager application is doing. I guess it's also possible you might want to write MBeans which control aspects of your Struts-based application, and present interfaces to those MBeans, either as another web application, or through other interfaces (command-line, etcetera). -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Another bright idea, make indexed work with JSTL forEach and friends
Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig On Sat, 4 Jan 2003, James Turner wrote: Date: Sat, 4 Jan 2003 13:26:34 -0500 From: James Turner [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Another bright idea, make indexed work with JSTL forEach and friends As has been pointed out, about the only remaining reason to use logic:iterate over c:forEach is that you can't use an html:text tag (or friends) with an indexed property set, because it only looks for logic:iterate on the page stack. Now, it would be very simple (having peered at the source) to have the html tags also look for JSTL iterators. However, to make this work, we'd need to add a dependency on jakarta-taglibs so that the class would be available. I don't think that this would break anything in terms of JSP version support, since it wouldn't require evaluation of ELs, just looking up the stack to see if we find a JSTL interator hanging around. Craig Unless you can do this all with reflection (instead of instanceof and Craig direct method calls), you'll create NoClassDefFound errors for people who Craig don't have the JSTL library in the stack. Other than that caution, I'm Craig +1. That would be gnarly to try to do this with all string-based reflection (no ClassName.class references or instanceof usage). Writing a version of findAncestorWithClass that takes a string instead of a Class is the first step. You'd also have to deal with allowing subclasses of the tag types. That's probably the ugliest part. At this point, I really don't see the urgency. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Another bright idea, make indexed work with JSTL forEach and friends
James == James Turner [EMAIL PROTECTED] writes: James On Sat, 4 Jan 2003, Martin Cooper wrote: If you want to do this, I'd rather see it happen in the html-el taglib than the regular html taglib. Struts-EL already depends on JSTL, and is designed to work in cooperation with it, so it's a much more natural fit than trying to sneak JSTL functionality into the regular tags. James I mildly disagree. EL is to allow struts HTML tags to use EL syntax. James This deals with letting the standard tags find JSTL looping constructs. James As is, you can *almost* entirely eliminate all the Struts tags except James for the HTML tags in favor of JSTL substitutes, since only the HTML tags James deal with things like actions. By implementing this, we can eliminate James having to use the logic taglibs at all. And the change is pretty darn James innocuous, here's the revisted code from BaseHandlerTag, which works James very nicely. Note that I'm not even referencing org.apache stuff. And James the JSTL stuff is only ever invoked if it fails to find the Iterate tag. James One thing I'm considering is caching the classes and methods so that the James reflection doesn't need to happen on every invokation. Sigh. The balance of architectural purity with convenience. It looks like what you've implemented is about the best you can do (you should implement reflection object caching, as you mention). It directly pollutes the Struts code with references to the JSTL, albeit not at compile time. Is that a problem? Who knows? Can anyone envision any other situations in the Struts code where indirect references to the JSTL would be convenient? That, at least, could give us some additional perspective on this. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposed: logic:else clause
James == James Turner [EMAIL PROTECTED] writes: James I find in my code, I do the following a lot: James logic:equal name=foo property=bar valuebaz James /logic:equal James logic:notEqual name=foo property=bar valuebaz James /logic:notEqual James I'd like to propose (and would be willing to code) the following: James logic:equal name=foo property=bar valuebaz James logic:else James /logic:else James /logic:equal James What do people think? I think the trend is to avoid implementing features which are easily supplied in the JSTL. This is easily done with an arrangement of c:choose, c:when, and c:otherwise tags. This doesn't help people who are forced to use containers only supporting Servlet 2.2. Hopefully that set is becoming smaller and smaller. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP; SCWCD -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposed: logic:else clause
V == V Cekvenich [EMAIL PROTECTED] writes:
V The onlye thing that most html-el tags need to be modified to support indexed
V property in JSTL, so we can do multi row updates.
V But that is post 1.1 I am sure.
V .V
What do you mean, Vic? I'm using the same EL engine that the JSTL uses. What
exactly do you think is missing?
V Hal Deadman wrote:
I think the faster everyone moves from logic tags to JSTL the happier
everyone will be. The JSTL choose tag already supports if/elseif/else. The
expression language in JSTL makes logic easy that would be nasty with the
various logic tags.
c:choose
c:when test=${foo.bar eq 'baz'}
...
/c:when
c:otherwise
...
/c:otherwise
/c:choose
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED] ; SCJP; SCWCD
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 3 Release Plan (revised)
Martin == Martin Cooper [EMAIL PROTECTED] writes: Martin A number of new features have been added to Struts since the 1.1 Beta 2 Martin release, and many bugs have been fixed. Therefore, I propose that we Martin release the tip of the main trunk in CVS as Beta 3 for a Struts 1.1 Martin release. I have checked in a proposed release plan, revised from the Martin previous version, which is available for review on the Struts web site: Martin http://jakarta.apache.org/struts/proposals/release-plan-1.1b3.html Martin Release plans must pass by a majority vote of committers on the project, Martin but all other interested parties are welcome to cast their votes (and/or Martin make comments or suggestions on the plan) as well. Martin -- Martin Vote: Struts 1.1b3 Release Plan Martin [x] +1 I am in favor of the release, and will help support it Martin [ ] +0 I am in favor of the release, but am unable tohelp support it Martin [ ] -0 I am not in favor of the release Martin [ ] -1 I am against this proposal (must include a reason). Martin -- I am eager to see this release happen, and I will do what I can to help support it, although being new to this exact sort of thing, I'm not quite sure what that will be. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc/userGuide struts-html.xml
dgraham == dgraham [EMAIL PROTECTED] writes: dgraham dgraham 2002/12/23 17:45:15 dgraham Modified:doc/userGuide struts-html.xml dgraham Log: dgraham Updated info on tags. dgraham Revision ChangesPath dgraham 1.42 +6 -2 jakarta-struts/doc/userGuide/struts-html.xml dgraham Index: struts-html.xml dgraham === dgraham RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-html.xml,v dgraham retrieving revision 1.41 dgraham retrieving revision 1.42 dgraham diff -u -r1.41 -r1.42 dgraham --- struts-html.xml 13 Dec 2002 02:39:01 - 1.41 dgraham +++ struts-html.xml 24 Dec 2002 01:45:15 - 1.42 dgraham @@ -2288,6 +2288,8 @@ dgrahampIf you would like to obtain the coordinates of the mouse dgrahamclick that submitted this request, see the information below dgrahamon the codeproperty/code attribute./p dgraham + dgraham +pThis tag is only valid when nested inside a form tag body./p This is a good idea, but perhaps this should be made clearer? The HTML tag needs to be inside the HTML form tag, but the Struts tag needs to be inside the Struts form tag, both for slightly different reasons. On that subject, wouldn't it be possible to write a tag library validator class which could verify this? I've wondered whether some of these hard to understand errors we get from the framework could be prevented by a tag library validator class. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 20M vs. 23M downloads
Matt == Matt Raible [EMAIL PROTECTED] writes: Matt Any idea why some nightly builds are 23MB and some are only 20MB? Matt http://jakarta.apache.org/builds/jakarta-struts/nightly/ The 3M difference is the Struts-EL distribution, which disappeared from the 8th to the 14th, and appears to be alternating every other day. The last nightly had it. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Size of nightly builds
Alan == Alan P Sexton Alan writes: Alan Between 18th and 19th November, there was a large drop in size of the Alan source nightly build, Between 17th and 18th, there was a large drop in Alan size of the binary build. These drops seem to be due to the Alan contrib/struts-el package. This is not something I use personally at the Alan moment but I did not notice anything in the mail list around this time Alan that would explain such a big change in size. Can anyone explain what Alan has happened there? I'm taking a look at the contents of those builds, but there's one thing I want to know: Is there some place where the console output from Ant for those builds is stored, so I can see if something went wrong? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Size of nightly builds
Alan == Alan P Sexton Alan writes: Alan Between 18th and 19th November, there was a large drop in size of the Alan source nightly build, Between 17th and 18th, there was a large drop in Alan size of the binary build. These drops seem to be due to the Alan contrib/struts-el package. This is not something I use personally at the Alan moment but I did not notice anything in the mail list around this time Alan that would explain such a big change in size. Can anyone explain what Alan has happened there? I've confirmed the binary on the 17th has struts-el included, and the binary on the 18th does not. So how do we track what really happened on a build for a particular day? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: b3 minus 27? (or so)
Ted == Ted Husted [EMAIL PROTECTED] writes: Ted Excluding enhancements, we currently have 27 outstanding issues Ted listed in Bugzilla. Ted Anyone (else) interested in trying to swat these this week, and Ted maybe then get beta 3 out the week of Dec 1? Ted I checked a few of these out that I'd like to handle (one or way Ted or the other =:). Any takers on the rest? I'm not working on a bug currently (unless you count figuring out why struts-el disappeared from the nightly), but I am working on some documentation which I hope to put in the user guide, concerning indexed properties, mapped properties, indexed tags, and indexed/mapped properties in Struts-EL. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Adding doc to user guide on indexed/mapped properties/tags
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. Any comments? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] ; SCJP -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 14116] New: - Add getMap() method to DynaActionForm to let JSTL EL reference DynaActionForms
bugzilla == bugzilla [EMAIL PROTECTED] writes: bugzilla DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG bugzilla RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT bugzilla http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14116. bugzilla ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND bugzilla INSERTED IN THE BUG DATABASE. bugzilla http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14116 bugzilla Add getMap() method to DynaActionForm to let JSTL EL reference DynaActionForms bugzillaSummary: Add getMap() method to DynaActionForm to let JSTL EL bugzilla reference DynaActionForms bugzillaProduct: Struts bugzillaVersion: Nightly Build bugzilla Platform: Other bugzilla OS/Version: Other bugzilla Status: NEW bugzilla Severity: Enhancement bugzilla Priority: Other bugzilla Component: Standard Actions bugzilla AssignedTo: [EMAIL PROTECTED] bugzilla ReportedBy: [EMAIL PROTECTED] I'll commit this in a day or so when I can finish the doc changes and additions to the strutsel-exercise-taglib. -- === 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
Re: Accessing DynaActionForm objects in JSTL tags?
David == David Karr Karr writes:
David I'm asking this here first, to discuss the technical issues. If it appears
David to be feasible, I'll ask a similar question on the user list, and then
David perhaps write a bug report.
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?
David I believe there's a simple change we could make to DynaActionForm to allow
David access to them from JSTL tags. Since DynaActionForm doesn't present a
David strict JavaBeans interface to its properties, you can't access them
David normally. However, the property values are stored in a HashMap in the
David DynaActionForm. The JSTL EL syntax can access hashmap entries. So, if we
David simply added a standard JavaBeans accessor for the HashMap, then the JSP
David programmer could access these properties through a syntax like this:
David value='${actionForm.dyna[foo]}'
David for the foo property of the actionForm DynaBean.
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.
I've considered whether it would be better to file an enhancement request for
BeanUtils, to modify the DynaBean interface, or whether to modify (file the
enhancement on) the Struts DynaActionForm class. The former would make the
change more widely applicable, which is both the good news and the bad news.
Changing an interface would require at least all the top-level classes
implementing the interface to now implement that new method. Alternatively,
the method could be added on just the BasicDynaBean, although I don't know
exactly what the inheritance tree down to DynaActionForm looks like. Since
Introspection operates on the actual type, it doesn't necessarily have to be on
the interface, just the highest level class.
On the other hand, changing DynaActionForm might be easier politically. I
posed a question about this on the commons-user list today, although the
response was polite, they appear to be planning new features in this area that
cover a much larger scope than I care about. They may not want to go in two
directions (even though this could be a very simple change).
If only DynaActionForm is changed, however, is there any likelihood someone
will want to use a plain DynaBean with this? One person who was looking for
this feature (who thought it was already supported in the JSTL) used as his
example JSP scriptlet code using plain BasicDynaBeans.
Any thoughts?
--
===
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
Re: cvs commit: jakarta-struts/src/share/org/apache/struts/taglib/html JavascriptValidatorTag.java
rleland == rleland [EMAIL PROTECTED] writes: rleland +attribute rleland +namehtmlComment/name rleland +requiredfalse/required rleland +rtexprvaluetrue/rtexprvalue rleland +info rleland + p rleland + Wheather or not to enclose the javascript rleland + with html comments. rleland + Defaults to codetrue/code. rleland + /p rleland +/info rleland +/attribute I have a request to the group, to make management of Struts-EL a little easier. Whenever you make a change which adds, deletes, or changes the type of, a custom tag attribute, could you submit a bug report indicating that the corresponding tag in Struts-EL needs to change? -- === 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
Re: [struts-el] HTML taglib
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(MessageResources.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. -- === 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
Re: [struts-el] HTML taglib
Eddie == Eddie Bush [EMAIL PROTECTED] writes: Eddie Ok - this nearly *has* to be an issue with either Ant 1.4.1 or NB. I finally Eddie got a chance to try it under Tomcat (4.1.12) and it worked *just fine*. Sorry Eddie - next time test outside of the IDE before I assume something is up. What a Eddie PITA. There's something silly I'd like you to try, just as an experiment, if you can still get it to fail in NB. In ELHtmlTag.java, add just the following line: private static Class beanInfoClass = ELHtmlTagBeanInfo.class; and retest. -- === 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
Re: [struts-el] HTML taglib
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 Caused by: java.lang.NullPointerException Eddie at Eddie org.apache.struts.util.MessageResources.getMessageResources(MessageResources.java:577) Eddie at org.apache.struts.taglib.html.HtmlTag.clinit(HtmlTag.java:91) That seems to point to a problem in my ELHtmlTagBeanInfo class (I've noticed I get an error like this if I make a mistake in the PropertyDescriptor array). Unfortunately, the way the BeanInfo class is used, if you make a mistake in setting the PropertyDescriptor array, the stack trace doesn't even include the BeanInfo class. Unfortunately, I'm not having any trouble building, deploying, or running the strutsel-exercise-taglib, which is using that tag. Could you trace this in the debugger? I assume you've recently cvs updated? -- === 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
Re: Suggestions for placement of Struts-EL information in the use r gu ide?
Ted == Ted Husted [EMAIL PROTECTED] writes: Ted 10/18/2002 11:11:47 AM, Karr, David [EMAIL PROTECTED] wrote: 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. Ted No worries, when I'm done, I'm sure it will look like the other Development Guides =:0) I've finished committing rough drafts of the top-level, bean-el, logic-el, and html-el package.html files. They don't attempt to use any external links yet. -- === 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
Re: DO NOT REPLY [Bug 13787] New: - Struts-EL: Roles functionality of logic:present not in logic-el
Ted == Ted Husted [EMAIL PROTECTED] writes: Ted There's a request tag in Jakarta taglibs that supports isUserInRole (among other things), so I would suggest Ted that we go with three and refer people to taglibs for the missing functionality (still all in the family :0) Ted The role functionality is new in 1.1, and so people going from 1.0 to struts-el won't even miss it. Just so it's clear, I assume you're referring to a taglib in the Jakarta taglibs project, and NOT the JSTL. I'm a little hesitant to force some people using Struts-EL to include still another taglib in their set of taglibs. Not to mention one that is a little (just a little) further away from the mainstream than Struts and the JSTL. There will be a set of people upgrading from 1.0.2 to 1.1 who won't miss it, but beta versions of 1.1 have been stable for such a long time, I think the number of 1.1 users is larger than might be expected for a beta release. My only argument against creating logic-el:present is cleanliness, as all but one of the features of logic:present are available in the JSTL (not to mention that attaching role-checking features to logic:present just seems odd). However, when I look at it from a pragmatic viewpoint, I realize that's less important than simple convenience. -- === 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
Re: DO NOT REPLY [Bug 12027] - bean;size should throw clear exception if neither name or collection are set
bugzilla == bugzilla [EMAIL PROTECTED] writes: bugzilla DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG bugzilla RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT bugzilla http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12027. bugzilla ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND bugzilla INSERTED IN THE BUG DATABASE. bugzilla http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12027 bugzilla bean;size should throw clear exception if neither name or collection are set bugzilla [EMAIL PROTECTED] changed: bugzillaWhat|Removed |Added bugzilla bugzilla AssignedTo|struts- |[EMAIL PROTECTED] bugzilla|[EMAIL PROTECTED] | bugzilla --- Additional Comments From [EMAIL PROTECTED] 2002-10-19 01:30 --- bugzilla It's your baby now, David =:0) bugzilla [or mark it later if you've other fish to fry for 1.1.0] I do have other things to do, but I might be able to get this done. I'll leave it like this for now. -- === 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
Re: Suggestions for placement of Struts-EL information in the use r gu ide?
Ted == Ted Husted [EMAIL PROTECTED] writes:
Ted 10/18/2002 11:11:47 AM, Karr, David [EMAIL PROTECTED] wrote:
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.
Ted No worries, when I'm done, I'm sure it will look like the other Development
Guides =:0)
This may be obvious to you, but it occurs to me that although the main user
guide has individual links to the HTML, Logic, and Bean libraries, I
think it would be odd to also have links from the same place to HTML-EL,
Logic-EL, and Bean-EL. It would be better to replace that with a link to a
page that covers Struts-EL, which would then have links to the HTML-EL,
Logic-EL, and Bean-EL descriptions.
I'm written a package.html file at org/apache/strutsel which covers the
overview information, which I haven't committed yet. I'm intending to write
package.html files in org/apache/strutsel/taglib/{bean,html,logic}. I
think those would be the appropriate pieces, you can figure out how we can link
them together :) .
I think it's important for this documentation to cover not only the Struts-EL
tags, but also the Struts tags which were NOT ported to Struts-EL, and which
JSTL tags and functionality can be used instead. Presently, I'm putting this
information into the package.html file at org/apache/strutsel, as opposed
to in the information for each taglib. I'm not sure which is the better
approach.
--
===
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
Re: Suggestions for placement of Struts-EL information in the user gu ide?
Ted == Ted Husted [EMAIL PROTECTED] writes: Ted You probably want to start with a Developers Guide as we have for the other taglibs. Ted http://jakarta.apache.org/struts/userGuide/dev_bean.html Ah, of course. This is the documentation generated from the struts-*.xml files. This is going to take some thought to figure out how to integrate into the user guide. I have the same basic data files in the struts-el directory, but I'm unsure how the generation process works. Even if we figured out how to generate the same kind of document tree in struts-el, we still have to figure out how to integrate the output into the main document. If we can't figure out a practical way to do this, it would be much easier to just add narrative sections to the main user guide. In the short run, it might be more practical to do this. -- === 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
Re: Suggestions for placement of Struts-EL information in the user gu ide?
Ted == Ted Husted [EMAIL PROTECTED] writes: Ted The API part is automatic. There's a stylesheet for the taglibs that lets Ant do all the work. =:0) Ted The other part is the package.html file, which the JavaDoc automatically bundles in as the description portion Ted on the cover page for the package 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
Re: Constructing Binary Distribution
James == James Mitchell [EMAIL PROTECTED] writes: James Anyone else having trouble running the dist target? James Mine is failing on the struts-el stuff (not compile error, but ant task James errors due to path settings and such), and I am working through it, but James wondering if I missed an email somewhere ?!?!?!? What is happening? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 12344] - Seems like you can only save ActionErrors in request scope...
bugzilla == bugzilla [EMAIL PROTECTED] writes: bugzilla DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG bugzilla RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT bugzilla http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12344. bugzilla ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND bugzilla INSERTED IN THE BUG DATABASE. bugzilla http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12344 bugzilla Seems like you can only save ActionErrors in request scope... bugzilla [EMAIL PROTECTED] changed: bugzillaWhat|Removed |Added bugzilla bugzilla Status|NEW |RESOLVED bugzilla Resolution||FIXED bugzilla --- Additional Comments From [EMAIL PROTECTED] 2002-10-13 01:09 --- bugzilla Fixed in nightly build 20021013. Thanks for the patch! This fix appears to address the ability to retrieve the errors from any scope. How do you get them into any scope but request? The Action.saveErrors() method doesn't appear to have an overloaded version taking a scope key. Also note that it would be good if any changes to how errors works would also be done in the messages tag, if they are compatible. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
checkbox name org.apache.struts.taglib.html.BEAN[0].stringProperty?
I've been adding more exercises to the Struts-EL exercise-taglib app, and I'm
finding some behavior I don't quite understand.
In the same JSP page, I have two logic-el:iterate loops, both of which
iterate through the same collection, the page attributes map (${pageScope}).
One loop has an html-el:button in each iteration, and the other has a
html-el:checkbox. Both of them set the indexed property to true (${!empty
pageScope} is always true). After seeing the generated HTML, I'm certain that
I'm unsure what I should expect for the name attribute in the generated HTML.
This is the button loop:
logic-el:iterate collection=${pageScope} id=item
html-el:button property=stringProperty indexed=${!empty pageScope}/
/logic-el:iterate
And this is what it generates for the first iteration:
input type=button name=stringProperty[0] value=Click
This is the checkbox loop:
logic-el:iterate collection=${pageScope} id=item
html-el:checkbox property=stringProperty indexed=${!empty pageScope}/
/logic-el:iterate
And this is what the first iteration generates:
input type=checkbox name=org.apache.struts.taglib.html.BEAN[0].stringProperty
I have a small feeling that the placement of the [0] is expected, but I'm
pretty sure the odd bean name is unexpected.
Could someone help me understand what I should expect here, and what might be
going wrong if this is incorrect? If I know what I SHOULDN'T be seeing, I
could try to track it down a little more.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Need help figuring out how I broke Struts-EL unit tests
David == David M Karr [EMAIL PROTECTED] writes:
David I could use a hand figuring out what I did to break my Struts-EL unit test
David process.
David I decided to get back to building some more unit tests for Struts-EL tags,
but
David when I tried to do the first run, I noticed some problems. Note that I DID
David test this before committing the initial library. It really did work.
David Here's the shell output that I get (I'll try to elide some stuff):
David --
David start.tomcat.40:
David java.io.FileNotFoundException:
c:\Tomcat4.0\target\test\servers\tomcat40\conf\server.xml (The system cannot find the
path specified)
David at java.io.FileInputStream.open(Native Method)
David at java.io.FileInputStream.init(FileInputStream.java:103)
David at java.io.FileInputStream.init(FileInputStream.java:66)
David at
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69)
Well, I got this to work, but I have to figure out if I have the best
solution. Apparently the value of build.home has to be an absolute path.
When I copied the base Struts build.xml file, I had changed the value of
${basedir}/target to just target. Temporarily, I changed this to
${basedir}/contrib/struts-el/target, and that makes it work. I don't think
that's the best solution, however.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Need help figuring out how I broke Struts-EL unit tests
I could use a hand figuring out what I did to break my Struts-EL unit test process. I decided to get back to building some more unit tests for Struts-EL tags, but when I tried to do the first run, I noticed some problems. Note that I DID test this before committing the initial library. It really did work. Here's the shell output that I get (I'll try to elide some stuff): -- [WONDARK;] ant test.tomcat.40 Buildfile: build.xml skip.tomcat.40: init: - jakarta-struts-el 1.0 - java.class.path = c:\jakarta\jakarta-ant-1.5\lib\xml-apis.jar;c:\jakarta\jakarta-ant-1.5\lib\xercesImpl.jar;c:\jakarta\jakarta-ant-1.5\lib\optional.jar;c:\jakarta\jakarta-ant-1.5\lib\junit.jar;c:\jakarta\jakarta-ant-1.5\lib\catalina-ant.jar;c:\jakarta\jakarta-ant-1.5\lib\ant.jar;c:\j2sdk1.4.0\lib\tools.jar;c:\j2sdk1.4.0\lib\tools.jar java.home = c:\j2sdk1.4.0\jre user.home = C:\Documents and Settings\dkarr struts.jar = c:/cygwin/home/dmkarr/work/jakartacvs/jakarta-struts/dist/lib/struts.jar struts-el.jar = ../jakarta-struts/dist/lib/struts-el.jar prepare.library: compile.library: Transforming into C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\contrib\struts-el\target\library test.tomcat.40: tomcat.home.40 = c:/Tomcat4.0 init: prepare.test: Created dir: C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\contrib\struts-el\target\test\classes Created dir: C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\contrib\struts-el\target\test\servers Created dir: C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\contrib\struts-el\target\test\lib compile.test: Compiling 16 source files to C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\contrib\struts-el\target\test\classes Copying 2 files to C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\contrib\struts-el\target\test\classes prepare.test.war: Copying 1 file to C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\contrib\struts-el\target\test\lib Building war: C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\contrib\struts-el\target\test\test.war prepare.test.tomcat.40: Created dir: C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\contrib\struts-el\target\test\servers\tomcat40\webapps Created dir: C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\contrib\struts-el\target\test\servers\tomcat40\conf Copying 1 file to C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\contrib\struts-el\target\test\servers\tomcat40\webapps Copying 1 file to C:\cygwin\home\dmkarr\work\jakartacvs\jakarta-struts\contrib\struts-el\target\test\servers\tomcat40\conf test.tomcat.40: start.tomcat.40: java.io.FileNotFoundException: c:\Tomcat4.0\target\test\servers\tomcat40\conf\server.xml (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:103) at java.io.FileInputStream.init(FileInputStream.java:66) at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69) at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:148) at java.net.URL.openStream(URL.java:955) at org.apache.xerces.readers.DefaultReaderFactory.createReader(DefaultReaderFactory.java:149) at org.apache.xerces.readers.DefaultEntityHandler.startReadingFromDocument(DefaultEntityHandler.java:493) at org.apache.xerces.framework.XMLParser.parseSomeSetup(XMLParser.java:314) at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:1097) at org.xml.sax.helpers.XMLReaderAdapter.parse(XMLReaderAdapter.java:223) at javax.xml.parsers.SAXParser.parse(SAXParser.java:314) at javax.xml.parsers.SAXParser.parse(SAXParser.java:253) at org.apache.catalina.util.xml.XmlMapper.readXml(XmlMapper.java:228) at org.apache.catalina.startup.Catalina.start(Catalina.java:725) -- Note that there is no c:/Tomcat4.0/test directory. Fortunately, I kept around the old directory where I did the initial Struts-EL work in, before I put it in CVS. When I run the same test there, it works fine. The build* files are almost identical between the old version and the CVS version. Any particular local configuration files that might shed some light? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Funny one: accesskey on html:hidden
This is funny. The HTML spec says that the input tag can have an accesskey attribute. It doesn't say anything about any particular subtypes of input, like hidden. The Struts code dutifully supports this attribute on html:hidden. Yes, I'm easily amused. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Nested taglib with EL?
Arron == Arron Bates [EMAIL PROTECTED] writes: Arron As for the EL, the property property should probably be left alone, but EL Arron working on value evaluations and such would be groovy. Looking at how Dave's Arron done the struts-el so far, it's just like what I produced for the nested tags Arron (using the extension), so it could happen. The evaluation of the property Arron property would have to happen before the nested tag works out what it's doing Arron in relation to the parent tags. EL on the property property would be dicey as Arron it would have to evaluate exactly to the nested reference. I don't feel like Arron being tech support for that one. :) I'm not certain yet, but I'm pretty sure that each of the nested tag classes would look almost exactly the same as all of the Struts-EL classes. I just process all of the attribute values through the EL engine before calling the base doStartTag(). There's not much more to do. The only wrinkle comes in if the type of the attribute in the base class is not String, int, boolean, or float. Then I have to write a BeanInfo class, as the attribute in the -el class has to be a String (int, boolean, and float are apparently automagically translated). This doesn't happen very often. The only cases in Struts-EL occurred with collection attributes. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Process for checking in files and resolving bugs
Outside of adding a reasonable checkin comment, is there some other process or information that is needed when I'm checking in files? I noticed that when I try to use the internal cvs interface in XEmacs, I'm unable to complete the commit process (gnuclient's connection gets reset by peer), although this might be some problem with XEmacs and/or gnuserv. I have no problem checking files out with this interface. When I do try to submit using this interface, the buffer gets filled in with some comments, like saying that I should fill in a PR number, which I would guess is the bugzilla problem report number. When I do this submit in WinCVS (as I can't get it done with XEmacs), the checkin comments buffer doesn't show that information. I'm not certain exactly what initializes that buffer. With respect to any bug number that I'm submitting code against, what is a reasonable process for verifying the bug is fixed so I can resolve it? I can easily test it in my distribution, but do I have to install and test it in the next nightly build, or what? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html ELRadioTag.java
Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig On 3 Oct 2002 [EMAIL PROTECTED] wrote: Date: 3 Oct 2002 05:00:47 - From: [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-struts/contrib/struts-el/src/share/org/apache/strutsel/taglib/html ELRadioTag.java dmkarr 2002/10/02 22:00:47 Modified:contrib/struts-el/src/share/org/apache/strutsel/taglib/html ELRadioTag.java Log: Uncommented onmousemove, onmouseout, and onmouseover attribute handlers, as I found the base tag was properly handling these. The onmouseup handler is still commented out, as the bug in the base tag isn't fixed yet. Craig You're more than welcome to fix the bug in the base tag :-). I thought it was likely I would do this, I just wanted to get the bug logged first. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- 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
craigmcc == craigmcc [EMAIL PROTECTED] writes: craigmcc craigmcc2002/10/01 18:50:13 craigmcc Modified:.build.xml craigmcccontrib/struts-el build.xml craigmcc Log: craigmcc Update the main build.xml file to include struts-el in the new contrib craigmcc directory, so that the binaries will be included with nightly builds. Oh, yeah, I forgot about that :) . That'll be sort of important. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- 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
craigmcc == craigmcc [EMAIL PROTECTED] writes: craigmcc craigmcc2002/10/01 18:50:13 craigmcc Modified:.build.xml craigmcccontrib/struts-el build.xml craigmcc Log: craigmcc Update the main build.xml file to include struts-el in the new contrib craigmcc directory, so that the binaries will be included with nightly builds. After thinking about this for a bit, I wonder exactly how this will work. The Struts-EL build requires a build.properties file, just like the top-level build. Will someone create that manually, or what? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- 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
Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig On 1 Oct 2002, David M. Karr wrote: Date: 01 Oct 2002 21:14:26 -0700 From: David M. Karr [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-struts/contrib/struts-el build.xml craigmcc == craigmcc [EMAIL PROTECTED] writes: craigmcc craigmcc2002/10/01 18:50:13 craigmcc Modified:.build.xml craigmcc contrib/struts-el build.xml craigmcc Log: craigmcc Update the main build.xml file to include struts-el in the new contrib craigmcc directory, so that the binaries will be included with nightly builds. 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). How do you want to handle this, then? Should it be conditional at the top-level build, or in the struts-el build? It seems like it might be easiest to add a 'if=jstl.jar' to the dist.contrib target in the main build.xml. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- 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
Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig On 1 Oct 2002, David M. Karr wrote: Date: 01 Oct 2002 21:14:26 -0700 From: David M. Karr [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-struts/contrib/struts-el build.xml craigmcc == craigmcc [EMAIL PROTECTED] writes: craigmcc craigmcc2002/10/01 18:50:13 craigmcc Modified:.build.xml craigmcc contrib/struts-el build.xml craigmcc Log: craigmcc Update the main build.xml file to include struts-el in the new contrib craigmcc directory, so that the binaries will be included with nightly builds. 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? 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. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Struts-EL: Finished with copyright header and javadoc
I've finished adding the copyright header to all the java source files, and I've added some javadoc comments to each class, method, and attribute. In several tag classes in the HTML library, I have some attribute evaluations commented out, as I've discovered that these are attributes which the HTML 4.01 spec defines, but which are not covered in the current Struts tag, either because their TLD doesn't specify them, or the Struts tag doesn't properly emit them. I've noticed some of these have had bugs reported against them (some by me), but probably not all. One thing I want to do in the very near future is make sure all of these are logged (and maybe even fix them :) ). Is there some point where it would be worthwhile for me to write an [ANNOUNCEMENT] note in struts-user about Struts-EL, or should that wait until we get to a Struts release (1.1-b3, or 1.1)? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Location of STANDARD file header for Jakarta Struts java files?
Ok, this is probably silly, but is there a STANDARD header block that is supposed to be at the top of all Jakarta Struts source files? I just did a casual search, and I noticed that there are quite a few minor variations, sometimes in the Copyright string (even for the same year), and sometimes missing RCS tags, etcetera. Would it be reasonable to add a file like this, including the RCS tags (and added with -kb so they don't expand the tags), so compulsive people like me :) don't fret about what's really supposed to go here? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Done with initial commit of Struts-EL into contrib/struts-el
I'm done with the initial commit of the Struts-EL library. I had mentioned that I was going to add standard file headers before committing, but I decided I wanted to make sure it was all in before I made any more changes. I did verify that it still all built, and at least the unit tests completed. I'll start on making standardization changes tomorrow evening. Hopefully none of the changes I make in the next few days will have any real effect on the resulting code. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Details of cvs import for creating contrib/struts-el
David == David M Karr [EMAIL PROTECTED] writes: David Once I get various administrative details straightened out in my local David repository, is it reasonable to assume that I would move forward with creating David a contrib directory containing the contents of my attachment to the David Struts-EL enhancement request (#12365)? David If so, I could use a little help with figuring out exactly how to properly do David the cvs import. David I assume the module name and path would be jakarta-struts/contrib/struts-el. David I don't know what the vendor tag would be. David I don't know what the release tag would be. David Once I get the import done, I'll fix the bug about the missing conf/share David directory, and I'll proceed to add standard RCS fields, file headers, and David relatively standard javadoc comments. David Once I finish those steps, I think it should be ready to commit, unless someone David can point out something else I should do before I commit. I really could use some help with this. I use CVS every day, but I haven't used cvs import in a long time. I'm not sure what the vendor tag or release tag would be. I'm reasonably sure my module name and path would be jakarta-struts/contrib/struts-el. Once I get the import done, I can proceed with standard headers and etceterata, and hopefully commit this. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Details of cvs import for creating contrib/struts-el
Martin == Martin Cooper [EMAIL PROTECTED] writes: Martin Hi David, Martin Sorry for not responding sooner. Yes, jakarta-struts/contrib/struts-el is Martin the appropriate place to check this in. Martin Personally, I try to avoid the use of 'cvs import' in an existing project, Martin because it has its own weird ideas about version numbering (related to the Martin vendor and release tags you mentioned). If I were you, I would check in what Martin you have using the regular 'cvs add' and 'cvs ci' commands, rather than Martin using 'cvs import'. I know it can be a bit of a pain to add the directories Martin and files this way before checking in, but the end result usually appears to Martin be more an integral part of the top level module. Sigh. I can deal with that. It's only 130 files. It'll just take me a minute to figure out how to script the cvs add :) . Martin I have not looked at your attachment to Bugzilla #12365, but it would be a Martin good idea to make sure that the ASL header is in the sources files before Martin committing them. Yes, I was going to add the file headers before committing, along with at least basic javadoc. I assume I can just copy the header from one of the Struts source files? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Struts-EL: Status and moving forward
I've gotten to the point with my Struts-EL contribution that I'd like some advice on how I can move forward with finalizing this. I've finished the code for all the tags, except I have to put in any required standard headers and add javadoc (and I'd like to know what is really needed here, from a Jakarta policy point of view), although there's really not much to the code that is novel at all. With some work (including an extension or two to the taglib XML descriptor), the code for the tags could be generated. The only tag where I've added (none removed) an attribute is the logic-el:match tag, where I've added an expr attribute, to take an EL value, as opposed to getting the value to compare from a cookie, header, bean property, or request parameter. I've finished converting all the original pages from the exercise-taglib, and I've added one other, and added a Show Source feature for all the tests. I've built a set of Cactus unit tests, covering many of the tags, but there's still quite a few which haven't been covered yet (the original Struts tests hardly cover any). I'm almost done with writing a README file that explains the purpose of the library, and details some of the porting decisions, which is a list of the original Struts tags which I did NOT port to Struts-EL (because JSTL covers their functionality). My current work isn't in CVS, and is based on the 1.1-b2 code base. I'd like to get this out there in the hands of people who can use it, and who can help to evolve it forward. Advice? Help? Direction? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Question about proper taglib URI for Struts-EL libraries
I'm starting to work through some production details for the Struts-EL library. I've finished the library code, and I'm filling out the webapps and the unit tests. I still have to write some documentation in the info element of the taglib element for each library, mostly explaining how it works, and a table listing the Struts tags that are NOT implemented, and what JSTL tags supplant them. I haven't put this work into my local CVS yet, but I will before I submit this for a real review. One little detail that I'm uncertain about is the uri element in the taglib element in the taglib description file. For instance, the value for the html library is: http://jakarta.apache.org/struts/tags-html-1.0 Should I change this to something else, like (the end) to tags-html-el-1.0? I'm not exactly certain what purposes this value is applied to. If that's just a symbolic value that will be used as the taglib URI, and it doesn't have to really exist, then that'll probably be fine. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Status on Struts-EL
the user would wrap with ${ and }, and would be
used as the element value, in the context of the explicit or implicit bean.
The property attribute would still be used as the HTML name attribute. If
the elproperty attribute was not present, the behavior would be as it was
before.
Along with these ideas, I did realize another completely different strategy for
building this library. Instead of trying to change how it works under the
covers, I could simply implement a tag library that exactly matches the Struts
tag libraries, but all of whose attributes are evaluated with the EL engine.
The internal behavior of the name, property pairs would be unchanged, but
attribute values could be specified as EL expressions in addition to, or
instead of, rtexprvalues. This would clean up the nasty code I've seen people
write to assemble an on... attribute value from pieces. I believe this only
becomes a slight implementation difficulty for attributes whose type is not
String or boolean, like the collection attribute of some tags. Since from
the point of view of JSP, an EL expression is just a string, that wouldn't map
directly to a javabeans set method that takes a Collection. In these cases, I
believe I'd have to implement a BeanInfo class that specifies a method in my
subclass, like setCollectionExpr() or something like that, which I can map
into the base class setCollection() method.
I'd appreciate any useful comments or suggestions.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts-EL: Ideas about name and indexed name attributes?
See comments below.
Jing == Jing Zhou [EMAIL PROTECTED] writes:
Therefore, I would say that html-el:text (and similar tags) wouldn't
Jing have a
name or indexed attribute. The property attribute (as I described
earlier) would be used both to get the current value and to specify the
Jing request
parameter name. The current meaning of the value attribute should still
apply (overrides the property attribute for the current value).
Jing There could be a way to enhance the current html tags while keeping the
Jing semantics of name, property which is one of beautiful things
Jing in Craig's original thinking.
Jing Suppose we define EL based name, property by attributes
Jing _name, _property and initialize them to be null. Then we could have
Jing protected String _name = null;
Jing public void setName(String name) {
Jing this._name = name;
Jing }
Jing protected String _property = null;
Jing public void setProperty(String property) {
Jing this._property = property;
Jing }
Jing public int doStartTag() throws JspException {
Jing if (_name == null) {
Jing name = Constants.BEAN_KEY; // so we do not need to initialize name
Jing to be a non-null value any more
Jing } else {
Jing name = (String) ExpressionEvaluationManager.evaluate(name, _name,
Jing String.class, this, pageContext);
Jing if (name == null) {
Jing name = Constants.BEAN_KEY;
Jing }
Jing }
Jing if (_property == null) {
Jing // throw new JspException(error message) or keep it depends on
Jing particular tag implementations
Jing } else {
Jing property = (String) ExpressionEvaluationManager.evaluate(property,
Jing _property, String.class, this, pageContext);
Jing if (property == null) {
Jing // some decisions here
Jing }
Jing }
Jing ...
Jing // make sure all RequestUtils.lookup will see only evaluated name,
Jing property, scope
Jing Object value = RequestUtils.lookup(pageContext, name, property, null);
Jing }
Jing Sometimes ago, I was trying to figure out if I could have a compact
Jing attribute which
Jing combine name/property/scope altogether when I design my UI. When I saw above
Jing possibility, I feel it is not a good idea to combine them into one
Jing attribute, because:
Jing 1) The combined attribute could not provide enough additional power I could
Jing buy:
Jing End users could put a tag in multi-level loop like this:
Jing html-el:text name=some_name[${loop1Status.index}]
Jing property=p1[${loop2Status.index}].p2[${loop3Status.index}].p3 /
I guess you've partially lost me. Would the alternative for point (1) be:
html-el:text
property=some_name[loop1Status.index].p1[loop2Status.index].p2[loop3Status.index].p3/
?
Which are you saying is preferable?
(Will the ActionForm processing successfully parse that property value so the
value can be set in the ActionForm?)
Jing 2) If using combined attribute, I have to delemite the attribute into name,
Jing property
Jing again, which cost unnecessary CPU time and depend on end users correct
Jing input.
Jing I am very concerned about user experience: think about an UI for City,
Jing State, Zip code,
Jing How would you feel if a site give you only one text field to input the
Jing city, state, and zip code? It will depend on the end users to input them in
Jing correct
Jing order with correct delimiters, it also need developers to parse the
Jing attribute into
Jing correct tokens. It will not be a good UI design.
Sorry, I don't understand. I'm not sure what you mean by delemite the
attribute into name, property again. How does this depend on the end user's
correct input? Are you talking about the programmer, or the user of the
application?
Jing So in general I hope the community could come out a design that keeps the
Jing original
Jing beauty of Struts and even the design could enhance the current html tags
Jing without
Jing having to create a parallel library in the end (Did someone say that
Jing before?)
The only constant is change. There is movement towards using the JSTL. The
goal is to eventually have a Struts tag library that works cleanly with the
JSTL. This parallel library is only a transition strategy.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tags: write private init() method to init. vars from cons. and release
Craig == Craig R McClanahan [EMAIL PROTECTED] writes: I would rather avoid even having a private init() method -- I'd rather see us initialize all String-valued attributes to null in their declarations and in the reset() methods. Any place in the code we've previously depended on the default value should do explicit checks for null and modify their behavior accordingly. Do you have a good example of your other statement, about modifying the specified attribute values in the tag methods? I may have seen that, but I want to be sure I know what you're referring to. I've fixed them as I've seen them, so don't know of any offhand -- but I would review the most complicated tags like html:form first. If you see something like this.foo = ... in a tag's doStartTag() or doEndTag() method, that is a danger sign. I guess I'll file a report if I see a case like that. The MessageTag class is an interesting case. It inits bundle and locale to null, but sets them to non-null values in release(). The references to them, in doStartTag() (which don't use the accessor methods, by the way), don't check for null. However, the method that it sends them to, RequestUtils.message(), does check for null. There's probably lots of cases like this that still work, even though release() leaves them in a different state than initial construction. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Quick guide to using debug logging in unit tests?
Could someone give me a concise pointer to figuring out exactly how logging would work in unit tests built like the Struts tags unit tests? I'm using LogFactory to get a Log and calling log.debug(...), but I realize that I'm unsure how I actually turn on logging, or control it (outside of code). Does LogFactory and Log have anything to do with the Logger element defined in the conf/test/server.xml file? I was hoping to use the SystemOutLogger class, so I could just see debugging output on stdout. I added a Logger element specifying this class (with a verbosity of 4), in ADDITION to the FileLogger. The result was that I saw lots more information coming to stdout, but not my log.debug(...) lines. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
MessageResources.messageKey(, foo) returns .foo?
I don't know if this is a bug or not. Even if it is, it might be awkward to change the behavior that I'm seeing. The method MessageResources.messageKey(Locale locale, String key) returns a message key with the locale key concatenated with the key, with a . between. If the locale string is the empty string, the returned message key begins with .. For instance, calling 'messageKey(., foo)' returns .foo. Is this really intended? I would think it would be more natural to not have the leading period if the locale string was empty. I noticed this while building unit tests for the Struts-EL errors tag, as I wrote a HashMapMessageResources class (with a getMessage() method essentially identical to PropertyMessageResources), so I can easily store test resources in memory, as opposed to using an external file. I had an error tag of error.misc, but in order to get this to work, I had to store a key of .error.misc in my MessageResources. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: MessageResources.messageKey(, foo) returns .foo?
Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig The messageKey() method is an internal utility, and the values it returns Craig are just used to cache messages uniquely -- given that they are not Craig publicly visible, it doesn't seem to be worth any extra processor time to Craig make them user-pretty. Craig If you're having to manually set the key to include this, your Craig HashMapMessageResources implementation probably isn't locale-dependent. Ah. I understand. I've adjusted my HMMR class to reflect this, so usage of it is a little clearer. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Any tool for directly formatting existing code in Apache form at?
Paul == Paul Kelly [EMAIL PROTECTED] writes: Paul There is gnu source code formatter called jalopy that seems to work ok - it Paul may be suitable for automating this Paul See http://sourceforge.net/project/showfiles.php?group_id=45216 I was just about to write a reply to myself saying that Jalopy works fine for this. It has some pretty interesting optional features, but it does exactly what I need out of the box. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tags: write private init() method to init. vars from cons. and release
Is there some reason the Struts custom tags have redundant initializations of their instance variables, once as implicit initializations, and once in the release() method? I hope that this code is either generated, or someone has carefully examined every single one to verify that the implicit init. value is identical to the value it's set to in release(). It would seem to me that a better strategy would be to write a private init() method which initializes all the instance variables to their initial state, and which is called from the release() method and a new no-args constructor (I would guess that none of the tags have a defined constructor). Is there a good reason for how this currently works? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tags: write private init() method to init. vars from cons. and release
Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig On 28 Jul 2002, David M. Karr wrote: Is there some reason the Struts custom tags have redundant initializations of their instance variables, once as implicit initializations, and once in the release() method? I hope that this code is either generated, or someone has carefully examined every single one to verify that the implicit init. value is identical to the value it's set to in release(). It would seem to me that a better strategy would be to write a private init() method which initializes all the instance variables to their initial state, and which is called from the release() method and a new no-args constructor (I would guess that none of the tags have a defined constructor). Is there a good reason for how this currently works? Craig It actually turns out that initializing to non-null values tends to get Craig you in trouble in containers that recycle tag instances -- we really need Craig to go through and rip that out (as well as the tendency to modify the Craig specified attribute values during doStartTag() or doEndTag(), which will Craig cause nothing but grief with optimizing page compilers. The issues with recycled tag instances is exactly why I was looking at this. I assume, by this statement, that you agree the current strategy isn't right? If so, I'll submit a bug for this. I plan on building a patch for this myself, but I'm not certain when I'll get to this. As I described, I would remove the implicit initializations, implement the init() method with the correct initializations, create a no-args constructor, and call the init() method from both release() and the no-args constructor. That should just take a few minutes to modify very tag :) . Do you have a good example of your other statement, about modifying the specified attribute values in the tag methods? I may have seen that, but I want to be sure I know what you're referring to. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Any tool for directly formatting existing code in Apache format?
Although I don't prefer this style for my own code, I'd like to facilitate making any code I contribute to Struts or related projects use the standard Apache coding format. Are there any tools for converting existing code to that format (including brace conversion)? Related to that, is there a predefined style in XEmacs that matches the Apache coding format? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts-EL: Ideas about name and indexed name attributes?
David == David M Karr [EMAIL PROTECTED] writes:
Jing == Jing Zhou [EMAIL PROTECTED] writes:
Jing The convention (see JSTL spec 2.2.1) is to use the name var for attributes
Jing that export information. As I do not think html-el:text/ should do any
Jing export
Jing things, we could simplify Craig's example as follows:
Jing c:forEach items=customers varStatus=status
Jing html-el:text property=customers[${status.index}].id/
Jing /c:forEach
Jing Where we are only interested in the current iteration index evaluated by
Jing an EL engine at run time and no changes are needed in the action codes.
David It's funny to have c:forEach iterate over a collection, but ignore the
item,
David which is essentially what's happening here. However, it does make sense
here.
David Just to summarize your example, the property attribute will be used in two
David different ways. It will be recursively wrapped by ${ and } and passed
to
David the EL engine to get the current value, and sent raw as the request
parameter
David name. By recursive, I mean that customers[${status.index}].id would be
David evaluated, resulting in (say) customers[2].id to get the request parameter
David value, and then wrapped with ${ and } to get the current value.
Jing Will it be possible to keep the semantics of name/property attributes
Jing and drop the indexed attribute when the EL engine is available?
David I'd like to be sure exactly what you're asking here. It's obvious that we
David wouldn't need to use indexed if we directly construct the index
expression,
David as in this example.
David The property attribute could have two different interpretations,
depending on
David whether the name attribute was present. The old meaning if name was
David present, and the new meaning if name is not present. The indexed
attribute
David could only be present if the name attribute was present.
I'm just thinking out loud here in case someone has any thoughts about where
I'm heading here.
I've realized that I can't use my strategy of having the behavior depend on
whether the name attribute is present. That's because there's already
conditional behavior that depends on that test, whether it checks the named
form bean or the default form bean.
Therefore, I would say that html-el:text (and similar tags) wouldn't have a
name or indexed attribute. The property attribute (as I described
earlier) would be used both to get the current value and to specify the request
parameter name. The current meaning of the value attribute should still
apply (overrides the property attribute for the current value).
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: upgrading to 1.1 nightly
dhay == dhay [EMAIL PROTECTED] writes: dhay Yep, saw that. dhay To override that method, then, do I have to subclass both ActionServlet (to dhay override getRequestProcessor()) and subclass RequestProcessor too? I thought dhay all this made it easier to plug stuff in? ;-) dhay Or am I missing something...? Look at the struts-config_1_1.dtd. You'll see a processorClass attribute in the controller element. This removes the need to subclass ActionServlet. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts-EL: Ideas about name and indexed name attributes?
Jing == Jing Zhou [EMAIL PROTECTED] writes:
Jing The convention (see JSTL spec 2.2.1) is to use the name var for attributes
Jing that export information. As I do not think html-el:text/ should do any
Jing export
Jing things, we could simplify Craig's example as follows:
Jing c:forEach items=customers varStatus=status
Jing html-el:text property=customers[${status.index}].id/
Jing /c:forEach
Jing Where we are only interested in the current iteration index evaluated by
Jing an EL engine at run time and no changes are needed in the action codes.
It's funny to have c:forEach iterate over a collection, but ignore the item,
which is essentially what's happening here. However, it does make sense here.
Just to summarize your example, the property attribute will be used in two
different ways. It will be recursively wrapped by ${ and } and passed to
the EL engine to get the current value, and sent raw as the request parameter
name. By recursive, I mean that customers[${status.index}].id would be
evaluated, resulting in (say) customers[2].id to get the request parameter
value, and then wrapped with ${ and } to get the current value.
Jing Will it be possible to keep the semantics of name/property attributes
Jing and drop the indexed attribute when the EL engine is available?
I'd like to be sure exactly what you're asking here. It's obvious that we
wouldn't need to use indexed if we directly construct the index expression,
as in this example.
The property attribute could have two different interpretations, depending on
whether the name attribute was present. The old meaning if name was
present, and the new meaning if name is not present. The indexed attribute
could only be present if the name attribute was present.
This would provide a transitional strategy, even while using the Struts-EL
library.
I'm still bouncing around these ideas in my mind. Any other affirmation or
rejection of these ideas would be useful, at least.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Status of Struts-EL contrib project
I had talked last week about building a tag library, composed of tags derived from the Struts tags, but which use the JSTL expression evaluation engine for attribute values, instead of using JSP rtexprvalues. I thought I would give you a little status on how I'm doing with this. I've finished the bean and logic libraries, and am now working on the html library. It's occurred to me that if I'm building a tag library that would be used alongside the JSTL, there's not much point in porting Struts tags that duplicate JSTL tag functionality. Therefore, most of the tags in the logic library aren't in my derived library. Part of the library documentation will cover this issue, and will detail exactly which Struts tags were not ported, and which JSTL tags cover their functionality. While building this, I decided to look at building unit tests for these tags. I thought this would be easy, as I could mutate the unit tests inside the Struts distribution. I was a little surprised to discover that there are actually very few unit tests for the Struts tags, just for logic:equal, logic:notequal, logic:present, and logic:notpresent. So, as another minor subproject to this, I'm experimenting with what I can do to build more complete unit tests for the Struts-EL tags. Almost all of what I'm doing here could be ported back eventually to the Struts unit tests. In particular, for the tags which generate HTML, I'm writing tests (and reusable support code) which verifies the generated output, including checking the attributes and their values which are present or not present in the output. This code uses JUnit, Cactus, and HTTPUnit, along with requiring JTidy, AspectJ, and Xalan. Except for Xalan, these all normally go along with HTTPUnit. I'm also going to look at slightly extending the XML files which describe the tag libraries, to include an element which indicates whether an attribute uses the EL engine for evaluation. This won't be used for generating the tag libraries, only for documentation generation. I'll provide more information as I get closer to completion (or what looks like completion to me). Any comments or questions? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Status of Struts-EL contrib project
Struts-dev == Struts-dev Newsgroup (@Basebeans.com) [EMAIL PROTECTED] writes: Struts-dev Subject: Re: Status of Struts-EL contrib project Struts-dev From: Vic C. [EMAIL PROTECTED] Struts-dev === Struts-dev It appears that only HTML tag would need conversion. ? Struts-dev I would think that logic and bean tag would be deprecated over time Struts-dev since there is JSTL equivalents as Craig mentioned before, if I recall. There are still some tags in the logic and bean libraries that don't have JSTL equivalents. Struts-dev Also, I have posted an example on sourceforge (basicPortal) of an JSTL Struts-dev for each tag with struts HTML for multi row update(it has a minor bug Struts-dev now - approve content page), should that be of use. I will continue to Struts-dev write realistic sample of using Struts with JSTL so should you need Struts-dev web app sample I will be incorporating what ever you post ASAP. Struts-dev Where would you post it? I'll take a look at at your code when I get a chance. Thanks for the pointer. You'll hear about it on struts-dev. Hopefully, it will be integrated into Struts as a contrib project. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Status of Struts-EL contrib project
Niall == Niall Pemberton [EMAIL PROTECTED] writes: Niall David, From your original post I assumed you were going to provide JSTL style Niall struts tags by incorporating the EL functionality of JTSL (I read Niall somewhere it was going to be split out from the JSTL, perhaps to commons) Niall with the main aim being that struts developers could use them now (with Niall Servlet 2.2 / JSP 1.1) and making the migration to JSTL much easier. From what you say below it seems the intention is to move the struts tags Niall which provide functionality that JSTL doesn't have to work in a compatible Niall way with JSTL. Niall Can you clarify this and are you just using the EL of JSTL or will your Niall ammendments need the whole of JSTL and require Servlet 2.3 / JSP 1.2? Hmm, I was not aiming for a Servlet 2.2 solution, but it's possible that could happen. As you suggested, I'm only implementing the Struts tags which provide functionality not in the JSTL. I'm implementing them by using the internal EL engine from the JSTL. If we were to try to get it work with Servlet 2.2, you would essentially have to use both sets of Struts tag libraries (and not use the JSTL tags at all). You would use this library to get the JSTL functionality, and the regular library to get the functionality I'm not porting. I believe that can work, although I'm not directly testing for that. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Struts-EL: Ideas about name and indexed name attributes?
In mapping Struts tags to Struts-EL, I'm wondering about the name attribute of the generated HTML for these tags, along with the property attribute of the custom tag, and indexed tags. In the current Struts library, in the checkbox tag, for instance, the strategy of setting the name and property attributes nicely flows the specified field values back into the specified actionform and property on the return trip. If the indexed attribute is set, it nicely builds an index reference, which will eventually cause the correct array/collection entry to be set. I'm thinking and thinking about how I can possibly map something like this to JSTL functionality, and I just don't see it. I was assuming that the name/property functionality would be mutually exclusive with the JSTL functionality, but in at least the HTML tags, where the name/property pair is used to build the HTML name attribute, I don't see how I can replace that. In the case of checkbox, the value attribute and others could still use the EL engine, just not the name/property functionality. Does anyone have any ideas about this? -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts-EL: Ideas about name and indexed name attributes?
Craig == Craig R McClanahan [EMAIL PROTECTED] writes:
Craig I've been thinking about this issue as well, as you might imagine.
Craig For general form field properties, I'm assuming that we would have to make
Craig the existence of the form bean explict -- say, for example:
Craig html-el:test var=${logonForm.username}/
Craig instead of assuming that you could just use username and know that it
Craig was resolved against the form bean in the surrounding scope. The property
Craig name can either be inferred from the expression (i.e. after the first
Craig period), or we could allow an optional property attribute that would
Craig provide the field name for the rendered input field.
I'm very hesitant to start parsing the EL string, as there's a lot of different
ways to form a legal expression, and I don't want to try to restrict the form
of the EL expression in these situations.
We could of course have the var attribute be an EL to get the current value,
and have the property attribute be the name attribute in the generated
HTML, but then you have a disconnect between the value and the name, whereas
the current name/property pair allows a clean specification of both the
current value and the request parameter name.
Craig For indexed things, remember that the subscript in an EL expression can be
Craig a variable. So something like this should work, where customers is an
Craig array of customer objects, and we're inside a form with a field per
Craig customer account number:
Craig c:forEach var=customer items=customers varStatus=status
Craig html-el:text var=${customer.id}
Craig property=customers[${status.index}]/
Craig /c:forEach
Craig could do the trick, as long as you scanned both the var and property
Craig attributes for expressions.
Yes, I had considered the array index possibility. This will provide more
flexibility, allowing the case of two nested iterate tags, and you want the
property attribute of the HTML tag to come from the OUTER iterate tag (which
someone on struts-user just asked about today).
However, in the general case, we're still having the users specify more, and
redundant information, just to avoid the use of the name/property pair.
I guess we could provide two ways to do this:
If the name attribute is present, the name and property are combined as
usual. However, if the var attribute is present, in place of the name
attribute, then the var value is used for the current value, and the
property attribute is used as the entire name attribute (of the generated
HTML).
(It's certainly confusing to have the name attribute mean two different
things, one in JSP, and the other in HTML).
Unfortunately, a change like this will require changing the base Struts tag.
In the case of CheckboxTag (and probably others), the current value lookup is
done directly in its doStartTag() method, with no comparison of value
against null check to bypass it (which is the case in other tags, like size
and message, for instance).
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subclass Struts tags to work with JSTL?
Tim == Tim Moore [EMAIL PROTECTED] writes: From: Martin Cooper [mailto:[EMAIL PROTECTED]] By the way, a good reason to use the name var for the n/p/s attribute is because that is what JSTL uses for the equivalent functionality. Consistency is good! ;-) Tim Well, I'm not sure that it is the equivalent functionality. From the Tim spec: The convention is to use the name var for attributes that export Tim information. So it's more like the id attribute, but it doesn't create Tim a scripting variable. There doesn't seem to be a standard attribute Tim name for the n/p/s equivalent...they just use a name appropriate to what Tim the action does. So c:out uses value, the conditional tags use Tim test, iterators use items. It seems like var should only be used Tim when you're creating in attribute in the scope specified by scope and Tim that perhaps value should be used when simply reading a property Tim (e.g., the form field tags). Along these lines, I agree that var is correct in place if id, but a more general statement about other situations is harder to make. Except for the id - var case, each one should be examined individually for what would make sense. Many of the attributes that would take EL values won't even have to have their name changed. For instance, the key attribute of bean:message is fine as it is. In the case of this tag, the name and property attributes wouldn't be needed in the EL library. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subclass Struts tags to work with JSTL?
Martin == Martin Cooper [EMAIL PROTECTED] writes: Martin Back around the time that Craig suggested the var attribute, I expressed a Martin preference for using parallel RT and EL taglibs: Martin http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg05792.html Martin As a recap, the reasons I prefer this approach are: Martin a) We can make any attribute that can accept an RT expr today accept an EL Martin expr. This will give us more flexible EL-enabled tags while not confusing Martin the user with a mixture of RT attributes and EL attributes on a single tag. Martin Of course, where the RT tags have n/p/s today, the EL tags would have a Martin var attribute instead. Martin b) It matches the approach taken by JSTL itself, with parallel RT and EL Martin taglibs. I certainly agree with this. That is how I'm proceeding with my experimental library, although in my preliminary work, I'm making struts-el.jar into an extension of struts.jar (requiring its presence), as opposed to being an entirely separate library. We should be able to release it as a standalone library later. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subclass Struts tags to work with JSTL?
Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig If we stay with the dual libraries approach, this all makes sense. Craig One thing we'll want to do *inside* the implementations is maximize the Craig reuse of the actual tag classes, to minimize the effort of keeping the two Craig libraries in synch. I wouldn't even be doing this if this wasn't easy to do :) . The most complicated code in each subclass will be in the evaluateExpressions() method, which is called from the derived doStartTag() method. Even that code will be mostly boilerplate. The more difficult cases will be where I really have to change what the base doStartTag() or doEndTag() methods do. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Subclass Struts tags to work with JSTL?
Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig On 16 Jul 2002, David M. Karr wrote: I don't know how much thought has yet gone into how Struts and JSTL can work together. I haven't noticed much serious talk about this. If these thoughts are obvious or ignorant, I apologize. Craig There hasn't been much talk about this on the lists. Part of that is me Craig trying to avoid succumbing to the pay attention to the cool new stuff Craig instead of getting 1.1 out the door :-). I definitely agree that people working on getting 1.1 out the door shouldn't spend any time on this. That's why it's good for me to look at this, as I'm not one of those people. It occurred to me that a straightforward interim solution would be to provide tag libraries named bean-el, html-el, etcetera. The actual tag classes would just be subclasses of the Struts tags. The way that the actual JSTL tag classes are implemented makes this very easy to do. Craig That would certainly be one way to do it. The other alternative I was Craig thinking of was to add a var attribute to each existing tag that Craig supported the name/property/scope tuple, and allow you to use either/or Craig with the same tag. Of course, that doesn't really cover cases like your Craig example of the message tag, where you might want to use EL expressions on Craig more than one of the attributes. I believe I remember you mentioning the var idea once, on this same subject. Although I think the name isn't quite right (the value can be an expression, not just a variable), I think this is also the correct approach for the name/property/scope tuple. In fact, these two strategies don't conflict. For properties which could map one-to-one to an EL value, what I did here would be fine. For things which are represented by the n/p/s tuple, we would add an attribute which would only be used when n/p/s is not used (perhaps checked in a TLV class), which would be an EL attribute. So, in the case of the derived message tag, instead of allowing EL values for name, property, and scope (which would probably be silly), we could have an (throwing out a name here) expr attribute to take the EL value. In fact, I spent about an hour this afternoon implementing and verifying a proof of concept (mostly spent updating my environment), adding a bean:el-message tag to my local CVS of Struts. For a P.O.C., it was easier to add the tag to the existing tag library, but for a real implementation, I would want a separate tag library. The code for the tag is very straightforward. My test derived from MessageTag, but it could just as easily (I believe) derive from NestedMessageTag. Craig I think this would be a cool contrib thing, if you wanted to work Craig the tags out and host it here. That's how the nested tags started, Craig IIRC. I will work this further and see how far I get. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Working with 1.1b1 (TC404b2), but can't find MESSAGE in latest CVS
I'm using Tomcat 4.0.4b2 with JDK 1.4.0. I have a small test application that I had working with 1.1b1. I decided to install the latest from CVS for struts and commons and work on building and using that, in preparation for testing some minor Struts additions. Without changing the application code, I changed the sets of jar files and tlds built in the WAR to use the set that I built from the latest CVS. When I run this newly built application, I get the following exception: javax.servlet.jsp.JspException: Exception forwarding for name main: javax.servlet.ServletException: Cannot find message resources under key org.apache.struts.action.MESSAGE at org.apache.struts.taglib.logic.ForwardTag.doEndTag(ForwardTag.java:180) at org.apache.jsp.index$jsp._jspService(index$jsp.java:77) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) [more] In my struts-config.xml, I have the following element: message-resources parameter=ApplicationResources/ In my WAR file, I have the following file: WEB-INF/classes/ApplicationResources_en.properties Note again that this was working in 1.1b1. So, did I miss something, or is this likely a bug? I didn't see any recent mention of this problem in either list. I tried changing the installed file to not have the locale suffix, but that had no effect. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: anyone care to clarify difference between struts and JSTL?
Craig == Craig R McClanahan [EMAIL PROTECTED] writes: Craig My advice to Struts users is as follows: Craig * If you're running on a Servlet 2.2 / JSP 1.1 container, you Craig will not be able to use JSTL (it requires Servlet 2.3 / JSP 1.2). Craig Go ahead and continue using the Struts tag libraries. Craig * If you're running on a Servlet 2.3 / JSP 1.2 container, you Craig should begin experimenting with JSTL. There is no problem in Craig using both JSTL and Struts tags in the same page (although, Craig obviously, the expression syntax is different). Craig * Over time, I plan to add a few features to the Struts tags to Craig ease migration to JSTL for the bean and logic libraries -- Craig for example, I want to support the same expression language, and Craig attribute names where that is possible. Craig * Longer term, I suggest that page developers plan on using the JSTL Craig tags in their applications, as quickly as it is feasible for you Craig to do so. But we're not going to throw away the existing Struts Craig tags any time soon, so they will continue to be available. Craig (One other note -- the expression language itself will become part of JSP Craig 1.3, so you'll be able to use it in template text as well as in custom tag Craig attribute values.) It would seem reasonable to consider doing what the JSTL implementors did, which is creating two sets of tag libraries, one using the EL, and one using scriptlets. As it's logical to assume that the default for the JSTL is the EL, and not RT, for each TLD, they created a -rt version and a non-rt version, which assumes the EL. In the case of Struts, you would probably want the default to be the RT library, and for the -el library to be optional. By making both of these available at the same time, it allows people to fully experiment with both alternatives. This would only be worthwhile during the transition. Later releases wouldn't need this. -- === David M. Karr ; Java/J2EE/XML/Unix/C++ [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: strust.taglib.bean proposal
Nicolas == Nicolas De Loof [EMAIL PROTECTED] writes:
NicolasString setterName = set
Nicolas + arg.substring(0,1).toUpperCase()
Nicolas + arg.substring(1);
Nicolastry {
Nicolas System.out.println(setterName +setterName);
Nicolas Method setter = parentTag.getClass().getMethod(
Nicolas setterName, new Class[] { String.class } );
Nicolas setter.invoke(parentTag,
Nicolas new Object[] {getBodyContent().getString()} );
I believe the functionality in this block is basically what
BeanUtils.populate() does, although with a little more overhead.
--
===
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Proposal: Add nameValue and checkedProperty to radio (and checkbox?)
I've often been frustrated by some details of the radio and checkbox tags. I have some issues with the rules for producing the name of the resulting element, and for deciding whether the component should be checked. I'd like to get some opinions on my proposed change. The crux of the problem is that the property attribute is overloaded for two purposes: 1. The name of the bean property to get the current value from. 2. The name attribute of the HTML component. Unfortunately, it's often desirable (IMHO) for those two values to be different. For instance, it seems conceivable that the bean used to populate the component would have two fields, one being a String, representing the option name, and the other being a boolean, indicating whether the option is on or not. It would be reasonable to name the boolean field enabled. However, using a boolean property of enabled means that the resulting radio button will have a name attribute of enabled, as opposed to something akin to the option name. I've modified my local copy of the Struts (1.0.1rc1) so that the radio tag has two additional attributes: nameValue If present, this will be the value of the name attribute in the resulting component. If not set, the value of the property attribute will be used. checkedProperty If present, the value of this property on the named bean will be compared with true to determine whether this component is checked. If not set, it will compare the value attribute against the value of the property property. I've tested this change in my environment and application, and it appears to work. The change is backward-compatible, because if neither of these two attributes are set, the behavior is the same as before. When I use these attributes, however, I'm able to use a reasonable property name for the checked property, and a reasonable name for the name of the HTML component. If I follow through with a patch for this, I'd obviously have to make similar changes in the checkbox and multibox component (although I'm not familiar with the latter component yet). I would assume I would also need to provide documentation and unit test patches. I would also make the patches against the latest in CVS, instead of the 1.0.1rc1 source release. What do you think? -- === David M. Karr ; Best Consulting [EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Proposal: Add nameValue and checkedProperty to radio (and checkbox?)
David == David M Karr [EMAIL PROTECTED] writes: David I've often been frustrated by some details of the radio and checkbox tags. David I have some issues with the rules for producing the name of the resulting David element, and for deciding whether the component should be checked. I'd like to David get some opinions on my proposed change. David The crux of the problem is that the property attribute is overloaded for David two purposes: David 1. The name of the bean property to get the current value from. David 2. The name attribute of the HTML component. David Unfortunately, it's often desirable (IMHO) for those two values to be David different. David For instance, it seems conceivable that the bean used to populate the component David would have two fields, one being a String, representing the option name, and David the other being a boolean, indicating whether the option is on or not. It David would be reasonable to name the boolean field enabled. David However, using a boolean property of enabled means that the resulting radio David button will have a name attribute of enabled, as opposed to something akin David to the option name. David I've modified my local copy of the Struts (1.0.1rc1) so that the radio tag David has two additional attributes: David nameValue David If present, this will be the value of the name attribute in the resulting David component. If not set, the value of the property attribute will be used. David checkedProperty Note that in my changes, I didn't change the property attribute, so it is still present and required. If both nameValue and checkedProperty are used, then property is ignored (even though it's required). However, it's never necessary to use BOTH nameValue and checkedProperty. Since I've divided the two purposes of property into two attributes, if you use one of the new attributes, you can still have property be used for the other of the two purposes. -- === David M. Karr ; Best Consulting [EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Building Struts 1.0.1rc1: Missing xalan
I'd like to experiment with some ideas for modifying the html:radio tag. Before I make changes, I'm first trying to build Struts1.0.1rc1 OOTB. The build.xml script talks about setting jdbc20ext.jar and servlet.jar, which I've done (pointing to my Tomcat4.0.1b2 distribution), but when I try to build it after setting those, I get the following (excerpts): DEPRECATED - xslp processor is deprecated. Use trax or xalan instead. java.lang.NoClassDefFoundError: org/apache/xalan/xslt/XSLTProcessorFactory java.lang.NoClassDefFoundError: com/kvisco/xsl/XSLProcessor So, apparently it needs Xalan too. Was the information about this accidently left out of the build.xml prolog? What version of Xalan is required, and how exactly do I make it available to the build script? Is it just supposed to be in the CLASSPATH (I sort of doubt this)? -- === David M. Karr ; Best Consulting [EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
