Re: Planning for 1.1 beta 2
Craig R. McClanahan wrote: I think the basic Struts download needs at least an initial walkthrough on all of the technologies it provides. Much a I'd love to be lazy and rely on the incredible amount of effort others have put into this :-), we can't just have nothing. I could do an encylopedia-style paragraph about each of the technologies enumerated at the top of http://jakarta.apache.org/struts/userGuide/introduction.html and then move the rest of the page into another section. That would at least clearly define our terms. Much more than that, and we'd start to cover the same ground as the Web Services Tutorial http://java.sun.com/webservices/docs/1.0/tutorial/index.html -- Ted Husted, Husted dot Com, Fairport NY US -- Java Web Development with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Planning for 1.1 beta 2
I started a Core Technologies page that we could insert before the Introduction as Chapter zero. These gives a brief description of each of our enabling technologies and links elsewhere for more detail. If we wanted to add more detail later, it would be easy to expand on this page. http://jakarta.apache.org/struts/userGuide/technologies.html I only did the first three this morning, but should be able to do the rest tonight. -T. Ted Husted wrote: I could do an encylopedia-style paragraph about each of the technologies enumerated at the top of http://jakarta.apache.org/struts/userGuide/introduction.html and then move the rest of the page into another section. That would at least clearly define our terms. Much more than that, and we'd start to cover the same ground as the Web Services Tutorial http://java.sun.com/webservices/docs/1.0/tutorial/index.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Planning for 1.1 beta 2
+1 for me Craig R. McClanahan wrote: I'd like to continue swatting the remaining bugs in 1.1, and improve the existing documentation, with a goal to release a beta 2 of Strust 1.1 in the near future (ideally by July 8 or so). Part of my motivation for the timing is that Sun is shutting down next week, so I will have some quality time hours available when I'm actually awake :-). Are the other committers interested in working towards such a goal? One thing I'd like to add to the TODO list is a review of all our custom tag implementations versus the JSP spec requirements -- particularly in the area of tag pooling and when the bodyContent can be accessed. The recent work on Jasper2 (in Tomcat 4.1.x), which will support tag pooling, has indicated we probably have some tags that don't completely conform to the contracts -- and we need to fix that before any final release. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Planning for 1.1 beta 2
+1 and more than happy to help with bugs and docs. -james [EMAIL PROTECTED] http://www.jamesholmes.com/struts/ --- Craig R. McClanahan [EMAIL PROTECTED] wrote: I'd like to continue swatting the remaining bugs in 1.1, and improve the existing documentation, with a goal to release a beta 2 of Strust 1.1 in the near future (ideally by July 8 or so). Part of my motivation for the timing is that Sun is shutting down next week, so I will have some quality time hours available when I'm actually awake :-). Are the other committers interested in working towards such a goal? One thing I'd like to add to the TODO list is a review of all our custom tag implementations versus the JSP spec requirements -- particularly in the area of tag pooling and when the bodyContent can be accessed. The recent work on Jasper2 (in Tomcat 4.1.x), which will support tag pooling, has indicated we probably have some tags that don't completely conform to the contracts -- and we need to fix that before any final release. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Planning for 1.1 beta 2
+1 on Beta 2 soon (although my company isn't shutting down next week :). +1 also on reviewing the tags. I fixed one or two of these a while ago - they showed up after I started using Resin 2.x - but there are likely more that I didn't stumble across. A systematic review would be good. Related to the tag issue, I had the thought that perhaps we should remove (almost) all of the release() implementations in the Struts tags. I think many people are confused about when release() is (supposed to be) called, and the implementations we have foster the belief that it will be called to reset property values between uses of a tag instance. Or would this be too drastic a change for now? -- Martin Cooper -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 11:05 AM To: [EMAIL PROTECTED] Subject: Planning for 1.1 beta 2 I'd like to continue swatting the remaining bugs in 1.1, and improve the existing documentation, with a goal to release a beta 2 of Strust 1.1 in the near future (ideally by July 8 or so). Part of my motivation for the timing is that Sun is shutting down next week, so I will have some quality time hours available when I'm actually awake :-). Are the other committers interested in working towards such a goal? One thing I'd like to add to the TODO list is a review of all our custom tag implementations versus the JSP spec requirements -- particularly in the area of tag pooling and when the bodyContent can be accessed. The recent work on Jasper2 (in Tomcat 4.1.x), which will support tag pooling, has indicated we probably have some tags that don't completely conform to the contracts -- and we need to fix that before any final release. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Planning for 1.1 beta 2
On Wed, 26 Jun 2002, Martin Cooper wrote: Date: Wed, 26 Jun 2002 11:49:49 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Planning for 1.1 beta 2 +1 on Beta 2 soon (although my company isn't shutting down next week :). +1 also on reviewing the tags. I fixed one or two of these a while ago - they showed up after I started using Resin 2.x - but there are likely more that I didn't stumble across. A systematic review would be good. Related to the tag issue, I had the thought that perhaps we should remove (almost) all of the release() implementations in the Struts tags. I think many people are confused about when release() is (supposed to be) called, and the implementations we have foster the belief that it will be called to reset property values between uses of a tag instance. Or would this be too drastic a change for now? Aside from the educational benefit (which I'm not sure that I really buy into), releasing object references when the page implementation calls release() would seem to be a good thing to do anyway. I'd rather point people to the spec (which, in JSP 1.2, has very clear lifecycle diagrams showing how it works, in section 10.1) and ensure that our tags take advantage of everything the spec lets us do to improve performance. -- Martin Cooper Craig -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 11:05 AM To: [EMAIL PROTECTED] Subject: Planning for 1.1 beta 2 I'd like to continue swatting the remaining bugs in 1.1, and improve the existing documentation, with a goal to release a beta 2 of Strust 1.1 in the near future (ideally by July 8 or so). Part of my motivation for the timing is that Sun is shutting down next week, so I will have some quality time hours available when I'm actually awake :-). Are the other committers interested in working towards such a goal? One thing I'd like to add to the TODO list is a review of all our custom tag implementations versus the JSP spec requirements -- particularly in the area of tag pooling and when the bodyContent can be accessed. The recent work on Jasper2 (in Tomcat 4.1.x), which will support tag pooling, has indicated we probably have some tags that don't completely conform to the contracts -- and we need to fix that before any final release. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Planning for 1.1 beta 2
Craig R. McClanahan wrote: Are the other committers interested in working towards such a goal? +1, I'll try to finish up the UML for classes. and put in place holders for the added package descriptions. Plus pitch in else where. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Planning for 1.1 beta 2
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 12:45 PM To: Struts Developers List Subject: RE: Planning for 1.1 beta 2 On Wed, 26 Jun 2002, Martin Cooper wrote: Date: Wed, 26 Jun 2002 11:49:49 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Planning for 1.1 beta 2 +1 on Beta 2 soon (although my company isn't shutting down next week :). +1 also on reviewing the tags. I fixed one or two of these a while ago - they showed up after I started using Resin 2.x - but there are likely more that I didn't stumble across. A systematic review would be good. Related to the tag issue, I had the thought that perhaps we should remove (almost) all of the release() implementations in the Struts tags. I think many people are confused about when release() is (supposed to be) called, and the implementations we have foster the belief that it will be called to reset property values between uses of a tag instance. Or would this be too drastic a change for now? Aside from the educational benefit (which I'm not sure that I really buy into), releasing object references when the page implementation calls release() would seem to be a good thing to do anyway. I was thinking that release() is only going to get called when the tag instance itself is going away, so those object references will be released also. But you're right, it doesn't hurt to do this. However, I think it would be good to make sure we set everything to null, rather than to literals or defined constants, so that it's clear we're not trying to reset to a known state. I'd rather point people to the spec (which, in JSP 1.2, has very clear lifecycle diagrams showing how it works, in section 10.1) and ensure that our tags take advantage of everything the spec lets us do to improve performance. Yes, I've pointed numerous people to the JSP 1.2 spec on exactly this issue. -- Martin Cooper -- Martin Cooper Craig -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 11:05 AM To: [EMAIL PROTECTED] Subject: Planning for 1.1 beta 2 I'd like to continue swatting the remaining bugs in 1.1, and improve the existing documentation, with a goal to release a beta 2 of Strust 1.1 in the near future (ideally by July 8 or so). Part of my motivation for the timing is that Sun is shutting down next week, so I will have some quality time hours available when I'm actually awake :-). Are the other committers interested in working towards such a goal? One thing I'd like to add to the TODO list is a review of all our custom tag implementations versus the JSP spec requirements -- particularly in the area of tag pooling and when the bodyContent can be accessed. The recent work on Jasper2 (in Tomcat 4.1.x), which will support tag pooling, has indicated we probably have some tags that don't completely conform to the contracts -- and we need to fix that before any final release. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Planning for 1.1 beta 2
On Wed, 26 Jun 2002, Martin Cooper wrote: Date: Wed, 26 Jun 2002 15:55:19 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Planning for 1.1 beta 2 -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 12:45 PM To: Struts Developers List Subject: RE: Planning for 1.1 beta 2 On Wed, 26 Jun 2002, Martin Cooper wrote: Date: Wed, 26 Jun 2002 11:49:49 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Planning for 1.1 beta 2 +1 on Beta 2 soon (although my company isn't shutting down next week :). +1 also on reviewing the tags. I fixed one or two of these a while ago - they showed up after I started using Resin 2.x - but there are likely more that I didn't stumble across. A systematic review would be good. Related to the tag issue, I had the thought that perhaps we should remove (almost) all of the release() implementations in the Struts tags. I think many people are confused about when release() is (supposed to be) called, and the implementations we have foster the belief that it will be called to reset property values between uses of a tag instance. Or would this be too drastic a change for now? Aside from the educational benefit (which I'm not sure that I really buy into), releasing object references when the page implementation calls release() would seem to be a good thing to do anyway. I was thinking that release() is only going to get called when the tag instance itself is going away, so those object references will be released also. But you're right, it doesn't hurt to do this. However, I think it would be good to make sure we set everything to null, rather than to literals or defined constants, so that it's clear we're not trying to reset to a known state. Except that we are ... even though the JSP page compiler doesn't know anything about it. And that's actually part of the problem. Our docs promise that some attributes will behave as if they have default values, which we've implemented by pre-initializing the corresponding property values. Everything works fine if tags aren't reused, or the tag implementation never modifies the values of the attributes set by the generated code of the page. However, if either of these conditions is violated, we're going to have problems with the wrong value the second time through the use of a tag instance, if the value was not set from the tag but was modified the first time through. That's a long winded way of saying I think I agree with Martin that we need to clear everything in release(). That also implies we need to establish a convention to establish the initial state of things -- perhaps by overriding setPageContext() which is guaranteed to be called each time. I'd rather point people to the spec (which, in JSP 1.2, has very clear lifecycle diagrams showing how it works, in section 10.1) and ensure that our tags take advantage of everything the spec lets us do to improve performance. Yes, I've pointed numerous people to the JSP 1.2 spec on exactly this issue. -- Martin Cooper Craig -- Martin Cooper Craig -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 11:05 AM To: [EMAIL PROTECTED] Subject: Planning for 1.1 beta 2 I'd like to continue swatting the remaining bugs in 1.1, and improve the existing documentation, with a goal to release a beta 2 of Strust 1.1 in the near future (ideally by July 8 or so). Part of my motivation for the timing is that Sun is shutting down next week, so I will have some quality time hours available when I'm actually awake :-). Are the other committers interested in working towards such a goal? One thing I'd like to add to the TODO list is a review of all our custom tag implementations versus the JSP spec requirements -- particularly in the area of tag pooling and when the bodyContent can be accessed. The recent work on Jasper2 (in Tomcat 4.1.x), which will support tag pooling, has indicated we probably have some tags that don't completely conform to the contracts -- and we need to fix that before any final release. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED
Re: Planning for 1.1 beta 2
For the docs, do you think it might be useful to add a new 1.1 section and march through the new features there, rather than patch the 1.0 docs? A 1.1 section might be easier to create, since we won't have to worry about segues, and will do double-duty as an upgraders guide. Of course, we could still go back and put in references to the 1.1 features in the appropriate places int the 1.0 chapters. Just thinking it might be easier if we don't have to fuss with splicing the narrative. Generally, I'd like to try and start reusing more of the JavaDocs in the User Guide. It seems to me that the User Guide should organize the presentation of the classes and add usage examples, but that our (meaning mostly Craig's =:0) JavaDocs are so good, maybe we should cutting and pasting more of those over, rather than writing the same thing in different words. Long term, this would also help keep things synched, since it would be easier to conform the guide to the JavaDocs (and vice versa). More like what we did with the Developers Guides, I guess, except that there would one(s) for the Action, Config, and Util classes. I don't want to get into that for the 1.0 User Guide now, but we could start on that path for the 1.1 chapter, and see how it goes. Meanwhile, I've set up a diff section in the release notes with pointers to every thing with 1.1 features or deprecations, that could then be used to help create the 1.1 doc section. http://jakarta.apache.org/struts/userGuide/release-notes.html#diff AFAIK, the JavaDocs are all updated with @since 1.1's now, and refer to execute rather than perform, and so forth. The ActionServlet docs may need to expand on the new flow, but otherwise we seem to be good on the JavaDoc front. The next thing I was going to do was finish-up on the release notes, so that everything linked in the diff section is mentioned above, and maybe trundle through the CVS mail log. -T. James Holmes wrote: +1 and more than happy to help with bugs and docs. -james [EMAIL PROTECTED] http://www.jamesholmes.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Planning for 1.1 beta 2
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 4:44 PM To: Struts Developers List Subject: RE: Planning for 1.1 beta 2 On Wed, 26 Jun 2002, Martin Cooper wrote: Date: Wed, 26 Jun 2002 15:55:19 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Planning for 1.1 beta 2 -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 12:45 PM To: Struts Developers List Subject: RE: Planning for 1.1 beta 2 On Wed, 26 Jun 2002, Martin Cooper wrote: Date: Wed, 26 Jun 2002 11:49:49 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Planning for 1.1 beta 2 +1 on Beta 2 soon (although my company isn't shutting down next week :). +1 also on reviewing the tags. I fixed one or two of these a while ago - they showed up after I started using Resin 2.x - but there are likely more that I didn't stumble across. A systematic review would be good. Related to the tag issue, I had the thought that perhaps we should remove (almost) all of the release() implementations in the Struts tags. I think many people are confused about when release() is (supposed to be) called, and the implementations we have foster the belief that it will be called to reset property values between uses of a tag instance. Or would this be too drastic a change for now? Aside from the educational benefit (which I'm not sure that I really buy into), releasing object references when the page implementation calls release() would seem to be a good thing to do anyway. I was thinking that release() is only going to get called when the tag instance itself is going away, so those object references will be released also. But you're right, it doesn't hurt to do this. However, I think it would be good to make sure we set everything to null, rather than to literals or defined constants, so that it's clear we're not trying to reset to a known state. Except that we are ... even though the JSP page compiler doesn't know anything about it. And that's actually part of the problem. Our docs promise that some attributes will behave as if they have default values, which we've implemented by pre-initializing the corresponding property values. Everything works fine if tags aren't reused, or the tag implementation never modifies the values of the attributes set by the generated code of the page. However, if either of these conditions is violated, we're going to have problems with the wrong value the second time through the use of a tag instance, if the value was not set from the tag but was modified the first time through. If the tag implementation (not including release()) modifies the values of properties, then yes, we're in big trouble. This is the case I've come across before. If I'm understanding you correctly, you're saying that release() also causes a problem by modifying the values. The only way I can see this would happen is if the container called release() and then reused the tag. At first, I thought this wasn't legal, but looking at the spec again, I see that it is in fact permitted. It wouldn't make much sense, performance wise, for a container to do that, but it could, so I guess we have to deal with it. That's a long winded way of saying I think I agree with Martin that we need to clear everything in release(). That also implies we need to establish a convention to establish the initial state of things -- perhaps by overriding setPageContext() which is guaranteed to be called each time. I don't think we can use setPageContext(), though, or setParent(), without some pain. As far as I can tell, the spec does not require that these be called before the attribute properties are set. If they are, then we could set the defaults there. However, if they're not, we'd have to keep track of which properties were set, so that we would know which ones not to meddle with. -- Martin Cooper I'd rather point people to the spec (which, in JSP 1.2, has very clear lifecycle diagrams showing how it works, in section 10.1) and ensure that our tags take advantage of everything the spec lets us do to improve performance. Yes, I've pointed numerous people to the JSP 1.2 spec on exactly this issue. -- Martin Cooper Craig -- Martin Cooper Craig -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 11:05 AM To: [EMAIL PROTECTED] Subject: Planning for 1.1 beta 2 I'd
Re: Planning for 1.1 beta 2
On Wed, 26 Jun 2002, Ted Husted wrote: Date: Wed, 26 Jun 2002 19:44:48 -0400 From: Ted Husted [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Planning for 1.1 beta 2 For the docs, do you think it might be useful to add a new 1.1 section and march through the new features there, rather than patch the 1.0 docs? I think a whats new tour in the release notes is certainly useful, but I'm not sure it makes sense to segregate the new stuff elsewhere. For example, in the building_controller.xml page, it makes sense to talk about the new exception handling options. A 1.1 section might be easier to create, since we won't have to worry about segues, and will do double-duty as an upgraders guide. Of course, we could still go back and put in references to the 1.1 features in the appropriate places int the 1.0 chapters. Just thinking it might be easier if we don't have to fuss with splicing the narrative. Generally, I'd like to try and start reusing more of the JavaDocs in the User Guide. It seems to me that the User Guide should organize the presentation of the classes and add usage examples, but that our (meaning mostly Craig's =:0) JavaDocs are so good, maybe we should cutting and pasting more of those over, or linking to them, since we know where the JavaDocs are compared to the user's guide. rather than writing the same thing in different words. Long term, this would also help keep things synched, since it would be easier to conform the guide to the JavaDocs (and vice versa). More like what we did with the Developers Guides, I guess, except that there would one(s) for the Action, Config, and Util classes. I'm pretty happy with how it worked out to double-duty the tag library developer's guides. The package.html for the non-tag-library packages could serve the same role for the Java programmer -- with the added benefit that even people who don't read documentation often look at the JavaDocs, so they have a better chance of seeing this stuff. I don't want to get into that for the 1.0 User Guide now, but we could start on that path for the 1.1 chapter, and see how it goes. Agreed -- I don't think we need to do anything other than critical bugfixes in 1.0. Meanwhile, I've set up a diff section in the release notes with pointers to every thing with 1.1 features or deprecations, that could then be used to help create the 1.1 doc section. http://jakarta.apache.org/struts/userGuide/release-notes.html#diff AFAIK, the JavaDocs are all updated with @since 1.1's now, and refer to execute rather than perform, and so forth. The ActionServlet docs may need to expand on the new flow, but otherwise we seem to be good on the JavaDoc front. The next thing I was going to do was finish-up on the release notes, so that everything linked in the diff section is mentioned above, and maybe trundle through the CVS mail log. Someplace, we definitely need discussions of dynamic form beans (probably in the building-the-view page) and sub-applications (either an expansion on configuring the controller or perhaps a page on advanced topics or some such. -T. Craig James Holmes wrote: +1 and more than happy to help with bugs and docs. -james [EMAIL PROTECTED] http://www.jamesholmes.com/struts/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Planning for 1.1 beta 2
See intermixed. On Wed, 26 Jun 2002, Martin Cooper wrote: Date: Wed, 26 Jun 2002 18:39:04 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Planning for 1.1 beta 2 -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 4:44 PM To: Struts Developers List Subject: RE: Planning for 1.1 beta 2 On Wed, 26 Jun 2002, Martin Cooper wrote: Date: Wed, 26 Jun 2002 15:55:19 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Planning for 1.1 beta 2 -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 26, 2002 12:45 PM To: Struts Developers List Subject: RE: Planning for 1.1 beta 2 On Wed, 26 Jun 2002, Martin Cooper wrote: Date: Wed, 26 Jun 2002 11:49:49 -0700 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Planning for 1.1 beta 2 +1 on Beta 2 soon (although my company isn't shutting down next week :). +1 also on reviewing the tags. I fixed one or two of these a while ago - they showed up after I started using Resin 2.x - but there are likely more that I didn't stumble across. A systematic review would be good. Related to the tag issue, I had the thought that perhaps we should remove (almost) all of the release() implementations in the Struts tags. I think many people are confused about when release() is (supposed to be) called, and the implementations we have foster the belief that it will be called to reset property values between uses of a tag instance. Or would this be too drastic a change for now? Aside from the educational benefit (which I'm not sure that I really buy into), releasing object references when the page implementation calls release() would seem to be a good thing to do anyway. I was thinking that release() is only going to get called when the tag instance itself is going away, so those object references will be released also. But you're right, it doesn't hurt to do this. However, I think it would be good to make sure we set everything to null, rather than to literals or defined constants, so that it's clear we're not trying to reset to a known state. Except that we are ... even though the JSP page compiler doesn't know anything about it. And that's actually part of the problem. Our docs promise that some attributes will behave as if they have default values, which we've implemented by pre-initializing the corresponding property values. Everything works fine if tags aren't reused, or the tag implementation never modifies the values of the attributes set by the generated code of the page. However, if either of these conditions is violated, we're going to have problems with the wrong value the second time through the use of a tag instance, if the value was not set from the tag but was modified the first time through. If the tag implementation (not including release()) modifies the values of properties, then yes, we're in big trouble. This is the case I've come across before. I thought we had caught all of those, but want to make very sure. For example, if the second use of a tag sets the same value for the same attribute on an instance being reused, the container has the right to assume that the previous setFoo() call is still in effect. If I'm understanding you correctly, you're saying that release() also causes a problem by modifying the values. The only way I can see this would happen is if the container called release() and then reused the tag. At first, I thought this wasn't legal, but looking at the spec again, I see that it is in fact permitted. It wouldn't make much sense, performance wise, for a container to do that, but it could, so I guess we have to deal with it. True ... and it would be our code that is making the incorrect assumptions, not the container. That's a long winded way of saying I think I agree with Martin that we need to clear everything in release(). That also implies we need to establish a convention to establish the initial state of things -- perhaps by overriding setPageContext() which is guaranteed to be called each time. I don't think we can use setPageContext(), though, or setParent(), without some pain. As far as I can tell, the spec does not require that these be called before the attribute properties are set. If they are, then we could set the defaults there. However, if they're not, we'd have to keep track
RE: Planning for 1.1 beta 2
If the tag implementation (not including release()) modifies the values of properties, then yes, we're in big trouble. This is the case I've come across before. I thought we had caught all of those, but want to make very sure. For example, if the second use of a tag sets the same value for the same attribute on an instance being reused, the container has the right to assume that the previous setFoo() call is still in effect. As far as I've seen the tags are quite clean. The nested tags went AWOL on Resin in a very interesting way because internal logic changes properties for the extended tag. Fixed by caching the values when the tag executes, and setting them back when the tag completes. The fact that these all work on Resin whould have to say something for the extended tag. The pessimistic cache/reset that the nested tags have to do can be taken to the super tags. When the tag completes, set them back and then it wouldn't matter what logic was in the tag, primed from a variation of a constant, internal logic or whatever. From where I sit it's absolute container compliance for the expense of a little object overhead. When the container gets around to the release all together, we can just set to nulls or initial constants. The container has to manage the sate of the tags it's made, this would assure the contract. No? Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Planning for 1.1 beta 2
Meanwhile, I've set up a diff section in the release notes with pointers to every thing with 1.1 features or deprecations, that could then be used to help create the 1.1 doc section. http://jakarta.apache.org/struts/userGuide/release-notes.html#diff AFAIK, the JavaDocs are all updated with @since 1.1's now, and refer to execute rather than perform, and so forth. The ActionServlet docs may need to expand on the new flow, but otherwise we seem to be good on the JavaDoc front. The next thing I was going to do was finish-up on the release notes, so that everything linked in the diff section is mentioned above, and maybe trundle through the CVS mail log. Someplace, we definitely need discussions of dynamic form beans (probably in the building-the-view page) and sub-applications (either an expansion on configuring the controller or perhaps a page on advanced topics or some such. What's your definition of a dynamic form bean?... I have some docco coming on how to make a complex bean with nested lists etc and how to make it properly with that new commons collection so that the bean isn't fully managed in the constructor and thus allowed to reside properly in request scope. People are constantly pushing their beans to the session because it's harder to build them with lists et al. Is this something what you're talking about?... Making concise docco type stuff for the site, and a tutorial hand-holder for my site. Unless Struts site wants more of this kind of stuff too?... Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Planning for 1.1 beta 2
On 27 Jun 2002, Arron Bates wrote: Date: 27 Jun 2002 14:33:11 +1000 From: Arron Bates [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Planning for 1.1 beta 2 Meanwhile, I've set up a diff section in the release notes with pointers to every thing with 1.1 features or deprecations, that could then be used to help create the 1.1 doc section. http://jakarta.apache.org/struts/userGuide/release-notes.html#diff AFAIK, the JavaDocs are all updated with @since 1.1's now, and refer to execute rather than perform, and so forth. The ActionServlet docs may need to expand on the new flow, but otherwise we seem to be good on the JavaDoc front. The next thing I was going to do was finish-up on the release notes, so that everything linked in the diff section is mentioned above, and maybe trundle through the CVS mail log. Someplace, we definitely need discussions of dynamic form beans (probably in the building-the-view page) and sub-applications (either an expansion on configuring the controller or perhaps a page on advanced topics or some such. What's your definition of a dynamic form bean?... Specifically, DynaActionForm. There's not a lot that needs to be said, but AFAIK we don't say anything at all in the docs at this point. I have some docco coming on how to make a complex bean with nested lists etc and how to make it properly with that new commons collection so that the bean isn't fully managed in the constructor and thus allowed to reside properly in request scope. People are constantly pushing their beans to the session because it's harder to build them with lists et al. Is this something what you're talking about?... Making concise docco type stuff for the site, and a tutorial hand-holder for my site. Unless Struts site wants more of this kind of stuff too?... I think the basic Struts download needs at least an initial walkthrough on all of the technologies it provides. Much a I'd love to be lazy and rely on the incredible amount of effort others have put into this :-), we can't just have nothing. Arron. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
