Re: Making Struts Build Easier (Re: coming out for JSF + Struts, was: Struts JSR?)
--- Joe Germuska [EMAIL PROTECTED] wrote: Whether the classic and el taglibs are one chunk or two isn't hugely important to me either -- I would prefer that this decision be made by developers who've done more work on that code to date. However, I did find that when I patched o.a.s.t.html.JavascriptValidator, I had to go and make a corresponding change in the EL version. I suspect that changes in those two libraries are going to track pretty tightly. But like I said, I'm not pushing for this; just floating it... Is there any reason that the EL tags wouldn't replace the existing tags for Struts 2.0? Also, IMO, many of the tags can be removed entirely for 2.0 because they've been replaced by more powerful counterparts in the JSTL. As I've been saying (a lot, it seems, lately) on struts-user, I think there are legitimate Struts JSP tags like html:messages that are not best replaced by JSTL. Any time Struts tools put resources in special locations in request or session scope, I think it's nice to have tags which know the special locations, instead of expecting people to dig in and find them. And, for example with html:messages, the message-property filtering is a useful feature that would require a lot of verbose JSTL to achieve the same goal. So, I'd suspect even in 2.0 there will be arguments for a small Struts taglib. But I am 100% on board with pushing people to use the JSTL where it is really equivalent. Yep, notice I mentioned removing many tags and not *all* tags :-). There are certainly tags we should keep around but I just don't see a need for most of the logic and bean tags in Struts 2.0. Widely known is that the Struts tags sit under the nested tags. And that JSTL and EL cannot fill the shoes of the nested tags. If Struts doesn't want to support the taglibs, then thats a separate issue. But for the nested tags to do what they do, they need the Struts tags including all the logic tags. I don't think that we'd drop all the tags, but as for letting some go that aren't in JSTL et al... -1 Btw: I've thought long and hard about how to get the nested concept into JSTL (to remove the dependancy on Struts), but it's just not a fit. The nested tags manage things as much for the trip back to the Struts servlet as much as making the viewing layout code easier. Nested tags live on Struts. I've watched these conversations, but just don't have the time for all the backround study it'd take to make worthy comment. But for the tags, things haven't changed. So, apologies for just piping in on familiar topics. I probably needed a pair of them fantastic gloves already mentioned... Cheers, Arron. David Joe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Struts goes TLP with unanimous vote...
Guys, Just got the summary email from the Apache board meeting, and the Struts proposal went through with flying colours. Congrats guys, really. So much never-ending quality work. I guess that with everyone else out driking Irish alcohol I was the first to see the email, and I got to be the whistle-blower. :) Cheers, Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts as an Apache Top Level Project
+1 for the TLP +1 for Craig as V-Pres. Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [RESULT][VOTE] Struts as an Apache Top Level Project
Ooops, just missed it. :) No worries. Due to life, I've been conspicuous in my absence, and probably wouldn't be a ripple in the PMC decision making anyways. Just as long as I can maintain commit status to support nested tag coders I'm happy. :) If things change and I get more play time, then I'll knock on the PMC door as required. Cheers, Arron. The response to this vote has been unanimous, with all proposed PMC members responding except for two: Arron Bates and Don Brown. I have attempted to ping those two directly, but have not yet heard back. The next board meeting is March 17th, which is next Wednesday. I propose to submit our resolution this weekend, for consideration at that meeting. In the absence of responses from Arron and Don before then, I will remove their names from both lists. They will, of course, be welcome to join the PMC at a later time. If anyone has any objections to the above plan, please speak up now. -- Martin Cooper On Sat, 6 Mar 2004, Martin Cooper wrote: Following up on a brief thread on this list in December [1], Craig, Ted and I have put together a draft resolution to the board of directors [2], along with a cover letter [3], that would promote Struts to an Apache top-level project (TLP). The main reasons for moving to a TLP are described on the wiki [4]. In Craig's words, The short answer, though, is we will be in charge of our own releases (currently, the Jakarta PMC is the only body legally recognized to vote on releases of *any* software under Jakarta). In practice, we can really just continue doing what we've always done. As most of you are no doubt aware, several Jakarta sub-projects have already made the transition to TLPs, including Ant, Avalon, Gump, James, Log4J, Maven, OJB, and Torque. Most Jakarta PMC members seem to be in favour of the migrations, largely because a single PMC cannot possibly oversee a code base the size of all of Jakarta. If you're OK with Struts being a top-level Apache project, please respond to this thread with either a +1 or +0. Otherwise, please reply with your concerns. When we previously discussed this, it did not seem like anyone was opposed to the idea, but if anyone is, now is the time to speak up. The resolution as drafted lists the Struts Committers who could reasonably be considered active at this time. Of course, we should not put anyone on the PMC without their buy-in, so the final resolution would only list the Committers who responded to the Vote with a +1 or +0. The draft resolution also leaves the name of the Vice President blank. Craig seems like the logical candidate, and is willing to act in this capacity, but we wanted the VP selection to be a community decision. So, please also respond with your nomination for Vice President, Apache Struts. Here's my +1 on the resolution as drafted, and my +1 for Craig as Vice President. -- Martin Cooper [1] http://nagoya.apache.org/eyebrowse/SearchList?listId=[EMAIL PROTECTED]searchText=%22Why+you+*want*+to+be+on+the+PMC%22defaultField=subjectSearch=Search [2] http://www.apache.org/~martinc/struts/tlp/resolution.html [3] http://www.apache.org/~martinc/struts/tlp/cover.html [4] http://nagoya.apache.org/wiki/apachewiki.cgi?JakartaPMCPropsedChanges - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nested-EL
Edgar P Dollin wrote: Everyone has preferences but in my opinion JSTL doesn't hold a candle to the nested tags, especially customized nested tags. I do agree however that JSTL for nested tags is not that important. It does help in environments where there is ZERO tolerance for JSP expressions Conveniently ignoring the fact that something like nested:write property=foo.bar/ stll contains a JSP expression -- just not a *standard* JSP expression :-). But something like... nested:nest property=foo nested:write property=bar / /nested:neste ...is back to standard JSP expression. :P Arron. or that are running older versions of the servlet container. Definitely. Edgar Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Nested-EL
--- [EMAIL PROTECTED] wrote: Back in September, David Karr was threatening to do Tiles-EL and Nested-EL. I see that the Tiles-EL has been committed, sweet. Nested-EL seems to be missing. David, have you started working on Nested-EL? If so, how far off is it from being complete? If not, do you have any tips, because I am getting started on it tonight. Doesn't the EL replace the need for a nested tag library? Isn't the EL syntax easier than using nested tags? I haven't used Nested but it seems like a Nested-EL is redundant. IMHO, I'd say EL is actually harder, but at any rate EL can't completely do what the nested tags can. Like anything recursive. I just had an email conversation with a developer in England that has an app which business data model is a very large data structure. Depending on the level and required feature of the interface, they just have an include file for nested markup at any given level. The root JSP page simply includes the level for the given point and away it goes, regardless of its place in the hierarchy, and it's all updatable to the server because the actual property is made behind the scenes. This is only possible with the nested context being passed in the request. I put an OO-JSP spiel on my site, and this appears to be an extreme implementation of it. I know they're not everyone's cup of tea, but it's a hammer that can hit some pretty wicked nails. Arron. David Carl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
EL evaluation performance...
Peoples (Dave?), Just curious as to how quickly the EL tag logic identifies that there is in fact stuff to evaluate? Any micro-benchmarks? If there's no real overhead, especially for properties provided without expression, to just use them in the tags as-is. Or at least the nested tags where the internals aren't as deep as the rest. Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Final Release
-0 Only because there is a bug raised against the nested tags where it's dropping a reference for included/tiles files in some strange instance. I would have liked to have confirmed, patched and squished/handled it, but my last few weeks have been crazy with moving to the US. I wont be able to get onto it until thurday next week until after the move. Would be sweet if 1.1 could wait until then, but anyways. Just need to say that a version cut now is done with possible issue. Anyone's welcome to dive in there and have a play to see if it is an issue... With obvious other priorities, I'll probably just gruble a little and wait to have it handled for 1.2 or 1.1.1 :P Arron. Ted Husted wrote: Since no significant issues have arisen in response to Struts 1.1 RC2, I propose that we release the tip of the main trunk in CVS as the Struts 1.1 Final release. I have checked in a proposed release plan, which is available for review on the Struts web site: http://jakarta.apache.org/struts/proposals/release-plan-1.1.html Release plans must pass by a majority vote of committers on the project, but all other interested parties are welcome to cast their votes (and/or make comments or suggestions on the plan) as well. -- Vote: Struts 1.1 Final Release Plan [ ] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). - I am +1 on the Struts 1.1 Final release plan. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] IDEA was Struts/.NET (was JavaPro)
And IDEA may be the best developer's UI ever invented. Ted, would you mind comparing IDEA to Eclipse a little bit, if you have time? Not a full blown feature-by-feature review, just highlights. I've used the latest Eclipse, and it's ok, but it's not IDEA. Eclipse has many of the features IDEA has, but not all, and they're not quite as well integrated. They have live templates, but IDEA's are easier to invoke etc etc. Eclipse have taken on some of the features to the degree that they seem to have even ripped off some of the icons (eg. the little light globe for code hints). Take custom keymaps. Eclipse can finally do custom key maps, but only for _some_ functions. IDEA can keymap _any_ function. The entire keymap for the whole IDE is changeable. You can even set keymaps to run your own ANT targets. I _really_ dig this. For repetitive tasks, I have an ANT build file full of messy things I've keymapped to make life easier. All the little stuff, it's toe-to-toe. But the big ones like the local in built version control and the diff tool are not there, and they're awesome tools. The diff tool, is great, shows up things in a flash. Local version control, didn't know you needed it until you have it. IDEA keeps a version history of _all_ your changes to files regardless of any other versioning system for the team. Basically, it rocks. Set labels and things, roll back to last known good versions... it's now indispensible. One of the killer features about the local VCS, is that IDEA unlike any other editor I've ever seen, can undo global search and replaces in your project for the entire undo histroy. too cool for words. You'll find that people using IDEA will swear by it. I dig it so much they got my money from my own wallet, in spite of other editors being free and my stingy tendencies. :P There's a demo available, best way to find out is to suck it and see. Arron. I've historically always been restricted to whatever my employer gives me (which has usually been JBuilder), so I have little experience in different UIs. Things are about to change though :) -TPP - This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: li'l help on contributing
Once a patch is logged against the bug, it waits until a committer has time to take it on and apply it. This patch will most likely be applied after 1.1, and before 1.2. OT: Solnet thrown you into another Struts project?... At least you don't have to play with RHE's Struts fork we used at Zurich. :) Arron. This is prolly, blaringly obvious to those that have done this before, but, after I have created a patch and attached it to the ticket, what is the process for fixes? btw, thanx for the heads up David. cheers Ben - Original Message - From: David Graham [EMAIL PROTECTED] Date: Thursday, June 12, 2003 1:00 pm Subject: Re: li'l help on contributing Create a patch in cvs diff -u format and attach it to the bugzilla ticket. David Hey guys, This is my first (small) foray into the world of open source contributions, so bear with me. I have fixed the code for the enhancement raised in Bugzilla (item 19944). I was wondering what the procedure is for checking these changes in? Does it first need approval(a vote) from the committers? are there any ant targets I need to run/show to prove that these changes don't break the existing code. Any help would be greatly appreciated. cheers Ben -- --- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What's next for Struts?
I've spent some time fixing (recoding?) a proprietary framework which worked exactly like JSF's component driven nature (In fact, I wrote their grid control. Craig- all you had to do was ask :P ). Let me say it has some very clear appeal to the developer, even though that implementation was very agricultrual (ugly when you get close, but gets the job done). Fact is, working with components can be great, *really* great. And to have it as a standard as such in the form of JSF means it's definitely worth an honest look. Even with our framework as it was, overall it was a joy to use, and quickly assembled a complex app that's been out there and running since late last year. Honestly, some aspects of working with components will just have you beside yourself with how cool it is. But the interface isn't really where Struts' value-add is. Other developers have shared the same opinion. So to this, Struts should look at integrating as well as it can to the JSF etc. For the future of Struts, IMHO, it seems it may be taking a step back off the front line to bring in more value-adds to application composition and management of the interface tier. It possibly (opionally?), wont be the first line of interaction, but the engine that drives the next layer. To that end, many people see persistence as the next layer after the interface (like those that use the sql jsp tags), to them it will replace Struts. For most, it will be another handy layer of abstraction. As for specifics... it's anyone's guess. Thing is though, innovation will happen in a project like Struts or [insert any other open source project] before it will happen in some specification consortium. So to take your eye off the OSS space in this area would be as dangerous as not having at least a play with JSF's component driven initiative. The JSF integration library is propbably a good initial way to keep your foot on either side of the fence. Arron. On Sat, 7 Jun 2003, Bill Johnson wrote: Date: Sat, 7 Jun 2003 13:39:13 -0700 (PDT) From: Bill Johnson [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: What's next for Struts? Thanks for passing that on. I have read it now. So I can infer that Struts will likely become an implementation of JSF. I don't know the basis for you inferring that this is likely -- but it is certainly feasible, and might very well be a very great idea -- but that's up to the Struts developer community to decide. That makes total sense given its popularity. It seems though that there will be a fair amount of overlap and that the version of Struts that implements the JSF spec will be quite different from the Struts we know today. Not necessarily. It's quite clear already that you can treat JavaServer Faces as a rendering library nad continue to use existing Struts based application design architectures. Enabling this was the whole point of my developing the Struts-Faces integration library. http://jakarta.apache.org/builds/jakarta-struts/release/struts-faces/ It also infers that companies like BEA and IBM will have implementations of JSF Having more than one implementation of JavaServer Faces in the world seems pretty much assured already. Next week, being JavaOne week, seems like a likely candidate for announcements in this regard :-). But you'll have to ask individual companies for their own plans regarding JavaServer Faces. and that JSF will be a requirement of the J2EE spec. Can anyone confirm that JSF will be a requirement of the J2EE spec for app server vendors, etc? JavaServer Faces is *not* part of the J2EE 1.4 specification. Whether it will or will not be part of of J2EE 1.5 depends on what the expert group for J2EE 1.5's JSR decides to do. Nobody knows at this point. Ted, you're one of the better known Struts people right? What do you think of JSF? For that matter, what do all of the Struts devs think of JSF? I'm not Ted, but I am the original developer of the Struts Framework. As it happens, part of my day job is to be the co-spec-lead for JavaServer Faces, so I have more than a little bit to do with how that turns out :-). Trust me ... Struts oriented developers and users *definitely* need to pay attention to what is going on with JavaServer Faces. I think there should be more discussion on this topic as I'm sure its on the minds of many more people than those at my company. I've CCed user list for that input. By the way, thanks for creating a great software framework! Regards, Bill Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: Status check?
-1 Two weeks seems a little tight. I only say this because the change to the nested tags after RC1 wasn't the smallest of changes, and I personally feel a little nervous that it would be shoved out the door with only two weeks on a release. It was a big fix to get Tomcat 4.1.x going with them, and it was agreed that having the RC2 timespan to allow uptake on any glaring problems would be fine, but two weeks seems a little quick. I've done my best to usher the latest of the tags onto the masses but the broadcast of a release brings in more people than I could ever hope of reaching personally. When RC2 comes out I'd like a little more time to be assured people are comfy with the changes. And as ted mentioned, some of the docs need updating, and for FileUpload to run its course. I know people want it out there but could I stretch the friendship and ask that there's at least a month of RC2 before final?... (what's two more weeks?... they'll fly by, I promise :) Arron. - Original Message - From: David Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:42 PM Subject: RE: Status check? Right, but what's the right amount of time to wait? Craig suggested 2 weeks and I think that sounds good. +1 -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] SEX SEX SEX
Already voted. IDEA is being severely robbed, IMHO. And 3000 odd votes from various users at keyboardmonkey.com would look suss. :P Eclipse has more users, so I suppose it has to give in, but to JBuilder as well!??... nah. doesn't bode well. Arron. Ok, now that I've got your attention ;) Please go and vote: http://www.sys-con.com/java/readerschoice2003/index.cfm -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Status check?
What if we compromise on 3 weeks? I understand the tag testing issue but we shouldn't be holding back because of documentation issues. It's all about getting the tags and other changes tested more completely. (what's documentation? ;) I can very munch understand something happening for JavaOne, it's a big deal to be able to say something new is out there. But after JavaOne, a week isn't much when there's not too much going on and it helps assure a more quality product, IMHO. Arron. David -1 Two weeks seems a little tight. I only say this because the change to the nested tags after RC1 wasn't the smallest of changes, and I personally feel a little nervous that it would be shoved out the door with only two weeks on a release. It was a big fix to get Tomcat 4.1.x going with them, and it was agreed that having the RC2 timespan to allow uptake on any glaring problems would be fine, but two weeks seems a little quick. I've done my best to usher the latest of the tags onto the masses but the broadcast of a release brings in more people than I could ever hope of reaching personally. When RC2 comes out I'd like a little more time to be assured people are comfy with the changes. And as ted mentioned, some of the docs need updating, and for FileUpload to run its course. I know people want it out there but could I stretch the friendship and ask that there's at least a month of RC2 before final?... (what's two more weeks?... they'll fly by, I promise :) Arron. - Original Message - From: David Graham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:42 PM Subject: RE: Status check? Right, but what's the right amount of time to wait? Craig suggested 2 weeks and I think that sounds good. +1 -- James Mitchell Software Developer/Struts Evangelist http://www.struts-atlanta.org 770-822-3359 AIM:jmitchtx - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: http://cvs.apache.org/builds/jakarta-struts/nightly/struts-faces
Isn't JSF just another spec like Servlets and JSP?... Any vendor can make a JSP impl based on the spec, so they should also be able to make a JSF impl. Struts-Faces allows Struts to play with any compliant JSF implementation. If it doesn't we get to go Craig-bashing. :) Struts plays with Servlet/JSP, it now plays with Servlet/JSP JSF. But don't worry, as soon as there's a real sniff of vendor lock-in happening, there'll be more than a few people up in arms. Arron. BTW: I have iPlanet WebServer 4, and App Servers 2 6 on my resume from two separate organisations. ;) iPlanet Web Server 4 was THE java web server. Times change. AppLogic components on the old netscape app server (Kiva)?... oh yeah! Is ASF allowed to distribute Sun JDK? Not AFAIK. I think main argument is license, ex: what is cost of JSF? Is it similar to JBoss issue? I am not against JSF integration w/Struts at all. The more the better. When there is only a single choice, this can't be good, standard or not. No one has educated me with another example of ASF file link like this. (and endorsing a replacement. Ex: On Tomcat 5 there is no files on apache.org... use BEA, here is the jar) I would feel better (and you would feel better for making me feel better :-) if others were listed as integrating with Struts with any disclaimer you want. (Ex: XYZ integrates with Struts but is not Standard to JCP 666, but this jar here is standard). OR: put the url link on Struts site, but the files outside of apache.org on sf.net or wherever, so someone has a chance to think I trust ASF but now I have linked outside of ASF. (just in case it blows up) Unless ASF is endorsing JSF and I just didt't get it. Looks like no one jumping to my side, therefore end of discussion. With a large pool you will not please everyone, I am not pleased. Some diversity is OK, so just say let me pout. .V (on technology side, majority of my revenue contribution is project recovery, ya) Steve Raeburn wrote: Vic, The JSF Expert group includes : Specification Lead Ed Burns Sun Microsystems, Inc. Craig R. McClanahanSun Microsystems, Inc. Expert Group Aligo, Inc. Apache Software Foundation BEA Systems Bayern, Shawn Bergsten, Hans Berkovitz, Joseph Bogaert, MathiasBorland Software Corporation Carapetyan, PeteDevelopmentor Documentum, Inc.Droplets, Inc. EDS Fujitsu Limited Geary, DavidHewlett-Packard IBM ILOG IONA Technologies PLC Lazarus, Eric Macromedia, Inc.Mettu, Kumar Nash, Michael Netdecisions Holdings United Novell, Inc.Oracle SAS Institute Inc. Siemens AG Strachan, James Sun Microsystems, Inc. Zukowski, John A. That's a fairly representative sample of the industry, so I think we can definitely conclude that JSF != Sun either. If you don't think JSF is the right technical direction, then that's one thing, but you are undermining your argument by making this about licensing and Sun. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
Struts is a product of the Apache Software Foundation... [cut] ...we can learn from our mistakes and cut a release whenever we add a feature that people can put to good use (instead of after we have added a large set of new features). -Ted. Couldn't agree more (hence my +1), new RC for JavaOne will be great. Just saying, things seem to have shifted a little. Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE (enough already!): Release Struts RC2 with FileUpload Beta 2
+1 This puppy's more than stable enough to cut another RC. I understand why Martin wants the FileUpload to go through the wringer, and it should, but it's already the most spiffy-est upload component there is. Beta2 of FileUpload has my vote for RC2. Somehow in all this I get the nagging feeling that Struts now has an agenda which it's never had before. It was just cutting quality software, hang the time it took. Regarding James' Open source is supposed to be speedy and responsive, where did you get this idea from?... only open source projects that are truly speedy drop the quality aspect in order to obtain it, unless I'm missing something obvious?... Take Exolab's Castor and how slow that's moving. But what a fine product, and not even at 1.0. Arron. +1 I agree that deprecating methods does not require a new beta. We don't guarantee backwards compatibility between betas. James, can you act as release manager for RC2? Sounds like Martin won't have time to do it. David From: Martin Cooper [mailto:[EMAIL PROTECTED] First off, big thanks to Martin for adopting FileUpload and getting this puppy back in shape. Now, about the Struts 1.1 RC2 release. The problem is the staging needed to get FileUpload out the door. It's currently at Beta 1, and the code base in CVS has some methods that have been deprecated since Beta 1. The deprecated methods need to be removed before 1.0 Final, which means that we need a Beta 2 to publicise the deprecations. Then they can be removed in an RC1, shortly to be followed (hopefully) by 1.0 Final. Much as I would like to see Struts 1.1 RC2 happen before JavaOne, I just don't see how that can happen, given the steps that FileUpload has to go through before a final release. Does this strike anyone but me as an example of the victory of process over sanity? Why does a deprecation/removal of some methods require a new beta? If your code depends on the deprecated methods, you can stick with whatever you're using now until you can fix your code, and then use the release. If you don't, you can evaluate the RC, and an entire step can be saved. The entire Struts 1.1 release has been a Kafka-esq adventure in strict adherence to a set of rules that, IMHO, has done nothing but add months of delay to an already terminally late release. It's hard to believe there's something that makes the JCP look speedy, but consider that in the time we've been struggling to get 1.1 out the door, JSF has gone almost completely from proposal to EA. Open source is supposed to be speedy and responsive, instead we're starting to make Microsoft look like a speed demon. The Apache rules serve a good purpose, to prevent shoddy releases. But at this point, we've got a major release hanging fire on (frankly) some relatively obscure supporting packages which aren't even used by the majority of the user community. If I were benevolent dictator for a day, I'd do a 1.1 RC2 now with the FileUpload Beta 2. But, since we live in an enlightened society, I'm putting it up for a vote. As we've been reminded recently, this type of voice is non-veto-able, lazy majority SO: +1 - Yes, release Struts RC2 with FileUpload 1.1 Beta 2 once Martin releases it. 0 - Eh -1 - I prefer to delay Struts RC2 until FileUpload is in final release. The 72 hour voting cutoff is 3AM Eastern June 1 James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [STP] RC1 Release Plan
[...cut...] http://issues.apache.org/bugzilla/show_bug.cgi?id=18066 Arron (or Antoni). Does it seem like there would be an easy patch here? Would specifying the type be a reasonable workaround? -- at least until we can fix it properly in the next iteration. If we can swat these two, we might be able to roll out RC2. Not a biggie. Patch committed, comment in bugzilla for those interested. Arron. Ted Husted wrote: I'll update the plan and website later, but for now, the outstanding RC1-RC2 list stands at five tickets [NOT RESOLVED, NOT CLOSED, STRUTS, NOT UNKNOWN]. http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=VERIFIEDemail1=emailtype1=substringemailassigned_to1=1email2=emailtype2=substringemailreporter2=1bugidtype=includebug_id=changedin=votes=chfieldfrom=chfieldto=Nowchfieldvalue=product=Strutsversion=0.5+Finalversion=1.0+Beta+1version=1.0+Beta+2version=1.0+Beta+3version=1.0+Finalversion=1.0.1+Finalversion=1.0.2+Finalversion=1.1+Beta+1version=1.1+Beta+2version=1.1+Beta+3version=1.1+RC1version=Nightly+Buildshort_desc=short_desc_type=allwordssubstrlong_desc=long_desc_type=allwordssubstrbug_file_loc=bug_file_loc_type=allwordssubstrkeywords=keywords_type=anywordsfield0-0-0=nooptype0-0-0=noopvalue0-0-0=cmdtype=doitnewqueryname=order=Bug+Number -T. Ted Husted wrote: I'm going to make run at the bug list and update the Release Plan, as we did for b3. -T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
committers attention - just a few moments...
Peoples, I'm waiting on a call in the post below about the nested tags. I know they're not everyone's favorite component, but I do need committer attention to form the game plan as it's not the typical bug fix. It's hard to form a consensus opinion on the one response I have. Copied below for convenience. Arron. Original Post___ Defenders of the faith, Just a small one to say the problem of of not being able to run the nested tag apps in Tomcat 4.1.18's funky Jasper engine has been tackled. I'd commit it, but the codebase being under release conditions, and for the fact that it's no simple few line bug fix. The internals have changed to leverage the request object more completely (was originally just used to enable the recursive JSP markup). The NestedPropertyHelper has been gutted and mostly re-implemented, and all the nested tags have been touched to accomodate the change. Instead of walking the tag hierarchy, all the child tags now pick up on the nested reference within the request object directly. The property handling is now more pessimistic, and resets everything it touches. All effort was made to respect all the minor changes the tags have undergone in fixing past bugs. The fact that most of it has changed means that I don't want it in this release, but the fact that it allows people to deploy in the latest tomcat release is important, something blocking an upgrade path for a lot of people. What about, once the release is out, then the update to the tags committed, and release a bug-fix release for the new nested tags (1.1.1)?... kind of like 1.0.2 was to 1.0.1?... Too unstable for 1.1 so close to release, but too important to let it slip for over a year for it to come out. Needless to say it works on my apps :), but I'm asking the nested tags user base to jump onto it and give it a test run to see if it works for them. For those nesters looking on, there's a jar at... http://www.keyboardmonkey.com/downloads/km-nested-v2.jar ...just throw it into the WEB-INF/lib directory, your classloader should pick them up before struts.jar. If not, delete the tags from struts.jar and give it another bash. Anyways, just thought I'd put it forward. Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: committers attention - just a few moments...
Failing responses from people who are actually familiar with the nested tags and your changes, then I think you'll just have to use your own judgment. I had to make a similar decision recently wrt the Struts-EL tags. Test your changes as much as possible, and try to get some feedback from people who are using your tags. If you think it's safe to commit, then do it (but don't quote me on that :) ). David I think David articulates a rational approach. If you think the fix for nested tags should go in (in spite of being a larger patch than we might be normally comfortable with), and you've tested it as much as you can, I'm certainly not going to argue. Worst case - we do an RC2 with this fix to give the world one more shot at proving it's still got a problem. Craig This is the feedback I'm after. Had I simply committed the patch that is on the big side, I would have been trounced. Especially seeing that time hasn't let me play apache recently, to then walk in and make such a large play (on RC1 day no less). Wouldn't have gone over well I imagine. Arron. BTW: So far, none of the early adopters have said their apps have broken with the new changes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Release Candidate 1 Release Plan
-- Vote: Struts 1.1-rc1 Release Plan [ ] +1 I am in favor of the release, and will help support it [X] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). -- +0 And thanks to *all* of you guys for all the hard work! Craig *all* reads as ...except for Arron. :P It be good work. yes, good work. Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tag Handler reuse
[ ...cut (there was probably copyright issues with copying that much of the spec :)... ] I believe these tags are OK. (Disclaimer: I am by no means a nested tags expert!) In effect, the nested tags do cache the property values, as you suggest they should, just not in the way you might expect. The caching is being done by setProperty(), but only if that method is being called by the container, and resetting of the original value is being done as the first thing in doStartTag(). correct. *game-show-ding* All that's been said by both parties is true. The contract for tags for clarification (for the benefit of those searching mailing lists for problems to report :)... Tag A created, set property one set property two invoked Goes to reuse tag A, set property one. property two is the same on this invocation, so it's not set again, the value assumed to still be there from first invocation. invoked. ...as Martin confirmed, the nested tags store the original setting for the properties they change, and then do their magic. When the tag is reused, the original property is restored. As already mentioned, Resin does this to the letter, and the above is what I had to do to correct the problem. So far Resin's the best performer for all things nested-taggish. The tags *could* set the original properties at the end of doEndTag(), but when it's reused, the logic is sound that it'll be set back again properly ready to dance. I'll try the pessimistic thing when I get the chance, but on the surface it sounds like it would only be a problem if Tomcat's doing something improper after a tag's doEndTag() has been invoked... Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need help deciphering screw-case for PR 15799
EmailUser?... ...smells like some moron hasn't configured his webmail properly :P I looked at this one too, and came out with similar feelings. I think this needs the eyes of our resident Keyboard Monkey, if he's around. Calling all Keyboard Monkeys... We need your help... Job done. You'd think that I wasn't subscribed to the mailing list, where in actual fact my service provider is housing 3000 unattended emails. The team's still doing top stuff, wish I had more time to play. I dig those IDEA told me to style commits :P How many have switched to IDEA?... I can tell that Martin and Ted are... take it we all took advantage of the half price offer?... Joining a recent project, fun to watch the right hand border turn to an exciting yellow red color scheme. Arron. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: nested:iterate with a HashMap
For one, this is a struts-user mailing list type question. But give this a bash... nested:iterate property=variablesThatProducedErrors nested:write property=name/ nested:write property=value/ /nested:iterate ...the nested tags don't need the name properties in the child tags. It's all sorted out by the parent tags. If the above doesn't work, please post the response to the struts-user list. Many more people to help you solve your problem sooner. Arron. Jerred Wilson wrote: Sorry, here's the jsp tags: nested:iterate id=element property = variablesThatProducedErrors td bean:write name=element property =name/ nested:write name=element property = value/ /td /nested:iterate -Original Message- From: Jerred Wilson Sent: Friday, October 25, 2002 8:06 AM To: 'Struts Developers List' Subject: nested:iterate with a HashMap I'm trying to use the nested:iterate tag to iterate through a HashMap. The logic:iterate documentation shows that I should be able to use the following to do so, but I always get the error: java.lang.IllegalArgumentException: Property 'variablesThatProducedErrors' is not indexed where 'variablesThatProducedErrors is a Map'. Why doesn't this work? Does anyone have this working? -Original Message- From: [EMAIL PROTECTED] [mailto:husted;apache.org] Sent: Friday, October 25, 2002 7:51 AM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-struts/doc status.xml husted 2002/10/25 05:50:32 Modified:doc status.xml Log: + Add note to Roadmap where we can document updating the Website from CVS. Revision ChangesPath 1.5 +5 -1 jakarta-struts/doc/status.xml Index: status.xml === RCS file: /home/cvs/jakarta-struts/doc/status.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- status.xml 20 Oct 2002 17:06:08 - 1.4 +++ status.xml 25 Oct 2002 12:50:32 - 1.5 @@ -106,4 +106,8 @@ /ul /section +section +pfont size=-2Website updated from CVS: 2002 OCT 25 by husted./font/p +/section + /chapter/body/document -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: HTML formatting of newline characters with bean:write tag
Craig R. McClanahan wrote: Can't you just embed your bean:write tag inside a pre element and get the same effect? Craig pre opens a can of worms if the designers/managers are picky. For one, it roots the browsers ability to word wrap. Use a regex in your action code or some funky tag and replace them with br / 's before output. It's the only way to get a true representation. Arron. On Wed, 23 Oct 2002, Inge Solvoll wrote: Date: Wed, 23 Oct 2002 14:25:48 +0200 From: Inge Solvoll [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: HTML formatting of newline characters with bean:write tag When outputting text with the bean:write tag, it can be text that was entered by a user in a textarea. The text is submitted with \n (linefeed) characters, and in most cases that I can think of, these linefeeds should be preserved when outputted in HTML. Why isn't all newline characters translated into BR tags when outputted through the bean:write tags? In PHP, this functionality exists in the nl2br function, but I normally expect Struts to perform things like this in a more transparent and elegant way. There is probably a reason for why this functionality doesn't exist, that I don't see right now. Or, it exists but I didn't do a good job looking for it? Anyway, I solved the problem for myself by rewriting WriteTag in the taglib.bean package to perform the needed translation from \n to BR-tags. Clearly, this is not a very elegant way of solving the problem, so I would be very happy to get some feedback on this issue. I hope this is the correct mailing list to submit this to, this is my first contact with this list. My company uses Struts extensively in an advanced way, and we often run into problems that there exists very little information about online. I believe these problems would be interesting for the Struts developers, so I will post a description later on. Keep up the good work! Inge :-) -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-dev-help;jakarta.apache.org
Re: [docs] how to get into Struts Resources?
Thomas L Roche wrote: WebSphere Studio has Struts tooling, so we'd like to put a link-and-a-blurb on http://jakarta.apache.org/struts/resources/guis.html How should we do this? Ask nicely. :) ...and log a docco enhancement in bugzilla. Arron. -- 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: HTML formatting of newline characters with bean:write tag
Craig R. McClanahan wrote: On Thu, 24 Oct 2002, Arron Bates wrote: Date: Thu, 24 Oct 2002 02:20:12 +1000 From: Arron Bates [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: HTML formatting of newline characters with bean:write tag Craig R. McClanahan wrote: Can't you just embed your bean:write tag inside a pre element and get the same effect? Craig pre opens a can of worms if the designers/managers are picky. For one, it roots the browsers ability to word wrap. Use a regex in your action code or some funky tag and replace them with br / 's before output. It's the only way to get a true representation. The other side of the coin is that maintaining line breaks in any fashion is *not* what people who are simply rendering HTML output want. At best, one could make this an option, but it's certainly never something I would use. I took it to mean that the text area is being used as a crude CMS type deal, or a web mail client, whatever. I've had to make heaps of the things over the years. Like anything, its all dependent on the app. You are right though, just rendering Html parsing strings is no-no. Arron. 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: Struts-EL: Ideas about name and indexed name attributes?
One thing we do give up (I think) is the implicit nesting of form field names (specified in the property attribute) inside the variable name of the form bean itself. I guess the same is true of the with-like facilities of the entire nested tag library. It will be interesting to see if we can come up with a way to keep this -- perhaps by composing a compound expression on the fly. Craig thought about it a little, and there doesn't seem to be an obvious fit to pairing the evaluation to a complex bean structure ready for BeanUtils without explicit handling. if it does happen it'll be a concoction of our making rather than something that just slides in there. think maybe the nested tags will become victim to the jstl. oh well. in this regard I think the jstl is lacking a little power for use with Struts. though I am bias, you can do some truly funky stuff with Struts when its marked up with the nested tags. But they're hardly a standard. Lately been working on a project which has some interesting stuff. I've taken a few parts a next step and I get the feeling it's towards what I imagine Java Server Faces to turn out to be. Looks like a bright future. If if could muster the energy for something open source in the future, it'd be the JSF impl. Apache looking at taking on an impl project?... Any chances of getting a backdoor of that spec?... :) Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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: Nested Messages Errors tags applicability...
The 'nameList.value' is being used to lookup of the messages/errors that were stored under this in the ActionMessages. ActionMessages has an internal Map and uses a key (normally the property name and there is also GLOBAL_MESSAGE constant) to store messages/errors associated with that field. That part's not the problem. Internally the name is being set to the same as the rest of the tags, is this simply being ignored to go fetch the messages on a standard name?... Could you clarify this part? Or were you asking if there was a different between passing in 'nameList.value' or a simple property 'value'. On all the tags which take a name attribute to get at the bean, they extend the NestedNameSupport. So internally they'll get their name attribute set, like it or not even if a name was provided it will be ignored, as they all need to rely on the model the parent tags and such are working off. Reading the messages tag docco, it reads like the name attribute has to be set, so I assumed the NestedNameSupport. Having a closer look through it all, it resolves itself nicely. You've used the NestedPropertySupport which means that the name will not be set, and it will use the default ActionMessages reference. It does reference a different bean, but it's hidden and internal so that's all ok. If people provide the name attribute, it's all going fall over if the nested property isn't there, but that's kind of outside the nested scope and the original tag should be used. My confusion was that it was working off a different bean reference, which kind of impossible with the other nested tags without setting a new root tag. So I was also thinking about allowing people to reference a separate bean as standard functionality, as these message tags would be. I don't think they should, but I can hold off on this choice for now. Result, it's all good. Sorry about any confusions. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Nested Messages Errors tags applicability...
Just curious as to the applicability of the Errors an Messages tags in the nested context... Because the nested tags use the one bean reference, I'm finding it hard to visualise using these tags within context. In the original tags, everything was an island, so it was all fine, but nesting against the one bean makes it a little fuzzy. Referencing the different bean means implanting a new root tag, which would mean you'd have to nest the tags all over again to get to the same point. It would be easier to go the route of the original errors/messages tags. I realise that it'd be really handy to be able to get at the same property that a text box is working off of, but the separate bean issue meant that I basically put it down to being out of context and as a result I didn't include them in the tags when I first wrote them. One way I can see it working is to make a small departure from the way the rest of the nested tags work, and allow the referencing of a different bean. This then raises the problem that if you do it for one, you should possibly allow the others. Not impossible. Just a check in the tags to see if there's a supplied bean name reference, if there is, allow it to go through. Up to this point I kept it as a best practice to leave the naming of any bean up to the root tag (well, it enforced it really). Means that the requirement of the root tag should probably be loosened up if a bean is explicitly provided. There will possibly be an ambiguity as to how far back the property will be calculated, and the definition of the nested tags being properly marked up. But I'm probably over-thinking the issue. Any other thoughts?... any other committers actually using the nested tags?... :) Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Nested Messages Errors tags applicability...
That all seems cool, and if the test works, all the better :) To confirm what's happening there... It's fetching the nameList.value property off the same bean as the text fields. To read the markup, the messages and errors would then be calling on the same property. Internally the name is being set to the same as the rest of the tags, is this simply being ignored to go fetch the messages on a standard name?... Arron. On Fri, 2002-06-21 at 05:45, David Winterfeldt wrote: I'm not 100% I'm sure I'm following what the problem is (probably missed some other e-mails). I was going to talk to you Aaron when I went to do these, but it seemed very simple so I went ahead and made them. I just wanted the nested messages and errors tags to be able to get the property name of the bean so you could display messages and errors next to a field from a list. These tags don't really need any other feature the nested tags provid. Currently the validator can handle lists, but not custom messages for each field. It does correctly create the full property as the error key though so you can display the error next to the field. Here is the example from web/validator/type.jsp where I tested this. nested:iterate property=nameList tr th align=left nbsp; /th td align=left nested:messagesPresent property=value br ul nested:messages id=error property=value libean:write name=error//li /nested:messages /ul /nested:messagesPresent nested:text property=value size=15 maxlength=15/ /td /tr /nested:iterate Let me know what you think. David -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Proposed Committer James Holmes
+1 Arron. Ted Husted wrote: James is a longstanding member of the Struts community and has been submitting and vetting a good number of patches for Struts 1.1 beta 1. He's been distributing and maintaining his own Struts add-in (the Console) for some time, and has shown he can manage a public project from soup to nuts. I believe he would be a good addition to the team, and I hereby propose him as a Struts Committer. He has my +1. Votes please? -Ted. Note that I have no idea whether James would be interested in donating the Console to the ASF or not, but that would be a separate issue, and is not the subject of this vote. -- 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: Resource Page...
Please note that beginning 2002-June-30, any page linked as a Struts Consultants on the Resource page must specifically mention that they offer Struts consulting. Listings that do not reference Struts will be removed. +1 Please note that beginning 2002-July-31, any page linked as being Powered by Struts must credit Struts or the Apache Software foundation (e.g., This product includes software developed by the Apache Software Foundation). Listings that do not reference Struts or the ASF will be removed. +1 It is true that some people like to see proof of Struts running, but I don't think that this is too much to ask. It's also nice for the end developer to get a little slice of his work advertised on the communities site, but I think that in this instance that it's not all that bad to get a little back. If people are proud Struts developers and really want it linked, they'll be able to get around most marketing departments to get a little powered by icon on the page, or tiny text. At some point the line must be drawn. It may as well be now. My $0.02 Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: form bean using nested extension must be in session?
No, they don't have to stay in session, but it requires some help to get the collections to tow the line. I've just created these collections, and having the discussion on the commons project at the moment to get them included into the project. Here they are, but there's no docco yet. http://www.keyboardmonkey.com/next/ReserveMap.java http://www.keyboardmonkey.com/next/ReserveList.java Arron. Struts-dev Newsgroup (@Basebeans.com) wrote: Subject: form bean using nested extension must be in session? From: Keith Leung [EMAIL PROTECTED] === Hi all, I'd like to know if it is neccessary to set the form bean to the session scope when I use it with nested extension? If so, what is the purpose of doing so? -- 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]
Resource Page...
The resources page is getting to the unweildy stage. Are there any thoughts to pruning it in the future?... I get twice as many referrers from Ted's site than jakarta. It looks like Ted's just using the same XML document (besides them hot! and new! bits ;). Sounds like we can just prune the resource page to one link. The resources page for Tomcat is not even a patch on Struts (well... maybe a patch)... ...does that mean Struts is bigger/better/the-killer-app?... :) Ted: You put the Other Struts Related Articles link in the TOC, but the content wasn't there. I see it's on your version of the page on your site... do you want to get it on the Jakarta page also?... I've removed it for now, to save users from thinking they're missing out on something, but you'll prbably get to CVS before it gets updated live. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: variable number of text fields in a form
Depends on the type of indexed getter/setter you're using.
public String getMyIndex(int i) {}
public void setMyIndex(int i, String value) {}
...the setter will be called in this case, but in this instance...
public Object[] getMyIndex() {}
public void setMyIndex(Object[] obj) {}
...the setter will not be called, as the system will get the array, and
set the item directly into the array, rather that return the resulting
array back to the setter. This could very easily be the case. It's
really easy to code this way, but don't expect the setter method itself
to be called.
Have you tried the nested tags?... makes light work of list type
operations among everything else.
Anyways, I've ranted this before, and your answer could be above :)
Arron.
Chakradhar Tallam wrote:
hi guys,
how do i handle the setting of variable number of text fields in a form!
i've tried with indexed properties but when i'm posting the form, the get
method is getting called rather than the set method for some reason. have u
had this kind of experience before, help is appreciated.
thanks,
CT.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: variable number of text fields in a form
And this is a user-list type question, so I've forwarded there.
Arron.
Arron Bates wrote:
Depends on the type of indexed getter/setter you're using.
public String getMyIndex(int i) {}
public void setMyIndex(int i, String value) {}
...the setter will be called in this case, but in this instance...
public Object[] getMyIndex() {}
public void setMyIndex(Object[] obj) {}
...the setter will not be called, as the system will get the array,
and set the item directly into the array, rather that return the
resulting array back to the setter. This could very easily be the
case. It's really easy to code this way, but don't expect the setter
method itself to be called.
Have you tried the nested tags?... makes light work of list type
operations among everything else.
Anyways, I've ranted this before, and your answer could be above :)
Arron.
Chakradhar Tallam wrote:
hi guys,
how do i handle the setting of variable number of text fields in a form!
i've tried with indexed properties but when i'm posting the form, the
get
method is getting called rather than the set method for some reason.
have u
had this kind of experience before, help is appreciated.
thanks,
CT.
--
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: increased JavaScript support in the link tag.
After some deep thought...
(any HHGTTG fans out there? :)
It all sounds quite ok as to what it is you're trying to do. I do think
that an efficient routing of the link interaction through JavaScript is
a good thing. It is a very viewy thing people want to do.
Looking at it from the end developer's point of view, I'd be after the
following with various parameters...
(what of the following is true?)
a) function only. Just call the function, no argument, no url.
b) page, function. Function with URL as the only argument.
c) page, function, functionName, functionProperty. As you describe.
c) function, functionName, functionProperty. As you describe, but no url.
And in all cases, the urlIndex to be optional, and default to 0 (the
first arg). Is this how it's all working?...
With it working like above, I'll have no problems taking it on to commit it
(naturally with the absence of -1's. I don't think that this is anything
paradigm changing, but that's the process).
Internally, it will need a little house keeping. The if's without the
{ block, and if you can call the Request utils.lookup, rather than the
duplication in the EcmaUtils.
I'll also need to do some testing on it. Any unit tests?... A simple one
page webapp that I can run tests against, regression tests etc?... or do
I have to make one?... Not too much of a drama either way.
Arron.
Phase Web and Multimedia wrote:
The tag is a Link Tag. I by no means want to create a new tag. If you read
my explanation I state that. The additional attributes are neccessary
though. The reason being is that the functionality is not in the current
Link tag to accomplish this. It has unique requirements that present the
need for an expanded set of Attributes on the Link tag. The idea is to be
able to include the action url into the javascript function call at a
specified an index point along with other parameters one might need to send
to the javascript function. The other goal is to be able to prepare these
parameters and place them into a bean.
For example:
If you have a popup window and you want to customize the size of the pop up.
You might prepare some size parameters for the popup window that you want to
be dynamic. With the tag I spun it allows for this to happen. You can
prepare the parameters yo want to pass to the javascript function in the
Action class and place it into a request bean (or whatever scope) and draw
those prepared parameters from the bean into the Link tag which then (of
course) would call the javascript function.
I am not sure what you are getting at, though. Did you read the
documentation that I wrote. It states that the attributes are added
functionality to the Link Tag. :-)
I think I have already done what you are saying. Please, correct me if I am
misunderstanding you. I am using the base functionality of the Link Tag. I
developed a whole new tag because I didn't have a choice. The intent was
always to incorporate the functionality into the Link tag. Maybe to avoid
confusion I need to go ahead and download the nightly and do a patch
submission. rather than a code submission than can be placed back into the
core struts Link tag.
Brandon Goodin
Phase Web and Multimedia
P (406) 862-2245
F (406) 862-0354
[EMAIL PROTECTED]
http://www.phase.ws
-Original Message-
From: Arron Bates [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 01, 2002 10:45 PM
To: Struts Users Mailing List
Subject: Re: Check this out!
Anyone would think that trying to get an opinion on something is an
uphill battle. :)
Instead of creating an entirely new tag, can you take a look at adapting
the current one?...
Reason I say this, is that there's already a tag there, and this tag
will need another name besides link. scriptlink or something. An
extra tag for people to learn.
Because the logic is already there to do the mapping, and the
querystring appending etc etc, I think it would be easier to simply add
an extra parameter called script or something that when set to the
name of a JS function, that when present, will wrap the resulting URL in
the java script function. This means that *all* current links could turn
into JavaScript routed links by adding one parameter, and inversely go
back by removing it. Which I think would be quite sweet.
Otherwise, it may turn out to be just a tag with an esoteric use.
Your thoughts?...
Arron.
Phase Web and Multimedia wrote:
Hey all,
I submitted an enhancement to struts. Read the following and if it sounds
worth having in struts give me a vote on the developer's list or make some
noise for some of the gurus to see.
The code is at the following url in zip format:
Here is the info on the tag:
http://www.phase.ws/linktag/taglib.zip
I don't know if a similar solution has been provided, but, I tweaked the
Link Tag to support the writing of
'javascript:[function_name]([param1,param2,param3...])' to the href
attribute of the final output. Here is a summarization of it's
functionality:
I added the following
Re: treeview...
It requires JSP 1.2 Apparently JSP 1.1 wont evaluate the custom tags of a dynamically included JSP. Which could also explain your servlet exception. Update your Tomcat to get it to work properly. You can fake it though, by looping through the child nodes yourself, but it will be restricted in the amount of levels possible. However, I don't have any available examples of this style any longer. Arron. Jean Fotovat wrote: hello arron, it does not seem to represent a sample on how to implement a treeview with struts !? isn't it ? thank you jean fotovat - Original Message - From: Arron Bates [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Cc: Struts Users Mailing List [EMAIL PROTECTED] Sent: Tuesday, April 30, 2002 3:05 PM Subject: Re: treeview... Yes. Complete tutorial to create trees with Struts here... http://www.keyboardmonkey.com/pilotlight Arron. Jean Fotovat wrote: hello community, has somebody implements a treeview on struts framework ? thank you jean fotovat -- 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: OT: Re: increased JavaScript support in the link tag.
Correct. :) Arron. Struts-dev Newsgroup (@Basebeans.com) wrote: Subject: OT: Re: increased JavaScript support in the link tag. From: Jose Quinteiro [EMAIL PROTECTED] === Phase Web and Multimedia wrote: After some deep thought... (any HHGTTG fans out there? :) What's HHGTTG not familiar with that one. :-) Hitchhiker's Guide to the Galaxy. Deep thought was the name of the first computer the white mice (or the dokphins?) created to answer the question of Life, the Universe, and Everything. Sorry for the OT. -- 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: increased JavaScript support in the link tag.
Interesting idea. But I'd really like to get 1.1 out the door before adding lots of new functionaltiy ... Not a problem. One of the things I learned, in watching the development of JSTL, is that tags with lots and lots of optional attributes, and different operating modes, can be really hard to understand -- and that describes quite a number of Struts tags today. Given that, we might want to call this one html:javascript or html:action or something, even though deep down it really does generate a hyperlink. Doing it as a separate tag also means you could focus on just the attributes you need for this purpose (i.e. no need to have the attributes to build up a URL). Yes, would agree, but the first thought which I had about it was that it could be used to simply redirect the action of the link with a single parameter. Easily being a toggle for going through the JS or not. It's just that there's a couple more to do the same kind of building for the JS arguments. There's already a javascript Struts tag too from David. Brandon: The -1 +1 business is the decision making process... http://jakarta.apache.org/site/decisions.html Unit tests... http://www.junit.org/index.htm ...personally though, I'd rather have a small specific environment linke a page or something so I can watch it dance. In this case, simply a page that has a list of links which go over all the different cases the tag is meant to do. Unit tests are more than just a harness. For an automated build/test process and whatever. Anyways, the link has way more information than I could ever spiel. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: treeview...
Yes. Complete tutorial to create trees with Struts here... http://www.keyboardmonkey.com/pilotlight Arron. Jean Fotovat wrote: hello community, has somebody implements a treeview on struts framework ? thank you jean fotovat -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: struts-nested.tld...
In a Struts distrib after 15th of January this year. I assume that you're trying to do something with the nested tags?... Arron. Jean Fotovat wrote: hello community, where could i find struts-nested.tld ? i don't find it in struts lib. Is it provided with struts or nobody hears about that ? thanks jean fotovat -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Displaying ArrayList of ArrayLists using logic:iterate
This is a user mailing list kind of issue, but anyways... What happens when you return the Object[] (myArrayList.toArray()) instead of the ArrayList itself?... Because if you're using Struts 1.0/1.0.1 the ArrayList won't work, but the Object[] will. Struts 1.1 can run the ArrayList directly. You're trying to nest iterate tags, have you considered the nested tags?... it really does make light work of this kind of thing. Arron. Srinivas Vemula wrote: Hi, I would like to use logic:iterate tag to print out an ArrayList of ArrayLists, Each ArrayList is a ROW from a ResultSet. My code snippet looks something like this... logic:iterate id=element name=cataloginfo indexId=index br logic:iterate id=alement name=element bean:write name=alement / /logic:iterate /logic:iterate * ) catalogInfo is a java.util.ArrayList which has java.util.ArrayList instances as elements When I try to run it it fails with this error javax.servlet.ServletException: Cannot create iterator for this collection at org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImp l.java:463) at org.apache.jsp.Catalog$jsp._jspService(Catalog$jsp.java:712) at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) IN a Nut Shell, I need to print a ResultSet in a Tabular format using logic:iterate tag. Any help in this regard will be greatly appreciated. Thanks U all for your time and help. Sri -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Tags for Visual HTML Components / Java Server Faces [was: ] Struts menu
On the defense of trees in Struts... ...current Struts 1.1 is actually an absolute honey to make trees. really. One step at a time, and it's a walk in the park. A while back (a month), the nested tags were made to penetrate a dynamic include, which allows for true recursion. Which means... oh yeah trees! I don't mean it's possible I mean if you can do it with trees, you can do it with Struts 1.1!... It really is cool, the same tag markup you always use (if you always used nested tags :), however you want to lay it out, 100% flexible. I've made a ton of trees in web stuff over the years, but this is sweet. Dynamic, collapsing... you name it. I'll be uploading a tutorial on my site to show it off in 24 hours. Struts... oh yeah! Arron. Craig R. McClanahan wrote: On Thu, 11 Apr 2002, Hans-Joachim Matheus wrote: Date: Thu, 11 Apr 2002 12:36:25 +0200 From: Hans-Joachim Matheus [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: Struts Tags for Visual HTML Components / Java Server Faces [was: ] Struts menu Hi, I'd like to hear a little bit of the ideas of the list members about other visual components that you know from e.g. Swing GUIs that you also would like to see in a HTML GUI, e.g. a Tree component. That is exactly the space that JavaServer Faces will live in, along with the associated infrastructure to make it work. What will be the relationship of such menu, tree, and other components to Java Server Faces. My plan is to make it easy to use Faces components to build the UI of Struts based applications, without having to mess with struts-config.xml, your actions, or any of that stuff. We'll (obviously) continue to support the existing HTML tag library, but I suspect most people will tend to choose the Faces tags for new apps, once they become available. Is it worth putting much effort in such components, e.g. tag libraries, If you need them right now, it's absolutely worth the effort. Doing a simple visual component like a date chooser widget (three select boxes for month/day/year) is pretty easy -- a bean class to represent the properties and a new tag to render it. Doing something like a tree control is *much* more complex. I helped do a really kludgy one inside the Struts-based Tomcat 4 administration application (download recent nightly build sources and look in the webapps/admin directory if you're curious), but would be very interested in ideas on how to do that more elegantly. or will some kind of Java Server Faces standarts kind of blow away the allready done work. (@see Log4J) That must be why the #1 question I received at JavaOne was what's the deal with JavaServer Faces and Struts? :-) How do you think will the now better and more trustworthy Javascript-DOM-capabilities of the new browsers influence such components. That only helps if your users have the new browsers :-) Would like to hear your 0.02 Euro-Cents ;-) Absolutely! Hans-Joachim Matheus 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]
Current release and dependent commons projects.
A bug was fixed in BeanUtils a couple of weeks ago after the lock-down, it's there now and I'd like to use it to make the nested iterate work as planned when using Map collections. Is the reference in the commons code going to stay the same, or next phase going to take new code?... Craig, I saw you put your two cents into the release of BeanUtils and Validator, is Struts 1.1 going to use these releases?... Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: NestedNotEqualsTag doesn't implement NestedPropertySupport
Rob,
It implements NestedNameSupport, which is an extension of
NestedPropertySupport. So in a way it does implement it. The statement
is therefore somewhat redundant in the other tags that implement
NestedNameSupport.
Currently, the tags that you can get the name reference from, you can
get the property reference from.
I still have to do an audit and clean this all up, but it's certainly
but pressing at the moment.
Arron.
Rob Leland wrote:
In doing the UML for the nested Logic tags I noticed
that the NestedNotLogicEqual doesn't implement
NestedPropertySupport
public class NestedEqualTag extends EqualTag implements
NestedPropertySupport, NestedNameSupport {
public class NestedNotEqualTag extends NotEqualTag implements
NestedNameSupport {
Is this an oversite, and if not why ?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: NestedFormTag in cvs head
Fixed. You were right, old servlet.jar did it. It puzzles me that the other iterate tags work in this scenario, as the container would have to write in these methods that it wouldn't know about. Anyways... Arron. David Winterfeldt wrote: I wondered if it might be something like this, but I didn't look into this at all last night. I think I kept my servlet jar reference to Tomcat 3.x for a backwards compatibility check. Since we're still keeping Struts compliant with Tomcat 3.x, we probably need to change this. David --- Rob Leland [EMAIL PROTECTED] wrote: David Winterfeldt wrote: v1.3 of src/share/org/apache/struts/taglib/nested/html/NestedFormTag.java won't compile for me. David I bet you are using Tomcat 3.X, JSP 1.1 ? I believe it uses a JSP 1.2 construct. -Rob -- Robert Leland ([EMAIL PROTECTED]) 804 N. Kenmore Street Arlington, VA 22201-2225 Voice: 703-525-3580 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ -- 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: NestedFormTag in cvs head
It fails to compile here consistently?... Compiles fine for me. The NestedIterate does the same thing with its super.doAfterBody() method use also, it's a surprise that it would only fail on this one. Arron. David Winterfeldt wrote: v1.3 of src/share/org/apache/struts/taglib/nested/html/NestedFormTag.java won't compile for me. [javac] symbol : method doAfterBody () [javac] location: class org.apache.struts.taglib.html.FormTag [javac] int temp = super.doAfterBody(); Anyone else having this problem? David __ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ -- 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: Beta 1 update
+1 Is the beta process here a lock-down, only code going into the full release on the version being direct patches?... or is code being committed as usual, just winging it without trying to upset the apple cart?... Just curious. Arron. Martin Cooper wrote: First of all, I sincerely apologise to you all for the length of time it is taking to get Beta 1 out the door. Unfortunately, I managed to get sick, and still haven't quite got back to full strength yet. A few things have happened since I tagged the CVS tree for Beta 1. 1) Craig has made a boatload of bug fixes to the code base. 2) Arron made some changes to the nested taglib which he requested be included in Beta 1. 3) David made many changes to Validator and the way it hooks into Struts. He also updated some of the files in CVS to tag them as part of Beta 1. 4) Rob is checking in UML diagrams as I write this. Given these changes, and especially given the already-updated tags in CVS, I think it would make sense at this point to retag the entire tree to pick up the latest of everything as Beta 1. This would give us a better, stronger, first beta. I promise to complete the beta release process in one phase this time, to avoid a repeat of the current situation. Is everyone OK with this approach? -- Martin Cooper -- 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: DO NOT REPLY [Bug 7103] - digester parsing error in struts-config.xml contained in struts-tiles
Martin, Something fuzzy happened here. I updated my CVS without seeing the fixed status, and all other config files were fixed but the tiles one. I checked in a change also, two commits shouldn't break something should it?... I checked in something last night, that I think missed your beta tagging. I didn't get it in before the tagging as I wanted to test it more thoroughly. Any chance of having it picked up?... There were a couple of people on my back about the lack of it. Arron. [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7103. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7103 digester parsing error in struts-config.xml contained in struts-tiles [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-03-14 05:18 --- Fixed in 20020313 nightly build. Will be fixed in Struts 1.1 Beta 1. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Struts 1.1 Beta 1 Release Plan
-- Vote:Struts 1.1b1 Release Plan [X] +1I am in favor of the release, and will help support it [ ] +0I am in favor of the release, but am unable to help support it [ ] -0I am not in favor of the release [ ] -1I am against this proposal (must include a reason). -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Example Webapps...
Currently, there's no example in Struts for use of the nested tags. This should be fixed. But to ask the committee's opinion on how... it can be anything from just packaging up my existing monkey example, or make another which is a little more straight :) Another option is to adapt one of the existing examples to have a section of it use the nested tags. Ted, doesn't one of yours use some dot notation?... so this could almost be there as it is. People like examples. I don't mind site traffic, but I'm sure that people would like one in the distribs. No? Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: The missing release plan
2 That way there's less room for people feeling their intended effort missed the boat. Arron. Martin Cooper wrote: Through informal discussion, we decided to go to Struts 1.1 Beta 1 on March 4th, which is today. However, I've realised that I dropped the ball, and did not produce a release plan, to be voted on by the committers. So the question is, how should I best recover? Here are a couple of options: 1) Continue with a Beta 1 release in the next day or so, regardless of a vote on the release plan, but depending on when the crucial fixes are checked in. 2) Post a release plan ASAP, and await a go vote before proceeding with the Beta 1 release. Other suggestions are welcome. Committers, please let me know what you would like me to do in this respect. -- Martin Cooper -- 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: Bean - DOM
How about the mechanism that comes with JDK 1.4?... They've added an XML marshalling system to provide an alternative to serializing objects. You can just pump a bean through the XMLEncoder and you'll end up with an XML document. Get the same document and run it through the XMLDecoder and viola, you're back ad your java object! Quite tidy. Arron. Incze Lajos wrote: On Fri, Mar 01, 2002 at 02:38:20PM +0300, Roman V. Petrov wrote: Did anyone write JavaBean-XML DOM converter that can be used with Struts? Sources, URLs and ideas will be appreciated. 1. domify.sourceforge.net. 2. jakarta-commons/jxpath (xpath access to bean and/or xml resources) Not DOM, but may fill your bill and MANY-MANY others. The order above is not by rank. I simply supposed that you want to give your beans to some xml mechanism (e.g. xsl) to process. Domify is simply that. I've mentioned the jxpath, also because it seems to me a more inventious answer to the same question. incze -- 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: why is iterate tag final?
It's not a final class in the nightly builds. None of the tags in cvs are final. A legacy detail. Arron. Jeff Goke wrote: I am curious why the iterate tag is declared as final? I was writing a wrapper tag to simplify the process of showing pages of information (since this is an extremely common requirement) but quickly realized I cannot extend the iterate tag. Right now I am resorting to taking the source from the class and just implementing the new class using the source, however, this hardly is an ideal solution. Does anyone know why this is a final class? Thanks, -Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
OptionsColleciton Tag...
Just a quick one to say that I think that this tag is a much more natural fit than the original option tags. Amazing what can be done in hind-sight. Nested version works just groovy and is now in there also. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/web/exercise-taglib html-select.jsp
Martin, Can I get a simple example bean and markup of its various options, so I can see how I have to get it nested?... Ta. Arron. [EMAIL PROTECTED] wrote: martinc 02/02/22 23:10:30 Modified:doc/userGuide struts-html.xml src/exercise-taglib/org/apache/struts/webapp/exercise TestBean.java src/share/org/apache/struts/taglib/html LocalStrings.properties web/exercise-taglib html-select.jsp Added: src/share/org/apache/struts/taglib/html OptionsCollectionTag.java Log: Add new html:optionsCollection tag, as discussed last November. I don't particularly like the tag name, but I couldn't think of anything better. Revision ChangesPath 1.2 +421 -1jakarta-struts/doc/userGuide/struts-html.xml Index: struts-html.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/struts-html.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- struts-html.xml 20 Feb 2002 00:41:14 - 1.1 +++ struts-html.xml 23 Feb 2002 07:10:30 - 1.2 @@ -3430,7 +3430,7 @@ element. This tag can be used multiple times within a single codelt;html:selectgt;/code element, either in conjunction with or instead of one or more codelt;html:optiongt;/code -elements./p +or codelt;html:optionsCollectiongt;/code elements./p pThis tag operates in one of two major modes, depending on whether or not the codecollection/code attribute is @@ -3570,6 +3570,426 @@ rtexprvaluetrue/rtexprvalue info CSS stylesheet class to be applied to this HTML element. +/info +/attribute +/tag + +tag + +nameoptionsCollection/name +summary +Render a Collection of Select Options +/summary +tagclassorg.apache.struts.taglib.html.OptionsCollectionTag/tagclass +bodycontentempty/bodycontent +info +pRenders a set of HTML codelt;optiongt;/code elements, +representing possible choices for a codelt;selectgt;/code +element. This tag can be used multiple times within a single +codelt;html:selectgt;/code element, either in conjunction +with or instead of one or more codelt;html:optiongt;/code +or codelt;html:optionsgt;/code elements./p + +pThis tag operates on a collection of beans, where each bean +has a stronglabel/strong property and a strongvalue/strong +property. The actual names of these properties can be configured +using the codelabel/code and codevalue/code attributes +of this tag./p + +pThis tag differs from the codelt;html:optionsgt;/code tag +in that it makes more consistent use of the codename/code and +codeproperty/code attributes, and allows the collection to be +more easily obtained from the enclosing form bean./p +/info + +attribute +namelabel/name +requiredfalse/required +rtexprvaluetrue/rtexprvalue +info +The property of the bean within the collection which represents +the label to be rendered for each option. Defaults to label. +/info +/attribute + +attribute +namename/name +requiredfalse/required +rtexprvaluetrue/rtexprvalue +info +The attribute name of the bean whose properties are consulted +when rendering the current value of this input field. If not +specified, the bean associated with the form tag we are nested +within is utilized. +/info +/attribute + +attribute +nameproperty/name +requiredtrue/required +rtexprvaluetrue/rtexprvalue +info +The property of the form bean, or the bean specified by the name +attribute, that will return the collection of objects to be +rendered for these options. +/info +/attribute + +attribute +namestyle/name +requiredfalse/required +rtexprvaluetrue/rtexprvalue +info +CSS styles to be applied to this HTML element. +/info +/attribute + +attribute +namestyleClass/name +requiredfalse/required +rtexprvaluetrue/rtexprvalue +info
Re: Nested properties everywhere....
Superficially it appears that it would un-clutter things because it would mean less tags, but there's no reliable way to know that a value is to be taken as a nested property. The dot delimiter is not enough, because in most nested cases there is no dot, as it's relative to the parent tag. This means that there has to be an extra property in the tag like... property-values=true ...or similar, and it's not like we want to feel the civil uprising if we made it the default logic. So it's already making the markup more messy just to turn it on. Then add the scope and name details to get your bean, and not only does it add an extra property to the tag, but it also has to be adapted on the inside for every property for every tag. That makes the inside more messy also. Implementing it is not a simple change to PropertyUtils, but to every tag for every property that you want to use the ability. Then add it to the nested tags (because they have to take the value of the property and evaluate the qualified nested version), and the effort has to be duplicated yet again. In my opinion, the cleanest and most intuitive solution for all parties is to leave the tags to do what they do best, and that would include the define tag. Arron. Johan Compagner wrote: I know i can do 2 define to get the maxRows and startCounter i do it now because there is not other way but it clutters the view and is a bit annoying to constantly define things. Nested everywhere for every tag where you can define a bean would be so much nicer and the jsp code would be much cleaner to read.. And it is a small modification for BeanUtils (or PropertyUtils) The only thing it needs to do is first check if there is a nested delimiter if so then try to find the first in the specific scope (if any) then do it the current way. johan - Original Message - From: Arron Bates [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Thursday, February 21, 2002 1:19 PM Subject: Re: Nested properties everywhere The tags use direct values or beans themselves to provide values for offsets and such. Would be quite a bit of work to get them all to work off bean properties instead, and there's the added decision of telling the tag that it is to use the values of properties rather than bean refs and values. The nested tags are the same in this regard, as the rely on the original tag to do its thang. When the original tags get the ability, the nested tags will get the ability, but of course they'll add the ability to have the property relative to the current nested bean level. You can get around it though, by using the bean define, working on a property to get a value into a bean reference, then use the bean name for the offsets and such. And of course, when using the nested tags, the bean define will be nested, so it's not like it can't be done. The define tag can also put beans into whatever scope which is one of the things that you're after. Arron. Johan Compagner wrote: Hi, I really would like to see that i can type nested properties everywhere. so every parameter of a tag that can map to a bean in the whatever scope should be able to use nested tags.. So to give an example: logic:iterate id=obj name=listbean.list scope=request offset=listbean.startCounter length=listbean.maxRows ofcouse i could also do this in the above example but it is just a case what should be possible. logic:iterate id=obj name=listbean property=list scope=request offset=listbean.startCounter length=listbean.maxRows This really cleans up the jsp code and is very readable. Or can i use the new nested tags feature for this?? But this does not work: nested:root name=listbean nested:iterate id=obj property=list scope=request offset=startCounter length=maxRows but that doesn't seem to work. johan -- 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: Nested properties everywhere....
The tags use direct values or beans themselves to provide values for offsets and such. Would be quite a bit of work to get them all to work off bean properties instead, and there's the added decision of telling the tag that it is to use the values of properties rather than bean refs and values. The nested tags are the same in this regard, as the rely on the original tag to do its thang. When the original tags get the ability, the nested tags will get the ability, but of course they'll add the ability to have the property relative to the current nested bean level. You can get around it though, by using the bean define, working on a property to get a value into a bean reference, then use the bean name for the offsets and such. And of course, when using the nested tags, the bean define will be nested, so it's not like it can't be done. The define tag can also put beans into whatever scope which is one of the things that you're after. Arron. Johan Compagner wrote: Hi, I really would like to see that i can type nested properties everywhere. so every parameter of a tag that can map to a bean in the whatever scope should be able to use nested tags.. So to give an example: logic:iterate id=obj name=listbean.list scope=request offset=listbean.startCounter length=listbean.maxRows ofcouse i could also do this in the above example but it is just a case what should be possible. logic:iterate id=obj name=listbean property=list scope=request offset=listbean.startCounter length=listbean.maxRows This really cleans up the jsp code and is very readable. Or can i use the new nested tags feature for this?? But this does not work: nested:root name=listbean nested:iterate id=obj property=list scope=request offset=startCounter length=maxRows but that doesn't seem to work. johan -- 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] Modular Applications (the BIG checkin) [LONG]
+1 Ted Husted wrote: I agree that a beta based on the current nightly build is a reasonable course of action for now. My real regret is that we did not get a chance to cut a 1.1 release before the last wave of improvements came done the pipeline. My concern is that either the release-cycle will now be extended, while we absorb the new features, or will be rushed, just to move things along. Of course, Craig's work is consistently excellent, and the likelihood of any actual problems is slight to none. My underlying goal is to remind us that Struts is being used by some very serious teams on some very serious projects. These teams rely on the #.# release stamp to tell them that the codebase is ready for primetime, and it is our responsibility to ensure that it is. I would usually expect changes this significant to live in the nightly build for several months before release. But, keeping the other features out the hands of production teams is now bordering on cruelty. So, I guess, it comes down to in for a penny, in for a pound; are we ready to cut a beta? -Ted. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-struts/doc struts-nested.xml
Sorry 'bout that, but that's all of it. Only a change to the struts.xsl and the nested docco. If you're hacking the stylesheet, then I can roll it back until your go-ahead. Yes/No? Arron. Ted Husted wrote: Arron, Could you hold off any more Commits. I'm in the middle of heavy surgery on the documentation. -Ted. -- 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: Broken link on the site...
Sounds fine to me. Arron. Ted Husted wrote: I'm not exactly sure what happened there, but if there are no objections, I'll proceed along the lines outlined here: http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg04760.html -Ted. Arron Bates wrote: I assume that the site update is the hany-work of Ted?... Is sweet. However the javadoc process or whatever has yet to be run, as the Developer Guide link to the usual package.html docco to the nested tag's is throwing 404's. The mast-head is so much easier to read now. :) Arron. -- 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: how can one track row id......
This should be asked on the users list. They answer and debate this often. You'll most likely end up running through your result set and populate a beans in a list. Then it's up to your own primary key management. Arron. [EMAIL PROTECTED] wrote: In a particular scenario im populating my form using logic:iterate with data fetched based on a query the user may edit or view the same(for each row) lets say im populating my order form with line item enrty and the user wants to edit or view each line item Now how can one generate and track the row ids...do we have any tags or attribues for any tag to do the same. If a tag attribute is doing the same then how can one get the index value generated. I have tried using html:link page=/editdetails.do?action=Edit paramId = % = index1 % bean:message key=edit.lineitems/ /html:link inside the logic:iterate tag is paramId generating an index value if so how do i track/fetch it and at the same time if we use indexed then what should be the value of indexed attribute do we have a clear cut solution for this scenarion -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Broken link on the site...
I assume that the site update is the hany-work of Ted?... Is sweet. However the javadoc process or whatever has yet to be run, as the Developer Guide link to the usual package.html docco to the nested tag's is throwing 404's. The mast-head is so much easier to read now. :) Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Taglib submssion
The Taglibs jakarta project ( http://jakarta.apache.org/taglibs ) is more the place for these tags as it seems as though there's no coupling with struts, just simply handy functionality. Which is what the taglibs project is all about. Arron. Gerard Weatherby wrote: I wanted to send email from a jsp page, so I put together some custom tags to do so. Thought I'd contribute to the open-source movement by providing them for consideration for inclusion in struts. (Or somewhere else, if that's more appropriate.) I've put everything together (src, tld, examples, xml documentation) together as best I could into a web-archive which is at http://www.charlesconsulting.com/struts-mail.war . Gerard WeatherbyVoice: 860-365-0876 Charles Consulting, LLC Fax : 561-258-0876 http://www.charlesconsulting.com -- 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]
Nested Extension - Committed
Well... there it is. - Recreated package.html to be more consistent with the rest of them, provide better developer docco etc. - To get things done, simply created the tld struts-nested.xml file of the others, keeping the docco. There's been all this mention of slowing things down in regards to the tags to see what the spec's going to end up with, so there'll be time to refine this if people feel it's warranted. I think something should be done, but this will give time to decide the colour of the bike shed. One idea I had was to put all the tags from the three libraries into one xml file, then run the stylesheet for each taglib, and that way the stylesheet can pick its tags and if a library nees something specific from any of them (or extends them), it can have it's own stylesheet (this could also be handy for other developers to automate the building of their Struts extensions). Naturally this could also be carried into docco. Say a page is needed where we want a list of all tags, we can simply make another stylesheet. I think you get what I'm driving at. Do the taglic.xml files' process do anthything more than just the html pages and the tld's?... if that's it I can spend a little time on making it happen if people think it's a good thing. - It built perfectly. And tested out through all my tests the same, hence the commit. - I haven't updated any of the site's links to include it as I figure that this is only done on a release basis (the api-1.0 docco etc). correct?... - Also cleaned up the main Struts logo (a clean-up was all that was done. I didn't make it rotate or anything :). It's just that 100% black drop shadow was driving me batty :) (the download is actually smaller too!) Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Nested Extension - Committed
the contrib as a sandbox. But this taglib has been in circulation for some time, and has had ardent support on the Dev list. So, moving forward, I would like to have discussion of why we would put something like this in contrib in the first place. -Ted. Martin Cooper wrote: I have to say that I'm disappointed to see this committed at this time. Craig specifically suggested that this code start out in 'contrib', but that request was not honoured. I happened to agree with that suggestion, but did not feel that I needed to say so, since I assumed that one dissenting comment, especially from Craig, was sufficient to indicate that the proposal needed more thought and/or experimentation. Certainly, any committer can make changes at any time. However, as Ted mentioned, If you believe someone might have a contrary opinon, it's helpful to ask first and proactively resolve any vetos. Personally, I feel that Craig's comments should have been addressed and resolved before any commit was made. I consider ignoring such comments to be bad form. I'm not going to -1 these changes, because I think the nesting taglibs are a useful extension to Struts. However, I'd really like to see us work as a team, in the future, rather than as a group of individuals. -- Martin Cooper - Original Message - From: Arron Bates [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Friday, January 18, 2002 12:28 AM Subject: Nested Extension - Committed Well... there it is. - Recreated package.html to be more consistent with the rest of them, provide better developer docco etc. - To get things done, simply created the tld struts-nested.xml file of the others, keeping the docco. There's been all this mention of slowing things down in regards to the tags to see what the spec's going to end up with, so there'll be time to refine this if people feel it's warranted. I think something should be done, but this will give time to decide the colour of the bike shed. One idea I had was to put all the tags from the three libraries into one xml file, then run the stylesheet for each taglib, and that way the stylesheet can pick its tags and if a library nees something specific from any of them (or extends them), it can have it's own stylesheet (this could also be handy for other developers to automate the building of their Struts extensions). Naturally this could also be carried into docco. Say a page is needed where we want a list of all tags, we can simply make another stylesheet. I think you get what I'm driving at. Do the taglic.xml files' process do anthything more than just the html pages and the tld's?... if that's it I can spend a little time on making it happen if people think it's a good thing. - It built perfectly. And tested out through all my tests the same, hence the commit. - I haven't updated any of the site's links to include it as I figure that this is only done on a release basis (the api-1.0 docco etc). correct?... - Also cleaned up the main Struts logo (a clean-up was all that was done. I didn't make it rotate or anything :). It's just that 100% black drop shadow was driving me batty :) (the download is actually smaller too!) Arron. -- 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: Pre Nested Extension Commit...
Oleg V Alexeev wrote: AB Making it one with the current library?... AB It can, but so can the html library. But for many reasons I go against AB it. One, the simple fact that they're all working off the same basic AB premise, the same relationships that the html tags work off of. So if AB it's done for one, it's done for all. If you do for all, it's another AB property which has to be added to each tag, and is entirely a lot more AB work with what I definitely feel is a less elegant solution in the end. AB The clean and efficient markup needed for the nested tags is just... AB well... sexy! AB :) Good. So, can you create mirror of existing tags with nested features with intention to merge base and nested tags together? If yes, then we don't need to support two different brunches of tags with similar code. They don't have similar code at all. The nested tags rely on the old tags to do exactly what they do best. They just link them together so that they have a parents and children etc. The difference between say, the code in the nested:equals tag is almost identical to that in the nested:text tag. It's just that they extend different classes to do what they do. I'd recommend taking 10 minutes to take a look at the source for the nested tags to see just how separate they are. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Pre Nested Extension Commit...
I think the real proof of concept was when the nesting extension continued to work well after the multiapp changes. It was a non-event because you guys managed to separate the tags and such (let's call them view components), from everything else (the servlet etc. Lets for naming sake, call it... say... the controller). The beans I suppose we can call it the model or something... (VCM?) ;) Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Pre Nested Extension Commit...
First of all, thanks for the votes peoples. Need to confirm something and ask opinions on another before I scuttle the codebase... (need three +1's or 0's, or some -1's with explanations if you please) ... 1) The nested system is going into the main source tree (not contrib)?... 2) The TLD. The nested tags extend the other tags, so this basically means a duplication of their library definition. To date I've just placed all the tags in the one TLD from the others. Any overwhelming opinions to separate the descriptor into the separate parts as the original library (means we would end up with nest-html, nest-logic or whatever). Keep it as one?... 3) The new TLD's docco... To make sure that the new TLD is as current as it can be, I'll create it again rather than just use my current one. In the other TLD's xml files there's a fair amount of docco. My intention here is that any tag which is an extension of an original, I will remove the docco with an exception of a line to say that this is an extension of [orig tag] tag of [orig tld].tld file. Those tags which are new for the extension will have fresh docco. That way it'll keep the size of the TLD down (if question two is +1), and save duplication of the docco and it's maintenance. Refer docco for original tags? I think that that's about what I need clarified before I commit this thing. Ta. (Ted: http://www.dictionary.com/cgi-bin/dict.pl?term=ta ) Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Pre Nested Extension Commit...
I'm not quite ready for that yet ... how about in contrib first? No offense, but what's to be ready for?... It's tested against your multi-app stuff. All works a treat, and being used by tons of happy campers. Or I can just wait until you've played with it... Remember that all the struts-*.tld files are *generated* -- they are not maintained in source separately. The same XML file that is the source of these is also used to produce the reference docco about the libraries. Yup. Noticed that. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Pre Nested Extension Commit...
Oleg V Alexeev wrote: One point to make it one, because of all nested tags are extends tags from different taglibs and use its own internal logic, common for all nested tags. And another point is a little question about adding of nested logic to the existing tags against of new taglib creation. Can it be done? Making it one with the current library?... It can, but so can the html library. But for many reasons I go against it. One, the simple fact that they're all working off the same basic premise, the same relationships that the html tags work off of. So if it's done for one, it's done for all. If you do for all, it's another property which has to be added to each tag, and is entirely a lot more work with what I definitely feel is a less elegant solution in the end. The clean and efficient markup needed for the nested tags is just... well... sexy! :) Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SHORT TERM PLANS]
Ted, Take a squizz at the tutorials I put up on my nested extension page. http://www.keyboardmonkey.com/stats (thinking of putting up a support group page for blatant traffic generators anonymous too. You in? :) Starting off with the war file of everything needed with exception of files needed to run struts. Each file is waiting for them with an underscore on the end so all they have to do is rename it to remove the underscore (when the tutorial specifies) and they're in business. This way I saved files from being seen by the compiler until required. The files are empty with exception of package and import declarations, so they still have to code the body logic. After each milestone there's another war file of everything up to that point. This goes on until the end where there's a running war file at the very end to check against the final running version. As for the tutorial's content, a full version of each source page is available at every step as well as the code supplied on the page itself. Making the milestone war files (six in the tute) were a genuine pain in the ass (that's donkey :), but got it under control with some automated scripts to compile, package and deploy all at once for testing an uploading. I've already had some excellent feedback as to people really getting benefit as to the way the tutorial worked (one even said it was about the best online tutorial they've ever taken). So I think that the effort in creating tutorials in such a manner is beneficial. It does add to the development time however. All that other stuff in the blank.war etc... blank.war was how I first started hacking Struts, so I'm +1 on keeping that system alive. Arron. PS: Any tag extensions planned for the Short Term Plans? :) Ted Husted wrote: Martin Cooper wrote: I'm planning on making some other changes to the Struts build process in the near future, and I could certainly roll these in if people think it would be desirable. Here's a different but related issue. For the example applications, I'm wondering if we want to adopt a file system format that allows someone to download and install the WAR, and have all the source code in place, ready for exploration and tweaking. This is the approach I've been taking with my own examples. http://husted.com/struts/resources/struts-simple.zip http://husted.com/scaffolding/dist/logon.zip The source is under WEB-INF (/web-inf/src/java/ ...), and the build process is setup so you can work on it in place, without going through a deployment phase. This would let us offer example, exercise, and documentation WARs, with source, directly from the Web site where people could try them out as pure applications, and take a peek at how things work. If this meshes with Martin's other plans, I could help with the necessary changes. I'm also meaning to relabel struts-simple as a workflow example, since that it what it has become. The new logon example (above) also includes using Velocity templates with the nightly build, but doesn't use the latest version of the new Velocity Tools, which is also compatible with Struts 1.0. http://cvs.apache.org/viewcvs/jakarta-velocity-tools/ I've also been working on a new version of the Struts blank app, if anyone is interested. http://husted.com/scaffolding/dist/blank.zip Basically the same thing, but with slightly different conventions and (more importantly) a build file that includes options for JavaDocs and building a WAR. I also hope to slip in some kind of stub for unit testing soon, based on some other work I'm doing with Vincent. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Building Java web applications with Struts. -- Tel +1 585 737-3463. -- Web http://www.husted.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]
Multi-App Support the Nested Extension
A note to anyone who's interested... Just tested the extension against Craig's code to make sure everything hums along nicely with the Multi-App stuff, and it does. Runs all my tag tests and the monkey examples as they've always run. Out of the 3000 hits to my running examples for the past 14 days, there's not one 500 response code. And nobody has mailed me to say they couldn't get the extension working. Everything's just peachy. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
The Nesting Extension - Support Site Update.
Peers, Finally have the resource page at a useful level for the general developer community. There's the latest update to the extension, The primer, The tutorial, an advanced topics page and a whole mess of other stuff. Hopefully it will answer all questions which are itching people. Performance, expandability... so on and so forth. I've gone over the tutorial code and file downloads, snippets etc... but there's bound to be something if a couple of people would like to get back to me on it. Anyways... www.keyboardmonkey.com/struts Just go play peoples! Will be mailing the user list tomorrow, so if you want your input included before hand... be quick. :) Now going to go find a life for a couple of days. After then I'll come back, remove the graphics, make the pages boring again so you guys have something ready to add to the user guides... :) Be cool. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Building Form Beans from XML Schema?
Jon, I'm quite certain the parser has the ability, it just doesn't do it. It's the generation of the Java code which is stopping it. I would think you could hack it, so when an object's setter is called automatically call it's validate() method (which the system creates both, so all you'd have to hack is when and where) for each object continuing to set all data (it carries invalid data quite happily, only complains when you ask it to marshal the document out or validate it) and remember all the validation errors which were thrown and just pop them into the pile for Struts. Could be groovy... but it's not an out-of-the-box ability. I've only had the chance to use the schema side of the matter. We use it to create the XML documents against the schema, when we have to do something which requires XML. I don't think my current client is a particular fan of XML per-se. Arron. Jon Ferguson wrote: Arron, Thanks for the hands-on. Shame really.. surely the parser provides this data.. wonder if there's another way to 'compile' that information into a method. BTW, have you used Castor's Object-Relational mapping? The second half of the equation would be to use that to persist the populated beans from within the Action. Cheers, Jon Arron Bates wrote: I've tried to do this with Castor generated objects. Problem is though, is that the errors are not fine grained at all. You validate the document by calling the validate() method on the top node, and you get a yes or a no. You can do this for all of the sub objects, but it's just that, you still have to implement the field validation yourself. Naturally you can't play any tricks with the calling of property methods to work around various issues as your objects are locked down to the automation process. Otherwise it's quite excellent. Arron. Jon Ferguson wrote: ( Republished under appropriate Subject :-( ). Hey, I've been toying with the idea of Modelling my form beans using XML Schema, then generating the actual beans using some XML binding tool like Castor (which should also generate my validate function). I should also be able to use Castor to do RDBMS mapping as well.. (but from a session bean manipulating the formbeans for example). I'm thinking of utilising schema from developments such as RosettaNet, BizTalk Frameworks and ebXML - noting that often the info entered into forms could be the same message information that might be passed between businesses. (Eg. a Purchase Order, etc.). I'm hoping that the result would: a) help to standardize the business app. b) leave it wide open for making use of b-2-b developments such as webServices and the above efforts. c) provide automatic form validation (inherent in the Schema), d) obviate the hand-coading of formbeans. Any comments on this approach? Has anyone tried this? Cheers, Jon -- 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] Part 1.2 Content-Type: text/plain -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Nested tags
I could possibly imagine a change to the form tag, but that would be it wouldn't it?... (yes/no Craig?) I need to look more at this. I only mentioned the form tag as I assume you will need to look up the forwards form beans for the action relative to the app/sub-app. If Resin is not implementing the spec correctly, I'm not interested in changing Struts to accomodate it. And don't think I'm picking on just them - I wouldn't check in the workaround for WebSphere (which didn't allow deleting request attributes for a while) either. That's just it. It's implementing it to the letter. I wont have to tell you what tomcat does :) Personally, I really want to focus on the controller updates first ... then, I will look at nested tags. Sweet. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Building Form Beans from XML Schema?
I've tried to do this with Castor generated objects. Problem is though, is that the errors are not fine grained at all. You validate the document by calling the validate() method on the top node, and you get a yes or a no. You can do this for all of the sub objects, but it's just that, you still have to implement the field validation yourself. Naturally you can't play any tricks with the calling of property methods to work around various issues as your objects are locked down to the automation process. Otherwise it's quite excellent. Arron. Jon Ferguson wrote: ( Republished under appropriate Subject :-( ). Hey, I've been toying with the idea of Modelling my form beans using XML Schema, then generating the actual beans using some XML binding tool like Castor (which should also generate my validate function). I should also be able to use Castor to do RDBMS mapping as well.. (but from a session bean manipulating the formbeans for example). I'm thinking of utilising schema from developments such as RosettaNet, BizTalk Frameworks and ebXML - noting that often the info entered into forms could be the same message information that might be passed between businesses. (Eg. a Purchase Order, etc.). I'm hoping that the result would: a) help to standardize the business app. b) leave it wide open for making use of b-2-b developments such as webServices and the above efforts. c) provide automatic form validation (inherent in the Schema), d) obviate the hand-coading of formbeans. Any comments on this approach? Has anyone tried this? Cheers, Jon -- 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 question
Email starting with How do I are for the struts-user list. This is more for your benefit as it is a community list entirely devoted to solving problems. The developer list is entirely devoted to creating them :) Arron. The only place I've seen the answer is on the strtus-user mailing list. Gupta wrote: Hi, How do i call a jsp usebean property value in another jsp tag? Problem Case: I have an html:hidden element and I want to replace %=transBean.getTransID()% by using jsp:getProperty name=mybean property=transID/ in below statement, html:hidden property=%=transVar% value=%=transBean.getTransID()% / I failed to get the result by coding the below statement: html:hidden property=%=transVar% value=jsp:getProperty name=mybean property=transID/ / The jsp is not parsing the statement full. TAI RAYAKU -- 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: Nested tags
Excuse the ignorance, but how will the multiple-servlet controller change the way JSP views work?... I could possibly imagine a change to the form tag, but that would be it wouldn't it?... (yes/no Craig?) There's been a couple of updates (one is related to the Resin bug that was just submitted. That was fun) some refactoring of the helper class to make it more generally usable for developers wanting to make their own nested tags. But it's still working as it should. ASF can still have it if they want it. I've finished the primer and a step-by-step tutorial which I want to cap off with a little extension to complete the training on the extension (always two there are). ASF want them too?... I still haven't put a spiel out on the user list yet (Tom's done so a few times, and I've seen a post on jGuru :). I'll hold off if it's going to be committed. Arron. Ted Husted wrote: Arron, Once Craig's implementation of the multi-servlet controller comes out, do you think you would have a chance to try and update your nested taglib? http://www.keyboardmonkey.com/struts/index.html At that point [SHORT TERM PLAN ALERT], I'd like to commit it to the nightly build, assuming you would still like to donate it to the ASF. -Ted. Tom Klaasen (TeleRelay) wrote: For the record: I've been playing with Arron's nested tags for a while now, and they seem OK to me. I've had the occasional what the #$%#@ when something didn't work as I expected, but after thinking about it the reason was obvious. This situation occurs with most struts tags (for me, in any case :P), so they do conform to struts standards ;) tomK -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Need Solution
This is really for the struts-user list. However... the error you have pasted here has nothing to do with the username property, but with the bean's property for institution. More specifically, struts can't find it. Could be that you're getter method for the institution property is not public or something similar. The user mailing list is full of friendly chaps that would love to help you out on this. This list is for the cranky and cynical :) Arron. RAO Sreenivasa Kagitam wrote: Hi, We are trying to do small application by using Strut frame work. We have coded a sample jsp with defined tag text.This tag is wroking only for the property as username. It is not working, if you give differnet name other than username. We have taken the example given by you(logon.jsp). Here is the Error what we are getting (We are using Weblogic6.1 as the Application server) Call org.apache.struts.action.ActionServlet.addServletMapping(action/java.lang. String,*.do/java.lang.String) Dec 31, 2001 6:42:22 PM IST Notice Management Application Poller not started for production server. Dec 31, 2001 6:42:22 PM IST Notice WebLogicServer ListenThread listening on port 7001 Dec 31, 2001 6:42:23 PM IST Notice WebLogicServer Started WebLogic Admin Server myserver for domain testDomain running in Production Mode Dec 31, 2001 6:44:09 PM IST Error HTTP [WebAppServletContext(3972952,DefaultWebApp,/DefaultWebApp)] Root cause of ServletEx ception javax.servlet.jsp.JspException: No getter method for property institution of bean org.apache.struts.taglib.html.BEAN at org.apache.struts.util.RequestUtils.lookup(RequestUtils.java:517) at org.apache.struts.taglib.html.BaseFieldTag.doStartTag(BaseFieldTag.java:18 8) at jsp_servlet.__visaautoreversal._jspService(__visaautoreversal.java:213) at weblogic.servlet.jsp.JspBase.service(JspBase.java:27) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.ja va:265) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.ja va:200) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServlet Context.java:2456) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.ja va:2039) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) Here with i am also enclosing the source file(logon.jsp) logon.jsp Could you please let us know at the earliest,If we are going in a wrong direction. Regards, Sreenivas. -- 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: nested : NestedPropertyHelper
The check for NestedSelectTag is no more (removed last night. It wasn't buggy, just not needed). The check is replaced by one on an interface which some 14 or so tags use now. Did you get around the spurious results of the two tags?... Arron. Tom Klaasen (TeleRelay) wrote: -Original Message- From: Arron [mailto:[EMAIL PROTECTED]] Sent: donderdag 20 december 2001 15:25 To: Struts Developers List Subject: Re: nested : NestedPropertyHelper [snip] I also removed the check for the select tag. I had it there from when there was no NestedParentSupport interface. It was the first implementation, then the logic tags were done and they all used it and the realisation was there that it's a state of nesting. Not implementing it means the helper will jump right over it. None of the extended logic tags use it, as you don't want them to be parents. Horrible parents those logic tags... lock their beans under the stairs they do :) These updates are all updated in the downloads and examples except the saving example... http://www.keyboardmonkey.com/struts If there is a better way... somebody tell me. It was the check for instanceof NestedSelectTag that rang alarm bells. The rest should be fine indeed. [snip] Sorry if this didn't help. A part of my frustration is that the extension is *really* simple, and does largely nothing at all. One of the things which has kind of baffled me about this group is the lengths I have to go to tell you you're running the original tags! As I've been saying from day one... ...they just see each other better to render that important little property property out properly. 'tis all. I know, that's why I don't understand the mismatch between the generated code. I'll get back on this. Cheers, tomK -- 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: Nested tags: radio problem
It's already in the system you're using. Just do it! I made it before I released it the second round. It's the new property property section of the Package.html It works off of the tokenizer working off the / character, so you can have anything in between. I allowed this for the naming convention you could use. eg. (Using my monkey example), if you're in a banana bean, and want to go back to levels to the monkey bean, you can use a nice naming convention like this... bunch/monkey/thePropertyIWant So to read it, you know you'll be back at the monkey. Of you can use the old ../../thePropertyIWant. They work a treat. My updated examples use them for the drop down box of taste's for the banana. You can also do absolute paths by using the / at the front to start at the root again. As for your specific problem... I don't really know what you mean by the [something] either. Give the above a bash and hopefully it'll become clear. Keeping in mind that if you do the above to a parent tag, all it's children will nest on from the parent. It's all in Package.html. :) Arron Tom Klaasen (TeleRelay) wrote: Hi Arron, I wonder if it would be possible/desirable if the nested tags supported a ../.. like action (so go up one level again). An example: I have a collection of bean1's, containing a collection of bean2's. I have a form that wants to select a bean2. so I do nested:iterate id=bean1iter property=bean1s nested:iterate id=bean2iter property=bean2s nested:radio property=../selected_bean2_index value=[something to indicate the current index of bean2iter]/ /nested:iterate /nested:iterate Hmm, while writing this down, the [something ...] doesn't seem clean to me... Anyway, any suggestions as how to accomplish this? tia, tomK -- 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: General model question ?
For the indexed property to work, it has to look to its parent. I have to look at the implementation, but all tags which use the indexed property have to rely on the parent iterator to supply the property, otherwise if they put the index on themselves, they wont render their property properly. This will have to be done for every tag. One of the things I considered was to propose placing a nested property in each of the tags to turn on the functionality. But this is an extra property for every tag which are full enough. There are properties already there which are not needed (name attribute), and should be separate. Keeping it separate means cleaning the developer interface, and focusing on the nesting, and letting the tags do what they do best. The nested extension allows you to do more than simply penetrate indexed properties. For the indexed property to do what it is the nested extension does, you would also have to now put them through all the logic tags also. You seen the second example?... and that was just with just using the nested version of the logic:equals tag. Nothing to be scared of either David. The extension integrates very well. I had the benefit of going through two solutions to get to this one. I created an indexed tag which does what the indexed property was meant to do, and also created a tagging system so I could do lists within lists, and ended up with a funky tree structrue managing deal. Then I hooked onto the nesting deal as you see it, and developed it. All three systems are in production, as each one allowed functionality the other couldn't provide. They all work great except the first two have limitations in the Struts framework and required a change to the populate methods in the servlet. Where as the nested extension brought together everything both systems handle and work of logic Struts already handled. There isn't any integration issues at all. They simply fix up the the original tag's inability to see each other to get their nested property sorted out. If all you're after is to get through nested lists, you're down the nesting path. Using the nesting extension means managing it is truly easy, and also allows more possibilities because of it's level of implementation. Arron. David Morris wrote: Arron, You solution sounds much simpler. I was in the process of restructuring my code to work with the iterate tag as written. I used to have rows and columns. I was rewriting to have rows, row, and columns so that I could define and access row attributes. You solution sounds much better. My only reservation is that it is not part of the base package. I don't get to vote on that, but on the surface it sounds better than what is available and I think that nested collection support it should absolutely be part of the Struts base. I think that adding an indexed attribute to the iterate tag would accomplish the same thing. Not sure how hard that would be to accomplish; it seems like all you would have to do is walk up the tree until you hit an iterate that doesn't specify indexed and append its name and current index. If you don't get to an iterate, it would be an error. I am all for your solution or support for indexed on the iterate tag. Did you go down the indexed iterate path? Is it worth pursuing to get something in place? David Morris [EMAIL PROTECTED] 12/18/01 06:34PM The extension means you can forget everything the other tags do and only specify your properties. No need for indexed attribute or otherwise. And the other attributes of the iterate tag(like length and offset) work fine. eg nested:iterate property=listPropertyOne nested:iterate property=listPropertyOne nested:text property=myTextProperty / /nested:iterate /nested:iterate And that is all you'll need. You are right with the original tags. You can do all sorts of awesome nesting, except you can only view and not input. Largely because the indexed attribute will only allow you to penetrate only the one iterate tag to set the nested property correctly. This is what the heart of the nested extension is. Writing the proper nested property correctly. There is a way to do it with the original tags (even without the indexed property)... but it is truly messy logic:iterate name=myForm property=myListProperty indexId=index1 logic:iterate name=myForm property=mySecondProperty indexId=index2 html:text name=myForm property='%= myListProperty[+index1+].mySecondListProperty[+index2+].myLastProperty%' / /logic:iterate /logic:iterate (yes I've been in one end and out the other in terms of nesting stuff). This method also kind of goes against the MVC paradigm. And when you compare it to the simplicity of the nested extension version. There's no comparison. But it did fill a void until I wrote the extension. The extension allows for all kinds of lists within lists and any other kind of nesting you can think of. It also allows for other things to be nested.
Re: General model question ?
The extension means you can forget everything the other tags do and only specify your properties. No need for indexed attribute or otherwise. And the other attributes of the iterate tag(like length and offset) work fine. eg nested:iterate property=listPropertyOne nested:iterate property=listPropertyOne nested:text property=myTextProperty / /nested:iterate /nested:iterate And that is all you'll need. You are right with the original tags. You can do all sorts of awesome nesting, except you can only view and not input. Largely because the indexed attribute will only allow you to penetrate only the one iterate tag to set the nested property correctly. This is what the heart of the nested extension is. Writing the proper nested property correctly. There is a way to do it with the original tags (even without the indexed property)... but it is truly messy logic:iterate name=myForm property=myListProperty indexId=index1 logic:iterate name=myForm property=mySecondProperty indexId=index2 html:text name=myForm property='%= myListProperty[+index1+].mySecondListProperty[+index2+].myLastProperty%' / /logic:iterate /logic:iterate (yes I've been in one end and out the other in terms of nesting stuff). This method also kind of goes against the MVC paradigm. And when you compare it to the simplicity of the nested extension version. There's no comparison. But it did fill a void until I wrote the extension. The extension allows for all kinds of lists within lists and any other kind of nesting you can think of. It also allows for other things to be nested. Like logic tags, and other tags which use a property attribute to access a bean. All tags of this manner have a nested extension counterpart. And that is truly powerful. No longer is it just the text tag, or other input tags which get the indexed property. As for adoption... I would like it to be, but that's not for me to answer :) Even if it was kept separate, the Struts guys would have to paradigm shift their tags to stop the extension from working as expected. And if another tag came out... I think it only takes me 5 minutes to add a tag, and that includes a little testing :) I've finished writing a primer, and it will be on my site in the next day or so, along with a by the hand tutorial. And about a week later I'll post some advanced topics and other specifics of the nested extension. When the Primer's up, it should answer most questions, and the rest will fill in the holes. Here's a pre-release version of my Primer (Please nobody link it. There's still other stuff to be done (like linking a small glossary to various terms) and I'm splitting it to multiple pages)... give it a try for me... http://www.keyboardmonkey.com/BetaPrimer.html As for the build it needs.. it works on any version of struts over release candidate 1.01. Actually works on older ones, but I've extended logic tags which were first released in this build. Maybe I should make a version for the old 1.0, yes?) Any other questions, you know where to find me. Arron. David Morris wrote: Arron, I have been struggling to get the current nested tags to do what I need. My first attempt at this failed when I found I needed the nightly build. Next, I got nested tags working for output and thought this is easy. Then I moved on to input. No support for indexed on the iterate tag. Then I thought I will simply swap the x and y coordinates of my collections. But there is no way I can see to reference a variable of on the length or offset attributes. Now I have come full circle. Does your extension solve this and is it likely to become a standard extension? If the answer to this is no, I guess that I will try adding support for indexed on the iterate tag, seems simple enough, but I haven't spent much time looking at what is available. David Morris [EMAIL PROTECTED] 11/30/01 07:26PM You are right in that the indexed property isn't in the indexed tag. The discussion was more on the new nesting tags that get through all this properly. Go here for the downloads... http://www.keyboardmonkey.com/download/struts/index.html And for a running example... http://www.keyboardmonkey.com/StrutMonkey With any luck they'll be a part of struts soon. You can get the basic iterators to go through more than one level, but it takes some fiddling. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Freetext attribute for all tags...
(I do apologise for this post. It should stop. But for some reason I just can't handle misrepresentation of trying to get markup to work in the largest amount of browsers possible (both those inside and outside the spec). So, if you don't want to hear a rant in reply to a rant, read another email...) Actually Colin, Both your points are misplaced, and you're trying to become a champion of correctness and I find it arrogant and ignorant that you're trying to publish that the need to create a page that works on *more* browsers is incorrect. As for your points... 1) I don't discriminate. In fact... this is all about going the extra step to make sure I *don't* discriminate. And that includes older browsers. You're talking in terms of *only* using non-standard attributes, where in reality they're actually used along side. If a browser doesn't support them, their presence doesn't effect them. So marginwidth works great in IE NS6, but NS4 will ignore it. I use also leftmargin rightmargin in the same tag and NS4 will use them and IE NS6 will ignore them. Result, a page that works in all 4+ browsers, and discriminates nobody. 2) It's not about being browser-specific. As above, it's about including specific attributes amongst standard ones. Not just using the specific ones. So considering all this... the pages I markup work on more browsers than the ones you do, because I'm not bound by the spec. This means... I have a potentially larger user base. Take this little piece of information to a potential client/employer... What's reality?... I am so over this conversation. Arron. * Does a bandwagon go faster if it's painted red?... Colin Sharples wrote: One last comment on this - have a look at the following sites: http://www.anybrowser.org/campaign/ http://www.webstandards.org/upgrade/ which present two other sides to the story: 1) by using browser-specific code you actively discriminate against those who have no option but to use something other than NS or IE (e.g. blind people who need a text-based browser). 2) the recent versions of most browsers, including the big 2, support all the relevant standards anyway, so there's simply no need to be browser-specific. That's reality for ya... Regards Colin M Sharples I/T Architect IBM Global Services New Zealand email: [EMAIL PROTECTED] phone: 64-4-5769853 mobile: 64-21-402085 fax: 64-4-5765616 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: form initialization
The only way which I've done such a thing is with a bean nested one level inside another. The constructor is called on the root bean, and have getters and setters there waiting to handle the parameters that you're passing from your form. In your action, call another method which will then build the nested bean with everything which you need from the database. From then in, reference properties in the internal bean via nested properties. So the sequence happens like this 1) Form is submitted with parameters needed to load the bean. 2) The constructor is called in the root bean and an empty root bean is made. 3) Struts servlet will populate properties with your init parameters. 4) In your action, call a method like initInternalBean() or something. 5) Inside this method, access the properties which were set by the form, and build an internal bean to what you need.. 6) If you have a simple getter method to access the bean you can get to the properties you need via nested properties which you can use thereafter in your JSP's etc. eg. internalBean.beanProperty Is this enough to get across what I'm trying to say?... I can provide a simple code snippet if it's not. If you're worried about managing nested objects in your JSP's I can help there too. ;) Arron. Jon Burford wrote: Greetings! I have a dynamic form which needs to be initialized from the database. If I put code to initialize the attributes in the default constructor of the form bean, all this happens with no problems - the form is displayed with the proper values. My problem is that the form bean needs some of the request parameters from the calling jsp page in order to properly initialize its fields. What is the preferred way of form bean initialization and how can it access request parameters at initialization time? I used a couple hidden form fields which the jsp page initialized to the corresponding request parameters, but this does not take effect until AFTER the constructor is called. Any help would be much appreciated. TIA! Jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Freetext attribute for all tags...
How about leaving it up to the developer who uses the attribute?... we can warn them about it. But let's leave it to them. Why should this group decide if a developer with different requirements / demands etc has the ability to add something to a tag? It's valuable to have it there simply for the anything unforeseen. Including allowing a developer to create a page for a specific browser, right down to a very specific one they hacked from an open source project for use in a custom data kiosk or something. Is there a plan to *enforce* Xhtml?... It's currently an option, but why don't we just enforce it. It's a w3C spec. I get browser specific requests for things all the time, but can I ever turn back to my project manager and say that it can't be done because it's not in a W3C recommendation. I work for a large multinational, and have to support browsers 4+. Many large companies do, and there's no reason at all why it can't be done. Many of these older browsers have little properties that have to be used to get them to do what it is that you need them to do. eg. to get rid of the white space around your html layout for 4+ browsers... body marginwidth=0 marginheight=0 leftmargin=0 topmargin=0 rightmargin=0 Which ones are W3C?... But I have to do it because my business manager signed off on a document that was generated by a graphic designer in another department. Struts doesn't have a html:body tag... and just as well. Is struts meant to be an adaptable tool for reality?... Otherwise... I vote to have the project name changed to Struts - a W3C explicit implementation. [+1] Almost being restrictive for the sake of it. There's no burden to bare, just a few lines of code that never have to be touched, just frisbee that little attribute... and just maybe it'll allow someone to do something they need to do. Arron. * (Something tells me I'm going to stay out of things like this in the future). Martin Cooper wrote: -1 I guess I started this by marking the associated bug report invalid, and adding the comments I received privately from the original reporter. The reasons I am -1 on this are: 1) The attributes for which this has been suggested are not valid per the W3C standards. I do not believe that Struts should be catering to non-standard solutions. Yes, I realise that some browsers support extensions to the standard. However, suppose that attribute 'foo', currently supported by browser X, is eventually standardised such that the standard values are not consistent with what browser X supported. What should we do now? 2) name collisions 3) syntax validation 4) duplication 5) XHTML (need to ignore when value is set) - Original Message - From: Arron Bates [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Sunday, December 09, 2001 11:27 PM Subject: Freetext attribute for all tags... Idea... There was just that too and fro in additional properties needed on html:image... bug in that there was the argument over what to support and what not to support... if there was a standard property (ie: freetext, freeform, uglytext or something) where developers could add a string to be included in the tag as they provide it (with an extra space at the front and back to avoid collisions). If a developer wants to include something to be rendered for one reason or another, Struts not supporting it or otherwise, they can without issue and code hacks that will have to be re-done the next version of the tag, tld etc... It means that the html:image and html:text can do whatever and the developer can still get the width, height and wrap stuff that he needs for nice formatting. Probably not *proper* for all the die -hards out there... but certainly useable, especially for html creatives that seek that extra level of control that Struts hasn't been around yet, doesn't want to or whatever. Just an idea. Arron. -- 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: Freetext attribute for all tags...
It's all reality. Standards and non-compliant realities alike. Take the new DOM scripting model... NS copied IE in the getElementById()... why... because it's truly sweet. But it's not in the spec. It's an example where the spec is not as good as the implementation. W3C are recommendations, and should be treaded as such. I truly feel supporting them only to the limits of their definition is as bad in a reality sense as letting everything through flood-gate style (Like an NS4 layer tag. There's a standard for ya :). It's also a chicken and the egg situation. Specs are more of a snapshot of the here, now and has been. Someone has to break the new ground and implement something for the idea to be had and the need created. Like the NS4 layer tag. But, a committer has already said no, so everything else as they say is pissing in the wind. (It's good to remind people the rules of the system, thanks Ted.) With that, I'm going to get back to my day job. :) Arron. Ted Husted wrote: Jon Wall wrote: Do you want Struts to be a framework for building just mass-market web sites (portals, ecommerce, etc)?? It's my personal feeling that we are providing the tag extensions as a convenience, and that they are ancilliary to the actual framework. I think this will become more evident as other presentation systems, like Velocity, come to support Struts. With the rise of Jakarta Taglibs and the JSPTL, there are fewer and fewer reasons for us to host our own tag extensions. Something that is forefront in my mind right now, is that we should continue to stay the course on the extensions during this transitional period. As it stands, any tag you might want to use can easily be created using bean:write or html:write, and the best thing to do might be for us (meaning me) to better document those techniques. And, as it stands, there is nothing to prevent people from using their own tag extensions with Struts. I think as team we encourage that idea whenever we can. If someone wanted to create and maintain their a set of tag extensions, that supported non-standard attributes, we'd be happy to link to those from the Resource page. But someone else will have to accept that burden. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.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: Freetext attribute for all tags...
I really think questions of compliance and properness are out of context in all truth. You get Html outside that of the struts tags... let's say... 96% of the markup are you're in the most free text you've ever seen in your life. You aint seen the fun of free markup until you've left off a double quote in a table tag ;) Look... if someone wants to get that wrap tag they'll end up managing it on their own textarea wrap=softbean:write name=mybean property=myProperty //textarea ...and drop Struts all together. Hell, I did just this the other day. :) Peoples, I'm sure we can all agree there's a lot more fun ways to screw your code than some freetext in your tags. The technology either helps you, and lets you get where you need to go (and for some people that's a wrap attribute) or it stands in your way and you have to get around it. People who create non-standard Html would have done so in other parts of their markup, and who is Struts to tell them you aint going to make sloppy markup with our stuff. Arron. Ted Husted wrote: Can we let it ride for a week, to see what else comes up? I appreciate input from the developers, but we might want to also see what the other committers have to say. I also just thought of another one: output - since that is what we are really doing, outputting something into the body of tag. I do agree with Craig, that compliance has to be the Prime Directive. If that sometimes means making things more difficult for people who choose to use Struts, because other products choose to be non-compliant, then so be it. I also agree that the framework should encourage proper use, and I do support a number of other design choices we've made in the place, which are not always popular with developers. Like Craig (I imagine), I would instantly veto something like a wrap tag for textarea being part of a tag, since that is a vendor-supplied extension, and not part of the W3C specification. This has always seemed like a likely compromise to me, and I've mentioned doing it several times myself. Though, the argument that there should be no non-standard attributes, carries some weight with me, since that is why we have this problem in the first place. People ran around doing whatever they pleased, standards be dammed. The other question I would ask, is how does this fit in with JSPTL? I don't think any of want to continue supporting tags that overlap with those. If we allow a literal attribute in all of our tags now, is that going trip people up later when we migrate. Might the Jakarta Input taglib's people have any thoughts on this? Eventually, we might want to hook up, and fill in the JSPTL gaps with a single set of Jakarta extensions. But now that we've let the genie out of the bottle, lets hang back and see what other people have to say. -Ted. Oleg V Alexeev wrote: Hello Ted, So, votes for naming of free style attribute for html tags - literal - 2 freetext - 1.5 (already extst) custom - 1 Any other votes or variants? If nothing then it will became 'literal'. Monday, December 10, 2001, 2:02:01 PM, you wrote: TH Is freetext all right with everyone, or should we use something like TH literal TH custom TH or TH verbatim TH It's just that I feel we have not paid close enough attention to the TH naming of things in the past, and we might want measure twice before TH we document this. TH -- Ted Husted, Husted dot Com, Fairport NY USA. TH -- Custom Software ~ Technical Services. TH -- Tel +1 716 737-3463 TH -- http://www.husted.com/struts/ TH -- TH To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] TH For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Best regards, Olegmailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.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]
Last commit to resources.xml...
Ted, Can I get that link changed? Arron. [EMAIL PROTECTED] wrote: husted 01/12/09 15:28:50 Modified:doc/userGuide resources.xml Log: Add several new resources. Revision ChangesPath 1.17 +10 -3 jakarta-struts/doc/userGuide/resources.xml Index: resources.xml === RCS file: /home/cvs/jakarta-struts/doc/userGuide/resources.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- resources.xml2001/11/21 23:54:05 1.16 +++ resources.xml2001/12/09 23:28:50 1.17 @@ -9,6 +9,7 @@ chapter name=Struts Resources href=resources section name=Contributor Taglibs href=taglibs +pa href=http://strutstestcase.sourceforge.net/;bStrutsTestCase v1.5 for JUnit/b/a (by Deryl Seal) is an extension of the standard JUnit TestCase class that provides facilities for testing code based on the Struts framework./p pa href=http://husted.com/struts/resources/MonkeyStruts.htm;bMonkeyStruts/b/a by Arron Bates. An approach to nesting beans./p pa href=http://www.multimania.com/bist77/struts.php;font size=2bREGEXP.VALIDATOR.STRUTS/b/font/a by Emmanuel Boudrant - A validation component that works with Struts 1.0, to manage form validation on server-side and client-side./p pa href=http://husted.com/struts/resources/struts-was.zip;bStruts-WAS.jar/b/a by Christopher Assenza - Modified Struts 1.0 JAR for Websphere 3.5 or 4. Zipped for download. (For additional tips regarding Websphere 3.5 see a href=http://jakarta.apache.org/struts/installation-was352-x.html;http://jakarta.apache.org/struts/installation-was352-x.html/a.)/p @@ -20,8 +21,11 @@ /section section name=Contributor Extensions href=extensions -pa href=resources/pow2acl.htmb Pow2ACL/b/a - Access Control List library. Track of application users roles and permissions. User can be authenticated: - directly using the package API; - using custom JSP tag -libraries. /p +pa href=http://strutstestcase.sourceforge.net/;bStrutsTestCase v1.5 for JUnit/b/a (by Deryl Seal) is an extension of the standard JUnit TestCase class that provides facilities for testing code based on the Struts framework./p +pa href=http://www.objectwave.com/html/tools/tool1_3.htm;bX2J/b/a is a code generation tool for building Struts applications. It includes wizard for easily creating JSPs, and the required Action and ActionForm classes as well as graphical tools for updating the config file. /p +pa href=http://www.inigoserrano.com/ISValidator/en/ejemploStrutsCompleto0010ISValidator.htm;bISValidator/b/a validates data in diferents scenarios, command line arguements, Servlets Parameters, et cetera. Includes example using theLogonForm from the example application. /p +pa href=resources/checker.htmlbStrutsResourcesChecker/b/a - Parses struts JSP files and looks for those tags which make reference to the application properties file. /p +pa href=resources/pow2acl.htmbPow2ACL/b/a - Access Control List library. Track of application users roles and permissions. User can be authenticated: - directly using the package API - using custom JSP tag libraries./p pa href=http://bist77.multimania.com/struts.php#rose;bStruts .. in Rose/b/a by Emmanuel.Boudrant - Use Struts with the Rational Rose UML model. /p pa href=http://husted.com/struts/resources/multi-struts.htm;bMulti-Controller/b/a by Sukachevin, Stoehr - Use more than once ActionServlet in your Struts application /p pa href=http://www.mail-archive.com/struts-user@jakarta.apache.org/msg16093.html;bJavaScript with html:errors - new Struts validation/b/a by Adam Grohs. /p @@ -102,6 +106,7 @@ section name=Books href=books ul +lia href=http://www.atlasbooks.com/marktplc/00670.htm;bStruts Fast Track: J2EE / JSP Framework/b/ab /bby Victor Cekvenich - Practical Application with Database Access and Struts Extensions./li lia href=http://www.amazon.com/exec/obidos/ISBN=1861005512/hitchhikeguidetoA/;bProfessional JSP Site Design/b/a - Wrox book - Features Struts throughout./li lia href=http://www.amazon.com/exec/obidos/ISBN=0735710953/hitchhikeguidetoA/;bJSP and Tag Libraries for Web Development /b/a- by Wellington L. S. Da Silva. Several chapters regarding Struts./li lia href=http://www.redbooks.ibm.com/redpieces/pdfs/sg246134.pdf;bWebsphere Version 4 Application Development Handbook/b/a font size=1(PDF)/font - Chapter 7 covers designing with both the Struts and Websphere frameworks,/li @@ -166,6 +171,8 @@ /section section name=Other Resource Pages href=other +pa href=http://www.ingrid.org/jajakarta/struts/;bJapanese Translation of Struts documentation/b/a as well as the other Jakarta projects)./p +pbStruts and Jakarta mailing lists in Japanese/b - a href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a and a href
Freetext attribute for all tags...
Idea... There was just that too and fro in additional properties needed on html:image... bug in that there was the argument over what to support and what not to support... if there was a standard property (ie: freetext, freeform, uglytext or something) where developers could add a string to be included in the tag as they provide it (with an extra space at the front and back to avoid collisions). If a developer wants to include something to be rendered for one reason or another, Struts not supporting it or otherwise, they can without issue and code hacks that will have to be re-done the next version of the tag, tld etc... It means that the html:image and html:text can do whatever and the developer can still get the width, height and wrap stuff that he needs for nice formatting. Probably not *proper* for all the die -hards out there... but certainly useable, especially for html creatives that seek that extra level of control that Struts hasn't been around yet, doesn't want to or whatever. Just an idea. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Nesting Tags. v2... Now it's truly happenin'
Peoples, More sleepless ones later, I think that I have the nested extension as far as it needs to be for true adoption. All the tags that were applicable (logic and bean), little house cleaning, a bug fix (that cropped up with the new tags), new example, testing JSP for the new tags, tidier look to the old example, yadda yadda. Anyways... It's leapt forward in how useable it is, so here I am telling you about it. For the full spiel, new example, old example, source etc... (hope you like red) http://www.keyboardmonkey.com/struts To go straight to the new example (I think it's quite compelling. Still one JSP page, but a whole lot of dynamic ability)... http://www.keyboardmonkey.com/StrutMonkey/MonkeyStruts_v2.jsp Docco for the package will tell all how it works and the funky new property property addition. (It's also in the wars and jars)... http://www.keyboardmonkey.com/StrutMonkey/Package.html If I can get the Resource link on the Struts Page to point to the first addy it'd be more advantageous rather than a page of mails. I can update this as required. Any questions, you know where to find me. Arron. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Fwd: Re: Extensibility of struts... a solution, maybe
Just a note on this subject You know that you can get absolutely sweet decoupling from everything struts for your data model with the use of nesting objects?... And no messy property copying! I wanted to get a simple persistence mechanism running for my form object, so I placed a little serialization logic into my action (Some app servers need their session objects to serialize also, like iPlanet). The struts action form wouldn't serialize for me so all I did was add an extra nest level and serialized from there down leaving my entire structure nothing but the data that I wanted. All the child objects implement serializeable, extend nothing, and know nothing of struts. This is all elegantly managed in the JSP's with the use of the handy-dandy nesting extension. :) That's my two cents. If you want the code for what I just blabbed on about, mail me... [EMAIL PROTECTED] Arron. (theKM*) * I think, therefore, I nest ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: General model question ?
I didn't code it, but I have to use it. The chaps here did it before I hit the scene. But I have to say that it's quite elegant. You won't find it in the code I've written for nesting extension. I didn't write this, so it's out of my hands to submit it (and I think that their client paid too much for it to give it away), but I can transfer some IP and wouldn't mind working on the actual solution. But back to the story... 1) yes. 2) yes, but the fine grained errors come from another validation mechanism. Where a custom action was made from extending the struts action, and using an interface the the beans implement, fetch's a series of validation rules from the form to run through. This brings the finer grained business driven errors. The Converters themselves however only throw one error per object type. What I'd like to see, and I think that it'd be easy to implement, would be that if a converter failed, that it register an error against the property key that threw it. Then you could write out the errors properly for each instance. 3) No. This would take an extra runtime mapping to say that n inputs go into the one converter. Not currently implemented, but I do agree that it would be some cool functionality. Best I've done is to have a child object that holds the three properties and returns the proper Calendar object when asked by the business logic. The particular system that I work with is robust enough to get the job done, but I think that working in hind-sight would make it a truly nice solution. Arron. Paul Speed wrote: Admittedly, I haven't looked at your code... but can you please verify that it meets the following requirements: 1) All form errors are displayed together. In other words, if more than one field is bad, the user will see all bad fields rather than having to correct them one at a time. 2) The user sees the original data they input. In other words, if the user enters abc into a dollar field, then the form displaying the errors and allowing them to redo their input will also display abc. 3) Data conversion and validation can be done on multiple fields at once. One example is a set of date fields (month, day, year) that together form a single Date object. I always find this topic interesting because I don't think the right answer has really bubbled up yet. That's why I try to understand the different approaches. From my point of view, to meet the above requirements data conversion and validation would have to be done on or within the entire form bean. Since your code sounds like it does this before the data ever gets to the form bean, I just wondered how you solved those issues. -Paul Arron wrote: People reading this thread should also look at the last few in... Re: Fwd: Re: Extensibility of struts... It's touching the same topic. I think that the most important things is what was just raised. The marshaling of strings into more valid objects. One implementation I'm working with has altered the struts servlet to allow the configuration of Converter objects to be mapped to object types, so that you can specify classes that can handle this marshal on a specific need in an automatic process. e.g.: we use BigDecimal for all of our dollar types (financial app), and there's a converter set up to handle the marshaling, and on the inside the model is perfectly fine. A bad marshal also results in an error, and is returned to the input view. Quite neat. Not taking away from skill or intentions, you've all written some sweet stuff, but don't you think (this is more than likely just me. I often think too laterally and get the wrong point on things) that relying on a big property switcheroo from the form object to the data model in the action class is messy and almost defeating the point of struts when it handles everything automatically, excellently and elegantly?... Struts' level of automagic management is something to be beheld, but as a group trying to maintain wads of yukky code that's frizbee-ing data from one object to another. It's like a Ken Done painting hanging on the wall of the Sistine Chapel. Nasty ugly little blemish. Arron. Craig R. McClanahan wrote: On Sun, 25 Nov 2001, box wrote: Date: Sun, 25 Nov 2001 22:53:38 +0100 From: box [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], box [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: General model question ? Thank you Craig, I see the point, You are right it makes a lot of sense. But the behind the scene matter of my question was the performance reason. I have to copy all the properties of ActionForm to appropriate business logic object. The clean way of doing this is using the reflection API, which is rather slow. First, you're going to have to do this type of conversion anyway -- because HTTP parameters come in as strings, you don't want to directly use things like java.util.Date for the properties. Second,
Re: Extensibility of struts Property Security
Yes, yes. Point made. That series of emails makes for some good bedside reading. I think that the solution that was arrived at is fine for protecting the struts system objects themselves. Is there anything happening to allow the developer to protect their own properties from this kind of arbitrary attack? Thought I had would be to configure a property modifier, or property mapping which yields other security properties which have to be checked before a property is set. ie: getMyProperty() property method uses a getMyPropertySecurity() to return a defined value which was set while writing the view so you can't just pass the one key value pair to change a value, but a two key value pairs with the second value being a specific hashing or such. This would stop the casual hacking of any property via the URL. You could also then define a security property for all things struts within the ActionForm. The possibility then in extending this would be to define a security property to each property to be set, or a more simpler global security property for the entire request, and let the developer decide as to how fine grained the property setting security should be, if at all. Just a thought. Arron. Ted Husted wrote: http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=813 So, someone could also call getServlet().setTempDir(whatever) with http://whatever.com/do/someAction?servlet.tempdir=whatever Hmmm. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/struts/ Arron Bates wrote: It doesn't even have to be a careful look at the code. It's not complex in the least. I must be missing something with the String or boolean properties that affect the system state thing. Do you mean what it is that I do with the example, where I have a string property that represents a submit button that add objects to the tree and another that can delete them?... If it isn't, can I get an example?... Arron. -- 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-html taglib
Laurie, The form is largely handled in two parts. The JSP is interpreted and the form inputs are rendered as properties of a bean. The struts tags uses reflection to get a hold of the values held by the bean. These property names are written out as the names of the form elements. When the form is submitted, the struts servlet uses the property names of the form elements to get a hold of the setter methods in the bean and sets them according to the values of those passed by the form. The servlet maps the action URL to the beans that it has to work against. So the the taglib is the mechanism to allow the showing of the values, and the servlet is the mechanism that recieves whatever is set by the tags. This is an automatic process. If your form shows the same page straight after, the values will be populated with those that were sent by the form. The servlet is the first thing to run, so you can't really interrupt this process. As for the validation... I don't know. Where I work wrote their own validation mechanism which I have to abide by. Arron. Laurie Harper wrote: Hi, I'm looking at integrating the struts-html taglib into an existing web application framework to provide form handling support. I understand the form rendering process including how form input fields get populated from the associated bean(s). What I'm not clear on is how the submitted data gets back into the bean when the form is processed or if it needs to be re-displayed. I thought the idea was that you associated your bean(s) with the form and then queried that bean in the action that handles the form submission. Do you have to use the request parameters to retrieve the submitted data? In that case, how does the validate() method come into effect? Sorry if I'm missing something really obvious here... L. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
