RE: Hello, all.
Christian, Glad to know your hear lurking! I think that was my original point when bringing up Barracuda. Struts can learn alot from Barracuda going forward. Each certainly has its' place of superiority but due to the focus of Barracuda being architecture which I've always thought it demonstratedThe intellectual mind share between the two projects can only be helpful for both! -Daniel -Original Message- From: Christian Cryder [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 9:26 PM To: Struts Developers List Subject: RE: Hello, all. Hi guys, Normally I just lurk here, but I did want to comment on a stmt pertaining to Barraucda. Barracuda is an impressive framework. It also has quite a powerful event model which struts lacks. The rendering seems tied to XMLC however. Barracuda, as its currently implemented _is_ tied to XMLC in two specific places: it uses XMLC to load the DOMs, and it uses XMLC to actually render the processed DOMs. But that's it - everything else is specific to the DOM api; we designed it that way intentionally. So decoupling from XMLC is fairly straightforward - you provide something to load the DOM, and you provide a renderer to actually stream the processed DOM back to the client. That's it. Now, we don't have another loader/renderer currently in the project, but that is on the todo list (Q1 2003 hopefully). it must be said from this experience that struts certainly doesnt tie you down to a particular view technology. :-) Just to be clear, Barracuda doesn't tie you to a particular rendering technology either; it is possible to use just the event model and to skip the component stuff altogether. Heck, you could actually probably use Barracuda as your controller and JSPs to render if you really wanted to. What Barracuda _doesn't_ try to do is make it any easier to JSP related stuff...if you need to use JSPs, then there are plenty of frameworks out there to consider (and Struts is certainly among the best I've seen). Struts is exciting because it has such momentum. Barracuda is exciting because it is the most complete MVC framework I've seen. I think this is a fair assessment (of course I'm biased ;-) Struts does have momentum, but the question is why? After all, MS's .NET stuff has momentum too... My point here is simply that momentum does not _necessarily/automatically_ mean something is good; coporate interests on both sides of the isle regularly try their hardest to generate momentum as a means to achieving developer adoption. This is particularly true of MS, but Sun does it too...there are many reasons that they have hitched their horses to the JSP wagon, but one of the major ones has to do with positioning against MS's ASP (not the architectural pro's/con's of JSP over and against other alternatives). Now, please note that I'm _not_ suggesting that all of Struts momentum has been manufactured; if you're stuck with JSP, then Struts is a lifesaver. The great thing about a project like Struts (and other open-source efforts) is that most of the growth comes from the community, rather than the industry; its driven from the grassroots. What I _am_ saying however, is that Barracuda was not created for the purpose of generating momentum (well, maybe that's what Lutris wanted). The primary focus of the developers involved, however, was to step back and say let's try really rethinking this whole problem space and see if we can come up with a way to really do it right. And so we evaluated all the other approaches we could find, and tried to learn from them, and tried to apply lessons learned from client-server development in a stated environment. But the emphasis was on architecture, not momentum. I've always felt that if Barracuda could get the architecture right, then it would make it much easier to build the type of RAD tool integration that made client server development so much easier, and that in turn would take care of any momentum issues. What actually amazes me is the measure of adoption Barracuda has already achieved, given the fact that we've still been focusing on architecture rather than ease of use. At any rate, I've digressed. Sorry to take up Struts bandwidth talking about Barracuda, but I think that both projects have good ideas and figure a little intellectual cross-pollination never hurt anyone. Cheers! Christian -- Christian Cryder [[EMAIL PROTECTED]] Internet Architect, ATMReports.com Barracuda - http://barracuda.enhydra.org -- Coffee? I could quit anytime, just not today -- 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: Hello, all.
Yep Glad everyone agrees. Personally I think Christian Cryder did a very impressive job. However design and elegance often aren't what matters at the end of the day. I'll contradict that with saying elegance always pays off! But who has written a book about Barracuda?... There are a few companies in the city that have evolved there one frameworks that are similar to Barracuda. I have used the good design from Barracuda to evalute the appropriateness of some of these approaches. Struts is exciting because it has such momentum. Barracuda is exciting because it is the most complete MVC framework I've seen. It is far beyond velocity, webwork and others that have been mentioned within this forum. I fully believe in time we'll have much of what is missing within struts. Let's keep being pragmatic and not over complicate the ease of use that got us excited in the first place and gradually evolve struts to scale to the most challenging environments that may need such things as action chains, component models and event models. -Daniel -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 9:43 PM To: Struts Developers List Subject: RE: Hello, all. Yep. Same decision I made. Im glad I went with struts. :-) -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 10:34 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: Hello, all. From: Andrew Hill [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: Hello, all. Date: Tue, 10 Dec 2002 10:17:26 +0800 Barracuda is an impressive framework. It also has quite a powerful event model which struts lacks. The rendering seems tied to XMLC however. Ive not used Barracuda myself so dont know how hard it would be to make it play with a different view technology. That said, using a DOM approach for rendering has substantial advantages. As it happens Im also using a non jsp DOM based rendering approach (not xmlc though) for the view in my struts app - and it must be said from this experience that struts certainly doesnt tie you down to a particular view technology. :-) btw Interesting to note that many of the things that struts lacks compared to frameworks such as Barracuda are addressed in the JSF spec - events, component models, etc... Im very much looking forward to Struts for JSF... /btw This is a direct result of Struts not trying to be everything to everyone. The main Struts functionality (action controller) is unlikely to become a standard as far as i can tell. So, Struts fits nicely into a comprehensive web framework composed of various standards and your own code. I'd much rather develop apps that use standards and appropriate toolkits like Struts than with something like Barracuda. -Original Message- From: Daniel Honig [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 04:59 To: Struts Developers List Subject: RE: Hello, all. In order to stick my head out so it can be cut off... Well I think that Struts rocks first off... But when you compare it to a framework like: http://barracuda.enhydra.org/ http://barracuda.enhydra.org/cvs_source/Barracuda/docs/what_the_heck_is_bar r acuda.html It seems clear to me that struts is not as elegant. Struts does not as clearly seperate M-V-C. Struts lacks a component model that Barracuda cleanly identifies. And I think this is fine. I wouldn't want to introduce Barracuda to alot of developer's because it is more complex. Struts is a simple way of achieving the same goal and pragmatism is one of the values I prize most in this profession. -Daniel -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Monday, December 09, 2002 11:58 AM To: [EMAIL PROTECTED] Subject: Re: Hello, all. You'll want to join the struts-user list to learn more about Struts and get help with any questions you might have. The struts-dev list is used by developers to discuss bugs, enhancements, and general topics concerning the framework's development. David From: Joseph Ottinger [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Hello, all. Date: Mon, 9 Dec 2002 11:45:14 -0500 (EST) Then enlighten me? I wouldn't have joined the list at all if I hadn't been interested in learning more. Dave had a substantive point, one I responded to. Where I erred once, I'm sure I can err again; I'm trying to prevent that if I can. On Mon, 9 Dec 2002, micael wrote: Joseph, you are making a fool out of yourself. You seem to have no idea how little you know. At 11:08 AM 12/9/2002 -0500, you wrote: On Mon, 9 Dec 2002, David Graham wrote: Joseph, I noticed you quoted me on your site but you left out the important point that Struts has never and will never dictate a model or view layer technology. Struts gives
RE: Removing the Consultants Page
I agree...How can this be done fairly? There are many opportunities for shameless self promotion. I don't think struts has to facilitate this... -Daniel -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 27, 2002 12:33 AM To: [EMAIL PROTECTED] Subject: Removing the Consultants Page I think Ted is in favor of dropping the Consultants page. I am as well and if you all agree then I think we should remove it. I'm personally tired of handling the requests for new links and policing the rules. David _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts logo
Well for whatever worth this comment may have... I think the last logo with the beer is the best of the logos on the page I've enjoyed the fact that when searching monster and other it-job sites for struts I'm presented with jobs requiring Auto Shop struts experience. Perhaps a logo that ties the two together is a good thing?... -dh -Original Message- From: edgar [mailto:[EMAIL PROTECTED]] Sent: Saturday, November 23, 2002 2:54 AM To: 'Struts Developers List' Subject: RE: Struts logo I agree but overall very original ;-}... -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 11:36 PM To: Struts Developers List Subject: RE: Struts logo +1 from me. I'm not an artist by any stretch of the imagination, so I won't be entering any proposals, but I'll sure enjoy seeing the results. Neither am I, but here's a few http://www.open-tools.org/struts-atlanta/images/new-logos/ I prefer the last one, but we might have a few legal issues to tackle first. The only potential caveat would be that any selected submission would need to be publishable under the standard ASF license agreement (same as the code and the docs). -emmanuel Craig -- James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens? - Seymour Cray (1925-1996), father of supercomputing -- 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: ChainAction class
I would just like to instigate some trouble along with this question since I am a big fan of the Chain Of Repsonsibility pattern and agree that it can do a nice job of creating atomic and reusable code structures. I would also like to say that I think it could be confusing to have a chain action. The example provided for invoking actions based on Locale is handled by implementing someone's own custom RequestProcessor. Fan of the COR pattern I may be but implementing a custom RequestProcessor seems cleaner. One problem if you implement COR is how do you assemble and execute chains? Where do you store this info? Servlet Filters offer another chance to implement COR. Perhaps I'm hallucinating again, but has craig talked about COR and Java Server Faces? I think its' great if the contribution doesn't hurt anything else and pending the design is good. But I think most cases for use in a COR environment can be handled other ways. COR is a nice way to redirect output streams for several transformations of the output stream. Say you had one action that read data from a database and output xml. You could continue to add chain processors until it outputs a PDF file. -Daniel -Original Message- From: Karl Baum [mailto:kbaum;Tallan.com] Sent: Tuesday, November 12, 2002 4:19 PM To: Struts Developers Lis Subject: ChainAction class Over the past year and a half, I have developed using the Struts platform. During this time, my colleagues and I created an Action class which allows other actions to be chained together. This design resembled the Chain of Responsibility pattern. The ChainAction class was well received by the many other developers on our project. Most importantly it helped keep our Action components simple and modular and promoted reuse in our code. In addition, the ChainAction class allowed for different Actions to be executed based on Locale. I have been benefiting from the Struts Model View Controller framework for some time and would like to contribute the ChainAction class to the framework. The addition of the ChainAction class would require no change to the existing Struts code base and would only offer Struts users an additional Action class implementation. I would like to gauge the interest other Struts developers have in this idea. Thanks. Karl -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Struts WML Tag Library
Chip, A couple of us have put together a canidate for this library already. My struts time has been 0 as of lateI'm out the door to a party here in manhattan, much apologiesPing me if I don't get the others e-mail addy's before the end of the weekend. -Daniel -Original Message- From: Chip Paul [mailto:chip;ethreatnet.com] Sent: Friday, November 01, 2002 10:26 PM To: [EMAIL PROTECTED] Subject: Struts WML Tag Library I'm currently in the process of converting existing and new customer sites into a mobile format. Since I used struts in doing the customer web sites, I thought I'd look into WML support for struts. After I saw that there was no current support, I starting hacking around in the html taglib, and just got a _basic_ version of wml based struts working. I think this is a really important part of the library, because the time savings of reusing all the server side code will quickly stack up for me at least. As I anticipate the resulting library to get more mature over the next few months, I thought I'd see about volunteering to add to the main taglib branch as I get my library working. I skimmed over most of the docs on that part of the site, but didn't find a clear cut email for whom to talk to, so I thought I should just post it to the list in case someone is already working on wml support. If there's noone currently working on it, I'd be interested in either signing up for it, or at least know whom I should send my lib to to get it integrated. My main focus is getting my own site up, so I imagine the library will be a tad rough by your standards - and to make matters worse I'm not overly knowledgable on the guts of struts itself, but I imagine both will work themselves out a bit as I delve in. At the very least, if it's on-topic, I'd like some guidance as I try to convert HTML-centric strutisms into their WML counterparts. Thanks in advance, Chip === Chip Paul, Lead Software Developer Ethreat Security Solutions, Inc. - http:///www.ethreatnet.com [EMAIL PROTECTED] Cell 256.479.5894 PGP Fingerprint: 47B0 8313 2F79 5DBD 87F7 3C5E 181B 76D4 49C2 B525 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Struts WML Tag Library
Yeah...This is the intent. I can get you the latest code but I've got two Irish lasses in chelsea who demand my time at the moment ;) I should remember to do this tommorow. -Daniel -Original Message- From: [EMAIL PROTECTED] [mailto:Kevin.Bedell;sunlife.com] Sent: Friday, November 01, 2002 10:35 PM To: Struts Developers List Subject: RE: Struts WML Tag Library Any way to combine forces? Daniel Honig [EMAIL PROTECTED] on 11/01/2002 10:25:26 PM Please respond to Struts Developers List [EMAIL PROTECTED] To:Struts Developers List [EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:RE: Struts WML Tag Library Chip, A couple of us have put together a canidate for this library already. My struts time has been 0 as of lateI'm out the door to a party here in manhattan, much apologiesPing me if I don't get the others e-mail addy's before the end of the weekend. -Daniel -Original Message- From: Chip Paul [mailto:chip;ethreatnet.com] Sent: Friday, November 01, 2002 10:26 PM To: [EMAIL PROTECTED] Subject: Struts WML Tag Library I'm currently in the process of converting existing and new customer sites into a mobile format. Since I used struts in doing the customer web sites, I thought I'd look into WML support for struts. After I saw that there was no current support, I starting hacking around in the html taglib, and just got a _basic_ version of wml based struts working. I think this is a really important part of the library, because the time savings of reusing all the server side code will quickly stack up for me at least. As I anticipate the resulting library to get more mature over the next few months, I thought I'd see about volunteering to add to the main taglib branch as I get my library working. I skimmed over most of the docs on that part of the site, but didn't find a clear cut email for whom to talk to, so I thought I should just post it to the list in case someone is already working on wml support. If there's noone currently working on it, I'd be interested in either signing up for it, or at least know whom I should send my lib to to get it integrated. My main focus is getting my own site up, so I imagine the library will be a tad rough by your standards - and to make matters worse I'm not overly knowledgable on the guts of struts itself, but I imagine both will work themselves out a bit as I delve in. At the very least, if it's on-topic, I'd like some guidance as I try to convert HTML-centric strutisms into their WML counterparts. Thanks in advance, Chip === Chip Paul, Lead Software Developer Ethreat Security Solutions, Inc. - http:///www.ethreatnet.com [EMAIL PROTECTED] Cell 256.479.5894 PGP Fingerprint: 47B0 8313 2F79 5DBD 87F7 3C5E 181B 76D4 49C2 B525 -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. --- -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: Struts IRC Channel
Hey I think it is a neat idea. IMHO I'd love to see jakarta with it's own Jabber client/p2p system but I'm not sure this will work. I find the mailing list is fine for most purposes and though the search on the archive isn't great it does give us a persistent archive where the irc chat sessions are by definition transient... -Original Message- From: [EMAIL PROTECTED] [mailto:Kevin.Bedell;sunlife.com] Sent: Monday, October 28, 2002 5:05 PM To: Struts Developers List Subject: Re: Struts IRC Channel Not sure how much of an issue this is - I've been on and off the IRC channel all day just to check it out and have yet to see anyone there other than a single sysop... V. Cekvenich [EMAIL PROTECTED]@main.gmane.org on 10/28/2002 03:31:20 PM Please respond to Struts Developers List [EMAIL PROTECTED] Sent by:news [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) Subject:Re: Struts IRC Channel Also, if a question is answered, at least in theory you can say Search the mail archive for post X and thus preserving the knowledge. .V Martin Cooper wrote: +1 on staying away from IRC. IMHO, IRC fragments the community we have on the lists. It also lessens the pool of people who can answer any given question, for a variety of reasons. Who's going to give authoritative answers to Tiles questions asked at 3am French time? ;-) -- Martin Cooper -Original Message- From: James Mitchell [mailto:jmitchtx;telocity.com] Sent: Saturday, October 26, 2002 12:42 PM To: Struts Developers List Subject: RE: Struts IRC Channel I totally agree with you David. I've collected an enormous amount of FAQ material (which I haven't organized yet) from this and the users list over the last 6 or 7 months. What good does it do to solve a really tricky problem if no one else can take advantage of that knowledge transfer? I'll be adding the new FAQ material and a few 'how to' sections soon. (for example: How to setup Netbeans to step through and debug your web application on Tomcat using Remote Debugging - a pictorial guide) James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. - Albert Einstein (1879-1955) -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] Sent: Saturday, October 26, 2002 3:01 PM To: [EMAIL PROTECTED] Subject: Re: Struts IRC Channel I for one, will not be answering questions on another forum. It's hard enough to keep up with the questions on this list :-). Also, I think it's a good that there be a central place to ask Struts questions. David From: Nick [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Struts IRC Channel Date: Sat, 26 Oct 2002 14:57:00 -0400 (EDT) Hi, I've recently started hanging out in #struts on irc.freenode.net to help answer questions relating to the framework. I don't know that much about some of the esoteric areas of Struts, so I would really appreciate it if some of the developers would idle there and field the occasional question. Activity is very low, so the load shouldn't be too high. If you think that this is a waste of time, let me know how you'd improve upon it. Sending people to mailing list archives doesn't always work as the search functionality isn't great. Thanks for your time. -Nick -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org _ Get faster connections -- switch to MSN Internet Access! http://resourcecenter.msn.com/access/plans/default.asp -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org --- This e-mail message (including attachments, if any) is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, proprietary , confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and erase this e-mail message immediately. --- -- To unsubscribe, e-mail:
RE: Struts Roadmap
It will be ready when its' ready and those who have issue can join me in with me on sacrificing free time to kill bugs in bugzilla. -Daniel -Original Message- From: David Graham [mailto:dgraham1980;hotmail.com] Sent: Thursday, October 17, 2002 4:52 PM To: [EMAIL PROTECTED] Subject: Re: Struts Roadmap I don't think Jan. 2003 is a reasonable time to get 1.2 out. Jakarta projects don't advertise release dates and I don't think we should start now. David From: Byrne, Steven [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Struts Roadmap Date: Thu, 17 Oct 2002 16:30:58 -0400 Great suggestions Craig. So that we don't have n people asking the same question about 2.3/1.2 dependence on the user list, can someone volunteer to do it here? Also, would it be reasonable for me to include with annotations in the roadmap things that are not set in concrete, like whether Struts 2.0 is based on Servlet 2.4/JSP 2.0? For example, have the first part for each release be things that we have definitely decided upon, and a second part be the things that are still being decided upon or which aren't committed yet? That way, people can see what the potentialities for each release are, and voice opinions one way or the other. Steve -Original Message- From: Craig R. McClanahan [mailto:craigmcc;apache.org] Sent: Thursday, October 17, 2002 1:06 PM To: Struts Developers List Subject: RE: RE: Tiles Refactorings for 1.1 compatability Three quick notes: * We should specifically ask on the user list about the timing of Servlet 2.3 / JSP 1.2 dependence. I would expect this to be a bit controversial on that short a time frame. On the other hand, knowing we could interoperate with (and not just integrate with) JSTL (and JSF when done) would be nice. * If the STXX folks are still interested, I'd like to see more formal support for XML processing pipelines be included in a 1.2 time frame. This will help people who want to leverage Struts in a web services hype world, as well as being generally useful. * I'd defer a decision on whether Struts 2.0 advances to Servlet 2.4 and JSP 2.0 or not for a while yet -- to me, it really depends on the adoption rate for J2EE 1.4 and the availability of products that run it. From the Struts perspective, Servlet 2.3-2.4 doesn't buy a lot, but the JSP 1.2-2.0 changes are going to be very very useful. Craig On Thu, 17 Oct 2002, Byrne, Steven wrote: Date: Thu, 17 Oct 2002 14:17:10 -0400 From: Byrne, Steven [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: RE: RE: Tiles Refactorings for 1.1 compatability Here's the draft roadmap that I wrote up. Struts 1.1 * Servlet 2.2 / JSP 1.1 based * tiles validator first class citizens * tiles module aware * validator module aware * Struts-el tag lib at contrib status * [need help here] ??? factored out into jakarta commons * resources factored out into commons-resources? Struts 1.2 January 2003 [duration: 2 months? ] * Servlet 2.3 / JSP 1.2 based * Struts-el tag lib integrated * Support for distributed struts components within a single application (either by just having a list of them or by using some assembling technology) * tiles JSTL aware * 1.1 bug fixes * [need help here] ??? factored out into jakarta commons Struts 2.0 Q2 2003 [duration: ??? months ] * Servlet 2.4 / JSP 2.0 * JSF integration [I'm not sure whether to tie these items in with the above roadmap or not] Struts 1.2 * investigate and prototype alternative module organizations including * arbitrary levels of nesting * locale based structuring * inheritance of elements from base types * struts-config * tiles [already has this, but there may be ways to make it cleaner] * validators * investigate adding identifier namespaces -Original Message- From: Ted Husted [mailto:husted;apache.org] Sent: Thursday, October 17, 2002 5:04 AM To: Struts Developers List Subject: Re: RE: Tiles Refactorings for 1.1 compatability I posted a starter version of the roadmap so we'd have something to patch :0) http://jakarta.apache.org/struts/status.html -Ted. 10/16/2002 4:42:10 PM, Byrne, Steven [EMAIL PROTECTED] wrote: Definitely a big part of what 1.1 is all about is integrating Tiles and Validator into the main Struts distribution. Pulling them back into pseudo-contrib status would not be a good thing. Has anyone estimated the level of effort to make each of them be sub-app aware? I imagine it's non-trival, but
RE: template status
For the last one I guess we just have to examine the definition of deprecate: dep.re.cate Pronunciation Key (dpr-kt) tr.v. de.pre.cat.ed, de.pre.cat.ing, de.pre.cates To express disapproval of; deplore. To belittle; depreciate. [Latin dprecr, dprect-, to ward off by prayer : d-, de- + precr, to pray; see prek- in Indo-European Roots.] depre.cating.ly adv. depre.cation n. depre.cator n. Usage Note: The first and fully accepted meaning of deprecate is to express disapproval of. But the word has steadily encroached on the meaning of depreciate. It is now used, almost to the exclusion of depreciate, in the sense to belittle or mildly disparage, as in He deprecated his own contribution. In an earlier survey, this newer sense was approved by a majority of the Usage Panel. So I guess we just be little those who use template, ahaha.Your still template, that's so 2000' ;) -Daniel -Original Message- From: Craig R. McClanahan [mailto:craigmcc;apache.org] Sent: Thursday, October 17, 2002 12:51 PM To: Struts Developers List Subject: Re: template status On Thu, 17 Oct 2002, Eddie Bush wrote: How do you deprecate a taglib? Add a deprecated element on each of the tags in struts-template.xml that suggests using Tiles instead. Add info at the top of each piece of documentation about templates saying the same thing. Leave the tag library in the 1.1 release (backwards compatibility). Plan on answering STRUTS-USER questions about this anyway ... -- Eddie Bush Craig -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
RE: multiple front ontroller in struts
I would guess that in alot of cases one could solve the need for multiple front servlets through the use of a custom RequestDispatcher? -daniel -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 7:13 AM To: Struts Developers List Subject: Re: multiple front ontroller in struts Not at this time. There are a number of deep assumptions in the code that the ActionServlet is the one-and-only in the application. Although, I think re-examining that assumption post 1.1 would be worthwhile. There are some performance advantages to having a single servlet, but there are also many configuration advantages to having multiple controller servlets, each respnsible for its own URI pattern(s). -Ted. 10/16/2002 6:17:59 AM, Anjali Jain [EMAIL PROTECTED] wrote: Hi all, is it possible to have one more front controller servlet other than Actionservlet in struts ...?? anjali -- 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: Tiles Refactorings for 1.1 compatability
Cactus versions What version of cactus should I be using for the latest Struts source from CVS? do I need to build cactus from source too? -Daniel -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 12:06 PM To: Struts Developers List Subject: Re: Tiles Refactorings for 1.1 compatability Odd - I didn't see it on the products page (overlooked?) but it was on the download page. Unfortunately that is not available in a Linux version. I grabbed it anyhoo - I have a Windoze install too. Eddie Bush wrote: I don't see SilverRun JD 1.1 - there's something called ModelSphere. Is that it? I like the idea of letting a tool build diagrams ;-) I snagged the demo of ModelSphere. Robert Leland wrote: There is no up to date UML diagram. The later one is a not up to date reverse engineering of the tiles package. I used SilverRun JD 1.1 to produce the diagrams. snip/ -Rob -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
update:RE: Tiles Refactorings for 1.1 compatability
Let me update this. I am able to get everything running
but I had to add a method to one of the Mock Objects to get the Tests to
build.
cvs update shows I have all the latest struts source.
I had to add in MockkServletContext.java:
a method:
public Set getResourcePaths(){
throw new UnssuportedOperationException();
}
to build the tests. Otherwise the build complains
MockServletContext.java should be abstract
-dh
-Original Message-
From: Daniel Honig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 1:15 PM
To: Struts Developers List
Subject: RE: Tiles Refactorings for 1.1 compatability
Cactus versions
What version of cactus should I be using for the latest Struts source
from CVS?
do I need to build cactus from source too?
-Daniel
-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 12:06 PM
To: Struts Developers List
Subject: Re: Tiles Refactorings for 1.1 compatability
Odd - I didn't see it on the products page (overlooked?) but it was on
the download page. Unfortunately that is not available in a Linux
version. I grabbed it anyhoo - I have a Windoze install too.
Eddie Bush wrote:
I don't see SilverRun JD 1.1 - there's something called ModelSphere.
Is that it? I like the idea of letting a tool build diagrams ;-)
I snagged the demo of ModelSphere.
Robert Leland wrote:
There is no up to date UML diagram.
The later one is a not up to date reverse engineering of the tiles
package.
I used SilverRun JD 1.1 to produce the diagrams. snip/
-Rob
--
Eddie Bush
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: update:RE: Tiles Refactorings for 1.1 compatability
Thanks!
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 2:10 PM
To: 'Struts Developers List'
Subject: RE: update:RE: Tiles Refactorings for 1.1 compatability
-Original Message-
From: Daniel Honig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 11:02 AM
To: Struts Developers List
Subject: update:RE: Tiles Refactorings for 1.1 compatability
Let me update this. I am able to get everything running
but I had to add a method to one of the Mock Objects to get
the Tests to
build.
cvs update shows I have all the latest struts source.
I had to add in MockkServletContext.java:
a method:
public Set getResourcePaths(){
throw new UnssuportedOperationException();
}
to build the tests. Otherwise the build complains
MockServletContext.java should be abstract
You must be building against a Servlets 2.3 API. The getResourcePaths()
method is new for Servlets 2.3. If you try building against a Servlets 2.2
API, you shouldn't have any problems.
--
Martin Cooper
-dh
-Original Message-
From: Daniel Honig [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 1:15 PM
To: Struts Developers List
Subject: RE: Tiles Refactorings for 1.1 compatability
Cactus versions
What version of cactus should I be using for the latest Struts source
from CVS?
do I need to build cactus from source too?
-Daniel
-Original Message-
From: Eddie Bush [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, October 16, 2002 12:06 PM
To: Struts Developers List
Subject: Re: Tiles Refactorings for 1.1 compatability
Odd - I didn't see it on the products page (overlooked?)
but it was on
the download page. Unfortunately that is not available in a Linux
version. I grabbed it anyhoo - I have a Windoze install too.
Eddie Bush wrote:
I don't see SilverRun JD 1.1 - there's something called ModelSphere.
Is that it? I like the idea of letting a tool build diagrams ;-)
I snagged the demo of ModelSphere.
Robert Leland wrote:
There is no up to date UML diagram.
The later one is a not up to date reverse engineering of
the tiles
package.
I used SilverRun JD 1.1 to produce the diagrams. snip/
-Rob
--
Eddie Bush
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: UML Modeler [Was: RE:Tiles Refactorings for 1.1 compatability]
I've got a personal relationship with the folks behind MagicDraw. While I doubt they would sponsor the whole Jakarta project, I might be able to bend their ears to working something out on licenses. Perhaps committers?...Something like that... If the project would like me to pursue this then let me know what our needs might be roughly. I can always ping them to see if they would want to sponsor us in some way. -Daniel -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:24 PM To: Struts Developers List Subject: Re: UML Modeler [Was: RE:Tiles Refactorings for 1.1 compatability] Yeah I found it - just a Windoze install though :-/ I didn't care much for Argo either. That's way more horse-power than I want in such a tool. Having the ability to reverse engineer into diagrams is awesome - and being able to draw diagrams easily is awesome. I don't really want to go to the trouble to build a model that depicts my code so concisely it can be auto-generated though. That seems like a real PITA. Robert Leland wrote: I don't see SilverRun JD 1.1 - there's something called ModelSphere. Is that it? I like the idea of letting a tool build diagrams ;-) I did a Google search: on 'SilverRun JD 1.1' http://download.com.com/3000-2417-8021135.html?legacy=cnet By the way avoid Argo, that was the open source UML builder that was big, buggy and slow. It has gone commercial and seems abondonded, no matter what the developers say. -Rob -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: UML Modeler [Was: RE:Tiles Refactorings for 1.1 compatability]
Good one. I think that the only thing that should ever be committed is the standard xml files and everyone has to adhere to that standard. don't want to waste cycles on this either. -Original Message- From: Robert Leland [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 4:44 PM To: Struts Developers List Subject: RE: UML Modeler [Was: RE:Tiles Refactorings for 1.1 compatability] I've got a personal relationship with the folks behind MagicDraw. Back in July http://marc.theaimsgroup.com/?l=jakarta-generalm=102750916312690w=3 Subject :Together ControlCenter for jakarta projects There was a fire storm about Rational Control Center for Jakrata Developers. The bottom line was we Jakarta Comitters would be 1) ok as using a free UML tool 2) Use would not = endorsement by Apache. 3) It would be optional, and we would only commit the project files if it talked the standard XML format. I am staying out of this one. -Rob -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bugzilla Bug 13239
I have prepared a patch to validator-rules.xml to fix Bug 13239 Roughyly: Hi , I am trying out the possiblities of Struts for our project, and i found the following issue I am having a date pattern (/MM) in one of my forms and in validation.xml *** fieldproperty=date depends=required,date arg0 key=typeForm.date.displayname/ var var-namedatePatternStrict/var-name var-value/MM/var-value /var /field * Even if i give a proper date like (2002/01) ,i am getting a invalid date response from the Framework. I went through validateDate(form) validator-rules.xml and gave couple of alerts and found the function has not been coded to cover this format. Please suggest what should be done? This case was not programmed into the logic and would always be considered invalid. Apparently there are folks out there who need this. Since I'm rather green around here what all needs to happen next for my patch to be included? I'm going to do the CVS diff -u thing. That we've talked about. Do I update bugzilla? Or who does that? And I should send the diff to the list right? Best Regards, -Daniel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [VOTE] How should Tiles be refactored?
Back to the issue at hand, though: Why can't tiles have a global configuration that can be overidden locally? Is this feasible? Other environments offer such functionality. -Daniel -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 6:26 PM To: Struts Developers List Subject: RE: [VOTE] How should Tiles be refactored? Ya, sorryI couldnt resist. James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Karr, David [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 6:24 PM To: 'Struts Developers List' Subject: RE: [VOTE] How should Tiles be refactored? Oh. Sheesh, it's not even Thursday. -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:22 PM To: Struts Developers List Subject: RE: [VOTE] How should Tiles be refactored? You sure about that? ;) James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Karr, David [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 6:18 PM To: 'Struts Developers List' Subject: RE: [VOTE] How should Tiles be refactored? Could we have a ruling on this, please? As far as I can tell, it's still Thursday, in all parts of the world. ;) -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:14 PM To: Struts Developers List Subject: RE: [VOTE] How should Tiles be refactored? Well, I know I'm not a committer and all hanging-head, but for what its worth... [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ x ] I DON'T think we should allow naked pictures of the committers on the main pageDOH HAHAHAHA [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by a switch which defaults to off [ ] I want tiles to have a different configuration (Elaborate). James ...and you thought I was serious for a sec huh? Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 3:49 PM To: Struts Developers List Subject: [VOTE] How should Tiles be refactored? There's been a lot of discussion on how 1.1 final should look, and I think it's good to have such discussions. We (commiters and non), being tasked with implementing everything that is Struts 1.1, need to have a clear picture of exactly what that means. Now, when it gets right now to brass tacks, it's irrelevant to me which way we go on this (right now - I think my position is well-known). Something has to be done though. Progress needs to be made, and to make progress we must have a clear understanding of how we should proceed. Tiles will not work as expected with modules and that needs to be fixed. What form should it take? I'm tired of speculation. I'm happy to study Tiles and determine what needs to change, but I will not take the decision of how to implement it upon myself. Please bear in mind that we have folks waiting on 1.1F very anxiously and that any behavior can be rectified in a later release. Also note that refactoring to support a dependent configuration would not undo (that I can see) any change which would be required to make the configurations entirely independent. That is a necessary step. The only question is if/when the next step of allowing sharing across modules should occur. Cast your vote. [ ] I want Tiles to have an independent (non-shared) configuration for each module. No future change is required IMHO. [ ] I want Tiles to have an independent (non-shared) configuration for each module. I think we should revisit this decision after 1.1F. [ ] I want tiles to have a (possibly) dependent (shared) configuration for each module in the 1.1F release. - modules would chain lookup from the current module to the default module (or something else) - could be turned on/off by
RE: Basic Issues
This is the correct view in IMHO. ATG had an interesting feature called converters the converter could be specified on the element that was being displayed as in input bean=some/bean/property converter=date(someformat) I've scrathed and itched a few times before wishing for this in Struts. It was quick easy and de-coupled. It worked well enough. -Daniel -Original Message- From: Taylor, Jason [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 11:32 AM To: 'Struts Developers List' Subject: RE: Basic Issues I disagree with the idea that JavaBeans should handle date formats, and I think it is a good example of mixing view and model components-- of confusing the roles of front- and back-end developers. Date formats and the like are better left to the front-end developer since they are UI elements and are subject to change anytime the UI changes. The back-end developer should supply all the data required to manipulate the format in a convenient and comprehensive way, but the actual format is a stylistic setting that should be controlled by the front-end developer. If you don't believe me, think of what happens every day: a client looks at a table of data, says hey we need to know (or don't need to know) what time the thing happened, and that along with a list of other nits goes back to the back-end developer who complains that they should've gotten solid requirements before starting the project and then makes a code change to add HH:MI pm with the leading zero removed before 10:00 because it looks funny. Maybe others like coding ad hoc date routines, but in that situation I tell my front-end guys to pick up a JS book and figure out what to do with the date beans I pass them. The whole idea of Struts is to create logical separations between the front end, which is UI-centric, and the back end, which is data-centric. The role of the back-end developer is to insulate the front-end developer from the complexities of managing data, and the front-end developer insulates the back-end developer from the complexities of managing the UI. Just as a front-end developer shouldn't have to worry about miscellaneous changes the DB admin/architect makes, the back-end developer shouldn't be pulled in every time the UI changes, or every time the same application is reskinned. Date formatting should *definitely* be handled in a front-end script or transformation, unless there is some solid requirement (like legal syntax) that it *always* has to be the same-- in which case it's not really a date, but more like a code. The Javascript Date object is pretty robust I hear, and there are people out there who are JS artists that can help you if you're having trouble. Struts tags have some deficiencies that it would be good for front-end developers to identify, but by and large there are lots of times where you need to have a front-end scripting language handle things. JavaBeans can't do everything, neither can taglibs, nor Javascript-- just use the right tool for the right job. -JT -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 6:30 AM To: Struts Developers List Subject: Re: Basic Issues I would suggest that this type of functionality be placed in a JavaBean rather than a tag. I idea is that it is really not up to the page to decide in what format a date is displayed. That's really a business requirement that you would want to enforce on the Web presentation tier, or a PDF presentation tier, or in some type of Word Processing report. The page needs to decide whether the date property is displayed between TD elements or LI elements, and so forth. But there's no reason for the page to worry about formatting the date. Only how to markup the date property for a HTML page. The tags provide the basic funcationality you need to expose JavaBean properties to the page but are not intended to be used as part of a Model 1 design where business logic and presentation markup are handled as a single task. So, I would take whatever code you might otherwise put in Javascript or a custom tag and make it part of the getDate() (or getDateDisplay()) method on the JavaBean. Ideally, all the actual formatting should take place in a business tier bean, and then the formatted string passed to the ActionForm, ready to go. -T. edgar wrote: I have found that the basic functionality of the tag library classes to be limited (I assume by design) , and I have found myself writing replacement tags for quite a number of things. I.E. In order to have a relatively simple date interface (avoid very complex javascript in every jsp) the logical place to put such code is in the tag libraries. Question 1: Am I missing something and is this code is actually being produced somewhere else? Question 2: Is there a desire for such code to be included in Struts or does this bring the user interface too much into the picture? Question 3: How complex will life be
RE: Basic Issues
But what about having another component that can be specified as an attribute to an input tag as the converters I mentioned in a previous post? This is more like what Jason is talking about. What's in the JSTL is probably useful for display only. The converter concept can be made useful bi-directional in/out -Daniel -Original Message- From: David Graham [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 11:38 AM To: [EMAIL PROTECTED] Subject: RE: Basic Issues Struts does not need a date formatting tag because the JSTL already has one. It's called (surprise) formatDate. What happens to your js date formatting when I turn off javascript? Dave From: Taylor, Jason [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: RE: Basic Issues Date: Fri, 11 Oct 2002 08:32:27 -0700 I disagree with the idea that JavaBeans should handle date formats, and I think it is a good example of mixing view and model components-- of confusing the roles of front- and back-end developers. Date formats and the like are better left to the front-end developer since they are UI elements and are subject to change anytime the UI changes. The back-end developer should supply all the data required to manipulate the format in a convenient and comprehensive way, but the actual format is a stylistic setting that should be controlled by the front-end developer. If you don't believe me, think of what happens every day: a client looks at a table of data, says hey we need to know (or don't need to know) what time the thing happened, and that along with a list of other nits goes back to the back-end developer who complains that they should've gotten solid requirements before starting the project and then makes a code change to add HH:MI pm with the leading zero removed before 10:00 because it looks funny. Maybe others like coding ad hoc date routines, but in that situation I tell my front-end guys to pick up a JS book and figure out what to do with the date beans I pass them. The whole idea of Struts is to create logical separations between the front end, which is UI-centric, and the back end, which is data-centric. The role of the back-end developer is to insulate the front-end developer from the complexities of managing data, and the front-end developer insulates the back-end developer from the complexities of managing the UI. Just as a front-end developer shouldn't have to worry about miscellaneous changes the DB admin/architect makes, the back-end developer shouldn't be pulled in every time the UI changes, or every time the same application is reskinned. Date formatting should *definitely* be handled in a front-end script or transformation, unless there is some solid requirement (like legal syntax) that it *always* has to be the same-- in which case it's not really a date, but more like a code. The Javascript Date object is pretty robust I hear, and there are people out there who are JS artists that can help you if you're having trouble. Struts tags have some deficiencies that it would be good for front-end developers to identify, but by and large there are lots of times where you need to have a front-end scripting language handle things. JavaBeans can't do everything, neither can taglibs, nor Javascript-- just use the right tool for the right job. -JT -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 6:30 AM To: Struts Developers List Subject: Re: Basic Issues I would suggest that this type of functionality be placed in a JavaBean rather than a tag. I idea is that it is really not up to the page to decide in what format a date is displayed. That's really a business requirement that you would want to enforce on the Web presentation tier, or a PDF presentation tier, or in some type of Word Processing report. The page needs to decide whether the date property is displayed between TD elements or LI elements, and so forth. But there's no reason for the page to worry about formatting the date. Only how to markup the date property for a HTML page. The tags provide the basic funcationality you need to expose JavaBean properties to the page but are not intended to be used as part of a Model 1 design where business logic and presentation markup are handled as a single task. So, I would take whatever code you might otherwise put in Javascript or a custom tag and make it part of the getDate() (or getDateDisplay()) method on the JavaBean. Ideally, all the actual formatting should take place in a business tier bean, and then the formatted string passed to the ActionForm, ready to go. -T. edgar wrote: I have found that the basic functionality of the tag library classes to be limited (I assume by design) , and I have found myself writing replacement tags for quite a number of things. I.E. In order to have a relatively simple date interface (avoid very complex javascript in
RE: [Resources] XMLMessageResources and Proposal
Yeah, Since it is Friday I'll just step up and toss my own 0.02 into the mix. When one is learning patterns everything looks like a pattern. I went through this syndrome. The kama sutra could be considered a book of patterns, and its' much older than the gang of four. But these days I when doing client work I tend to avoid the framework mindset that brings us together in a project like struts and just do it quick and dirty. -Daniel -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Friday, October 11, 2002 3:41 PM To: Struts Developers List Subject: Re: [Resources] XMLMessageResources and Proposal I was reading a thread last night somewhere off in bozo-land where this fellow was trying *so* hard to shove patterns into his design it was hillarious. I won't go into details - but shove is an appropriate description. Sometimes, people want so badly to use a new thing that ... well they misuse it. The key, I think, as Mark pointed out is: Does it add value? Why add complexity where you don't have to? ... just my 0.02 :-/ James Mitchell wrote: LOL James Mitchell Software Engineer/Struts Evangelist http://www.open-tools.org -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Errors when switching to struts.jar 1.1b1
I monkeyed around with my web.xml and got my application working after similar issues. Note that the validator is now a plug-in and must be configured directly. Wish I could be of more help and speak directly to your errors but I'd mess around with the sample applications and try to isolate the differences and something should pan out. I found porting to be a minor inconvenience. -Daniel -Original Message- From: alex hun [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 11:58 AM To: Struts Developers List Subject: Errors when switching to struts.jar 1.1b1 hi all, I got this error when i switch my current struts jar to the 1.1b1 release version. Does anyone know what causes it? My application has been working well with the previous version of struts.jar. thanks [INFO] RequestUtils - - Looking for ActionForm bean instance in scope 'request' under attribute key 'LogonForm' Oct 9, 2002 2:59:25 PM SGT Error HTTP [WebAppServletContext(6106608,SIS2, /SIS2)] Error loading servlet: 'action' java.lang.AbstractMethodError Oct 9, 2002 4:28:08 PM SGT Error HTTP [WebAppServletContext(1271473,SIS2, /SIS2)] Servlet failed with ServletException javax.servlet.ServletException: Servlet class: 'org.apache.struts.action.ActionS ervlet' could not be handled by the ClassLoader -- 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: Selective diff?
Just for my own curiosity is it possible to solve this problem by branching the module that contains the patch? You would have a nasty time merging it back togehter, but this is better than having a copy of the entire tree locally for each patch? Isn't this what branching is for? Am I missing something? -Daniel -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 3:32 PM To: Struts Developers List Subject: Selective diff? Problem: I've got a pending patch on RequestUtils already for selectApplication. I also made another modification (added getApplicationPrefix to return the current module prefix) to RequestUtils while bringing the validator into 1.1-compliance. This means I have two different bugs I need to pick certain changes out for selectively. Question: Is there a way I can tell cvs diff -u to give me just a certain section as a patch - or is it possible for me to modify the patch to exclude the already posted patch for selectApplication? Not being 110% familiar with how the diff does it's thing (and noticing there is apparantly some config up top telling it where to apply the patch), I'm reluctant to believe it's a simple matter of editing the patch file. Should I then have a seperate CVS tree for each patch - which only contains changes relevant to a given bug? (Man - that's a nasty solution, but it's the best one I can come up with! That's certainly a lot of work just to keep changes seperate!) -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Selective diff?
Well, I'm not sure its' the fastest/easiest solution. However it is the one we all seem to readily understand :) I think branching would probably work, but if your not comfortable with it, then I'd wait for an opportune time to try it out and crutch by in the manner your most comfortable... -Daniel -Original Message- From: Eddie Bush [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 4:28 PM To: Struts Developers List Subject: Re: Selective diff? I had thought about that. I don't like the idea of having to maintain that though - it's much more straight-forward (to me) to maintain seperate trees (as gruesome as it may seem). I need to learn CVS better :-/ My current strategy is looking like: .../struts/bugs/ jakarta-struts/ (virgin code) by-bugid/ 12702/ jakarta-struts/ (includes changes for bugid 12702) 10348/ jakarta-struts/ (includes changes for bugid 12348) etc ... Nasty as it appears, I think it's probably the fastest/easiest solution. I'll dig into the cvs texinfo docs and see if I can familiarize myself enough with branching to use that alternative. I would want my diffs built with regard to the jakarta cvs tree though - not mine. Thanks! Daniel Honig wrote: Just for my own curiosity is it possible to solve this problem by branching the module that contains the patch? You would have a nasty time merging it back togehter, but this is better than having a copy of the entire tree locally for each patch? Isn't this what branching is for? Am I missing something? -Daniel -- Eddie Bush -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Selective diff?
Well this is exactly the manner that I used PVCS another SCS a commercial from merant that I'm sure many listees have encountered. Now the needs/challeneges of my teams are probably not as great as open source development. But I was thinking in concept you should be able to create a branch for each patch and track the patch as that branch. -Daniel -Original Message- From: Byrne, Steven [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 5:05 PM To: Struts Developers List Subject: RE: Selective diff? Well, yeah, you actually might want to make a branch for just that reason: CVS gives you the ability to produce diffs between versions. Assuming Eddie was empowered create such a branch (OT!), then he could check in his changes to that branch. He, or others (since its a visible branch), could pull changes into the main line selectively, and could make CVS diffs for a specific change that was needed to add that to a bug report or whatever by using the diff between specific versions capability. Successive changes to the same branch work fine, and can be diffed either individually, or collectively. Now I realize that this is a little far fetched in some ways, because I think if he were able to create and write to a branch, he would be able to write to the mainline as well. So it's somewhat not sensible, UNLESS CVS provides a way to allow for differential access controls to branches versus the mainline (I have a vauge feeling that it does, but I haven't checked). If it did, this would be an interesting alternative to the current practice os attaching diffs to the bug report, as people could just create a branch and put their changes into it. Committers could pull the changes from that branch over into the mainline when desired. Since the branch is made with respect to a specific version of the file(s) in question, the bit rot that sets in when there's a long time between when a patch is created and when it's integrated can be avoided as the integrator can see exactly how the patch looked wrt the file at the time it was created, as well as how it might appear currently. Ok, so I'm probably smoking crack with this whole idea -- anyone know for sure if CVS specifically disallows this kind of commit on a branch only privilege? Steve -Original Message- From: Martin Cooper [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 1:48 PM To: 'Struts Developers List' Subject: RE: Selective diff? -Original Message- From: Daniel Honig [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 12:44 PM To: Struts Developers List Subject: RE: Selective diff? Just for my own curiosity is it possible to solve this problem by branching the module that contains the patch? You would have a nasty time merging it back togehter, but this is better than having a copy of the entire tree locally for each patch? Isn't this what branching is for? Am I missing something? No, this is not what branching is for. Branching is used to maintain multiple versions of the code in the CVS repository. What Eddie is trying to do is create diffs for patches to the code. You wouldn't want to be making changes to the repository just to prepare patch files. -- -- 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: [Proposal] Sub-application inheritence
This topic is of interest. To me. I started working out with Web Objects. In WebObjects everything you do is basically viewed as an instance of a component base class. So if you build a search application it can be subclassed and any portion of the model/view/controller can be changed. The java world has yet to catch up to this it seems as we're lost in our mesh of JSP's/MVC frameworks and template engines. If I understand JSF-Java Server Faces is intended to be. Then one could build components that can have inheritance of behaviour. This would lessen the need for sub-applications to support such subclassing. If sub applications are to support inheritance of behaviour there no doubt would be the introduction of a hierarchy which makes this happen and IMHO this is a component model. -Daniel -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 9:42 PM To: Struts Developers List Subject: Re: [Proposal] Sub-application inheritence On Mon, 7 Oct 2002, Eddie Bush wrote: Date: Mon, 07 Oct 2002 18:19:08 -0500 From: Eddie Bush [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: [Proposal] Sub-application inheritence Sub-applications in Struts 1.1 are one of the biggest advantages over 1.0. They let you break your configuration apart into multiple pieces - so that different people can work on their piece of the project without affecting others. This is good for those of us working in a team-oriented setting where different (groups of) people may be responsible for different function areas (ok, Bob and Henry - you guys get the account-maintenance stuff - Frank, Nancy, and Richardo - you guys get this 'store' module - etc). Still, sub-applications aren't as functional as they could be. Because of the structure imposed on sub-applications [1], I think several people believe it would be reasonable for sub-applications to be able to share information with one another[2]. I believe it is expected behavior, in fact. There's sharing and then there's sharing :-). Sharing *data* in application scope and session scope is a reasonable thing to have - the fact that it's all in the same webapp is sort of a poor man's single sign on plus not having to copy your JAR files into things like $CATALINA_HOME/common/lib in Tomcat. Sharing *functionality* was not at all in the design goals I had originally. My view of the world was that sub-apps should be as self contained and independent as possible, in the same manner that webapps should be as self contained and independent as possible. The idea is that you can assemble individual subapps together, and also minimize the cross-sub-app dependencies that can complicate and slow down development. Not everyone agrees with this world view. Another, equally important to me, goal is that any existing Struts (1.0) app should be able to run in 1.1 by itself, or as a subapp, with zero changes to the struts-config.xml file. This is where life gets complicated with your proposal. Currently, each module loads whatever resources it will need. As a result, there is unnecessary duplication of certain resources. Some of those particular resources result in wasting RAM, while others have a more significant impact. Of those that have a more significant impact, the most notable is undoubtably the data-source. Data-source is handy. It's a pool for JDBC connections. The fact that you can configure the pool to limit connections is undoubtably an important functionality to those who use it (though I can't say with full certainty, as I do not use the built-in data-source) - but now that we have sub-applications, determining how to setup the pool to properly manage connection limits could be quite ... difficult. Yes, there are many very good OS DBMSs out there - but we all have to sensibly ration out our connections - if only because of resource consumption. The proposal I would like to set forth is thus (this is a suggested order): 1 - refactor data-source instantiation/acquisition so that duplicates are not created -- *and* sub-apps would they chain the lookup from the current module to the default module. 2 - refactor message-resource instantiation/acquisition the same way 3 - refactor global-forward ~kind of~ the same way. Global forwards mentioned in sub-apps would be pushed up into the default module. Yes, I know there's a possibility for clashing. 4 - (optional) introduce module-level forwards that would replace our current global forwards - and have the exact same scope (visibility) as our current global forwards. All of these are interesting ideas, but to me I think it's post-1.1 thinking. Because any of them will likely break backwards compatibility (and because changes this major will only delay 1.1 further), I'd rather not focus on implementing them now. OK? Disclaimer:
RE: WML taglib?
Davor, I need struts taglibs on my project and am using 1.02 How would you feel about turning the code over to me and I can port it. I would love to have tags for cards/dos/gos? I have a WAS phone to test. The other direction would be to go to 1.1b which I would do and forget 1.02...? But I started hacking some code together from bits and pieces to take care of my first needs. Links in WML and so on I'm sure your much farther ahead. -Danie -Original Message- From: Davor Cengija [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 25, 2002 3:46 AM To: Struts Developers List Subject: RE: WML taglib? On Mon, 2002-09-23 at 22:59, Martin Cooper wrote: The idea has been mentioned before, and there's even a section on the Struts ToDo list for it. However, I don't believe anyone has signed up for such a thing yet, so feel free to jump right in! Yes, I saw that, but I didn't know how recent the TODO list is. Anyway, I have some basic wml taglibs aready written and they even work, at least for my recent project :-) and in DeckIt wml emulator on Linux. I wrote it against the source of Struts-1.1b2 and since it's my first attempt to write anything for Struts itself I don't know wether it's compatible with Struts-1.0 or not. Now, how to provide the code I wrote? How to test it? (See my other mail, Unit testing taglibs). Also I'll need some serious beta testers since I don't even have WAS enabled phone to test the taglib in the real world. Cheers! -- Davor Cengija [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]
