Re: I18N - Currency question
On Friday, August 8, 2003, at 08:08 AM, David Thielen wrote: Hi; I am displaying currency in my website. It is always in U.S. dollars so I am doing: NumberFormat.getCurrencyInstance().format( (float) price / 100f ); Two questions: 1.. I assume I should set the locale for this to en_US since I want to have the dollar sign. If your website supports only US English, or if that's the default, then sure. 2.. Should it do the commas and periods to the user's locale - or is everyone used to dollars using the US comma/period setup. If you're supporting other locales, I'd format accordingly. If I was selling something, I'd be as accommodating as possible. 8-) If you're using JSP for presentation, I recommend the JSTL i18n and formatting tags instead of Java code. david thanks - dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using JSTL tags instead of Struts tags
On Thursday, Jul 10, 2003, at 12:34 America/Denver, Yuan, Saul (TOR-ML) wrote: I started using JSTL but found that it encouraged site builders to start embedding logic in JSP's. I'd sure be interested in some examples of this. JSTL doesn't really provide anything more than what you could do yourself with scriptlets and runtime expressions -- indeed, it's a lot LESS than what you could do with those things, in addition to doing it much more succinctly. JSTL does have a few tags that deal with the backend, say the query tag: sql:query ..., with this you can pull data directly in a Jsp page without going through a controller layer. But this doesn't necessarily mean JSTL encourage you to do it this way. JSTL's SQL tags are unfairly maligned, IMO. If you stay away from sql:update and sql:transaction, which clearly break MVC protocol*, your views can pull data from the model and display it (which is what views are supposed to do) with sql:query and the param tags. david *because the views are modifying the model (database) Saul I guess you could say my viewpoint on this is exactly the opposite. Craig - 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: Using JSTL tags instead of Struts tags
On Thursday, Jul 10, 2003, at 08:29 America/Denver, Mark Lowe wrote: I started using JSTL but found that it encouraged site builders to start embedding logic in JSP's. While I can see that JSLT is more powerful, isn't it true to say that it encourages breaking with the view-controller demarcation? Logic in a JSP page is not necessarily a bad thing. Logic that modifies business data is almost always inadvisable, but views have every right to pull data from a model, examine it, iterate over it, make logical decisions based upon it, and of course, display it. I find the struts tags on the other hand, used with zero scriptlet tolerance, forces you to do all the work in your action servlets. The work that you do with JSTL, and therefore in JSP pages instead of actions, involves activities like iterating over data, conditional tests, accessing URLs, i18n, xml manipulation and database access. Except for database updates and transactions, all of those activities are well within the perview of a view. david I'm open to views against mine, and I also wouldn't dismiss the advise of the folks who developed struts, but whenever I read use JSLT it seems to me a step backwards. On Thursday, July 10, 2003, at 03:05 PM, Hookom, Jacob wrote: Start using it and you will :-). The expression language is the best thing since sliced bread. David I agree, I'm even using the EL parser to do stuff on completely different layers for scripting logic. Also, you can VERY easily use JSTL's parsing objects in your own tags to make them a little more flexible. Jacob - Keith -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 9:51 AM To: Struts Users Mailing List Subject: RE: Using JSTL tags instead of Struts tags I don't have any documentation but the only Struts taglibs I use are html and tiles. I replaced my usage of the bean tags with the fmt:message tag and the Struts logic tags are all replaced with a combination of the c:if and c:forEach tags plus the expression language. The JSPs are remarkably easy to maintain and debug using this strategy because there aren't any scriptlets or complicated business logic in them. David --- Kamholz, Keith (corp-staff) USX [EMAIL PROTECTED] wrote: I'd be interested in finding out about this too. -Original Message- From: White, Joshua A (HTSC, CASD) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 7:30 AM To: 'Struts Users Mailing List' Subject: Using JSTL tags instead of Struts tags A previous thread had encouraged me to look into JSTL. It looks like there are several tags which I could use instead of Struts tags. Has anyone come across any documentation about experiences doing this (benefits, drawbacks, caveats)? Anyone care to share their experience? Joshua This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. - 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] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using JSTL tags instead of Struts tags
On Thursday, Jul 10, 2003, at 13:39 America/Denver, Joe Zendle wrote: Yes, if every datasource in the universe is a set of tables in which the schema never changes ;-) Schema changes will be felt somewhere in your app, no matter how you read the database. It's true that industrial-strength apps shouldn't expose database schema to their views, but not all applications require that level of decoupling. It would be an interesting exercise to encapsulate database access in JSP fragments. You could still decouple the database schema from your views, but your fragments could use JSTL, which is considerably easier than JDBC or EJBs. david -Original Message- From: David Geary [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 1:11 PM To: Struts Users Mailing List Subject: Re: Using JSTL tags instead of Struts tags On Thursday, Jul 10, 2003, at 12:34 America/Denver, Yuan, Saul (TOR-ML) wrote: I started using JSTL but found that it encouraged site builders to start embedding logic in JSP's. I'd sure be interested in some examples of this. JSTL doesn't really provide anything more than what you could do yourself with scriptlets and runtime expressions -- indeed, it's a lot LESS than what you could do with those things, in addition to doing it much more succinctly. JSTL does have a few tags that deal with the backend, say the query tag: sql:query ..., with this you can pull data directly in a Jsp page without going through a controller layer. But this doesn't necessarily mean JSTL encourage you to do it this way. JSTL's SQL tags are unfairly maligned, IMO. If you stay away from sql:update and sql:transaction, which clearly break MVC protocol*, your views can pull data from the model and display it (which is what views are supposed to do) with sql:query and the param tags. david *because the views are modifying the model (database) Saul I guess you could say my viewpoint on this is exactly the opposite. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using JSTL tags instead of Struts tags
On Thursday, Jul 10, 2003, at 14:40 America/Denver, David Graham wrote: The work that you do with JSTL, and therefore in JSP pages instead of actions, involves activities like iterating over data, conditional tests, accessing URLs, i18n, xml manipulation and database access. Except for database updates and transactions, all of those activities are well within the perview of a view. So you're advocating placing some database logic in the view and some in Java classes? I've had to maintain apps written that way and it was a complete nightmare. The view has absolutely no business querying the database in all but the simplest apps (3 pages max). No, I'm just saying that reading the database from a view is sometimes a viable alternative for smaller applications, especially if you encapsulate reading the database within the view itself. I realize I'm bucking traditional wisdom but I don't like to see sql:query lumped together with sql:update and sql:transaction. The last two are much more offensive than the first. david David david I'm open to views against mine, and I also wouldn't dismiss the advise of the folks who developed struts, but whenever I read use JSLT it seems to me a step backwards. On Thursday, July 10, 2003, at 03:05 PM, Hookom, Jacob wrote: Start using it and you will :-). The expression language is the best thing since sliced bread. David I agree, I'm even using the EL parser to do stuff on completely different layers for scripting logic. Also, you can VERY easily use JSTL's parsing objects in your own tags to make them a little more flexible. Jacob - Keith -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 9:51 AM To: Struts Users Mailing List Subject: RE: Using JSTL tags instead of Struts tags I don't have any documentation but the only Struts taglibs I use are html and tiles. I replaced my usage of the bean tags with the fmt:message tag and the Struts logic tags are all replaced with a combination of the c:if and c:forEach tags plus the expression language. The JSPs are remarkably easy to maintain and debug using this strategy because there aren't any scriptlets or complicated business logic in them. David --- Kamholz, Keith (corp-staff) USX [EMAIL PROTECTED] wrote: I'd be interested in finding out about this too. -Original Message- From: White, Joshua A (HTSC, CASD) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 7:30 AM To: 'Struts Users Mailing List' Subject: Using JSTL tags instead of Struts tags A previous thread had encouraged me to look into JSTL. It looks like there are several tags which I could use instead of Struts tags. Has anyone come across any documentation about experiences doing this (benefits, drawbacks, caveats)? Anyone care to share their experience? Joshua This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. - 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] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
Re: Using JSTL tags instead of Struts tags
On Thursday, Jul 10, 2003, at 15:18 America/Denver, Mark Galbreath wrote: Is this the same David Geary that wrote, among others, Advanced JavaServer Pages? Yes. david Mark -Original Message- From: David Geary [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 5:09 PM To: Struts Users Mailing List Subject: Re: Using JSTL tags instead of Struts tags On Thursday, Jul 10, 2003, at 14:40 America/Denver, David Graham wrote: The work that you do with JSTL, and therefore in JSP pages instead of actions, involves activities like iterating over data, conditional tests, accessing URLs, i18n, xml manipulation and database access. Except for database updates and transactions, all of those activities are well within the perview of a view. So you're advocating placing some database logic in the view and some in Java classes? I've had to maintain apps written that way and it was a complete nightmare. The view has absolutely no business querying the database in all but the simplest apps (3 pages max). No, I'm just saying that reading the database from a view is sometimes a viable alternative for smaller applications, especially if you encapsulate reading the database within the view itself. I realize I'm bucking traditional wisdom but I don't like to see sql:query lumped together with sql:update and sql:transaction. The last two are much more offensive than the first. david David david I'm open to views against mine, and I also wouldn't dismiss the advise of the folks who developed struts, but whenever I read use JSLT it seems to me a step backwards. On Thursday, July 10, 2003, at 03:05 PM, Hookom, Jacob wrote: Start using it and you will :-). The expression language is the best thing since sliced bread. David I agree, I'm even using the EL parser to do stuff on completely different layers for scripting logic. Also, you can VERY easily use JSTL's parsing objects in your own tags to make them a little more flexible. Jacob - Keith -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 9:51 AM To: Struts Users Mailing List Subject: RE: Using JSTL tags instead of Struts tags I don't have any documentation but the only Struts taglibs I use are html and tiles. I replaced my usage of the bean tags with the fmt:message tag and the Struts logic tags are all replaced with a combination of the c:if and c:forEach tags plus the expression language. The JSPs are remarkably easy to maintain and debug using this strategy because there aren't any scriptlets or complicated business logic in them. David --- Kamholz, Keith (corp-staff) USX [EMAIL PROTECTED] wrote: I'd be interested in finding out about this too. -Original Message- From: White, Joshua A (HTSC, CASD) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 7:30 AM To: 'Struts Users Mailing List' Subject: Using JSTL tags instead of Struts tags A previous thread had encouraged me to look into JSTL. It looks like there are several tags which I could use instead of Struts tags. Has anyone come across any documentation about experiences doing this (benefits, drawbacks, caveats)? Anyone care to share their experience? Joshua This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. - 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] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --- - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e
Re: Using JSTL tags instead of Struts tags
On Thursday, Jul 10, 2003, at 15:14 America/Denver, David Graham wrote: --- David Geary [EMAIL PROTECTED] wrote: On Thursday, Jul 10, 2003, at 14:40 America/Denver, David Graham wrote: The work that you do with JSTL, and therefore in JSP pages instead of actions, involves activities like iterating over data, conditional tests, accessing URLs, i18n, xml manipulation and database access. Except for database updates and transactions, all of those activities are well within the perview of a view. So you're advocating placing some database logic in the view and some in Java classes? I've had to maintain apps written that way and it was a complete nightmare. The view has absolutely no business querying the database in all but the simplest apps (3 pages max). No, I'm just saying that reading the database from a view is sometimes a viable alternative for smaller applications, especially if you encapsulate reading the database within the view itself. Then you're only advocating this approach for apps that don't update database data at all, they just view it. Given an app that doesn't update data, is around the 3-5 page mark, and doesn't have to support multiple database types, I agree with you. I have yet to come across any app that fits that description though. You could modify database data in actions (I know, I know) and read it from JSPs. Granted, it's not the best design, but I bet you could scale up to 5-7 pages with it. 8-) david David I realize I'm bucking traditional wisdom but I don't like to see sql:query lumped together with sql:update and sql:transaction. The last two are much more offensive than the first. david David david I'm open to views against mine, and I also wouldn't dismiss the advise of the folks who developed struts, but whenever I read use JSLT it seems to me a step backwards. On Thursday, July 10, 2003, at 03:05 PM, Hookom, Jacob wrote: Start using it and you will :-). The expression language is the best thing since sliced bread. David I agree, I'm even using the EL parser to do stuff on completely different layers for scripting logic. Also, you can VERY easily use JSTL's parsing objects in your own tags to make them a little more flexible. Jacob - Keith -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 9:51 AM To: Struts Users Mailing List Subject: RE: Using JSTL tags instead of Struts tags I don't have any documentation but the only Struts taglibs I use are html and tiles. I replaced my usage of the bean tags with the fmt:message tag and the Struts logic tags are all replaced with a combination of the c:if and c:forEach tags plus the expression language. The JSPs are remarkably easy to maintain and debug using this strategy because there aren't any scriptlets or complicated business logic in them. David --- Kamholz, Keith (corp-staff) USX [EMAIL PROTECTED] wrote: I'd be interested in finding out about this too. -Original Message- From: White, Joshua A (HTSC, CASD) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 7:30 AM To: 'Struts Users Mailing List' Subject: Using JSTL tags instead of Struts tags A previous thread had encouraged me to look into JSTL. It looks like there are several tags which I could use instead of Struts tags. Has anyone come across any documentation about experiences doing this (benefits, drawbacks, caveats)? Anyone care to share their experience? Joshua This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. - 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] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: JSTL Book
On Thursday, Jul 10, 2003, at 17:14 America/Denver, Mark Galbreath wrote: Craig's recommendation notwithstanding, I think the best JSTL book on the market right now is David Geary's Core JSTL: Mastering the JSP Standard Tag Library, (Sun/Prentice-Hall 2003). It is a really good read and has plenty of concrete examples. Thanks Mark. I must say Shawn's book is very good, as is Han Bergsten's JSP book, which has thorough coverage of JSTL. Shawn and Hans are both nice guys and sharp as razors. I haven't read JSTL KickStart or Sue Spielman's book, which is coming out soon. If you want more information about Core JSTL, see www.core-jstl.com. If you're interested in JavaServer Faces, see www.corejsf.com. Core JSF is in the making! And keep in mind that Craig doesn't always recommend the BEST book, but the book his friends have written. I'd like to think Craig is my friend. 8-] david Mark -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 6:43 PM On Thu, 10 Jul 2003, Mike Duffy wrote: Date: Thu, 10 Jul 2003 15:39:49 -0700 (PDT) From: Mike Duffy [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Subject: JSTL Book Does anyone have a recommendation for a good JSTL book? I like Shawn Bayern's book about it (JSTL in Action). Shawn did a lot of the heavy lifting on the implementation (the standard taglib in Jakarta Taglibs), so he definitely knows what he's talking about. Craig - 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: Sell me on tiles
The major selling point of tiles is that you can encapsulate, and reuse, page layouts, much as you can reuse layout managers in classic UI frameworks such as Struts. Beyond that, tiles have many other features that will save you a great deal of time and effort, such as extending an existing tile to create a new one. david Southard, Don wrote: We are starting a fairly new project using struts. We are at a point where we need to make a decision on using tiles or not using tiles. On one hand it's not too hard to implement (one developer already has it working with our project). On the other hand we haven't seen any added functionality that would really make us want to go with this feature. All that said can someone give me some brief points on why we should use tiles? -- L. Don Southard 303 218 4823 x4823 - 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: AW: [OT] Eclipse IDE - The Two Towers
Kenny Smith wrote: Hi s.frank, I think your first paragraph and second make different points. I completely disagree that choice of IDE is just an aesthetic choice. Your second point about the Perforce-Integration is talking about specific functionality. If your project requires specific functionality, then the choices of IDEs are limited. However, people think differently. Take NetBeans and Eclipse. They do the same job, but they do it in VASTLY different ways. Why? Because different people have different ideas. One person will be far more productive using Eclipse and a different person will be more productive with NetBeans. Yes. Seriously... who _cares_ if it's easier for an administrator to setup a new box. That is a one time event and completely gets lost in the amount of time a developer will spend using the machine. In addition, IDEs are pretty darn easy to install. My box at work came without one, I chose my favorite and installed that one. Sure -- let each developer set up their own environment. It's a myth that using one IDE improves team performance. I agree. Consider Struts (and thus getting this thread somewhat back on topic). Who cares what IDE Craig or Ted or any of the other committers use? In an OO development environment, define the interfaces between subsystems, divie up the work, and integrate the work of different developers when the time comes. How each developer accomplishes his subsystem is immaterial as long as the functionality and interfaces are well-defined. david Kenny Smith JournalScape.com [EMAIL PROTECTED] wrote: I think there exist many and more fruitful ways to express your individuality than using IDE A rather than that ide B. If the IDE is not important, why not standardize one: Makes it easier for administrators to setup new boxes, allows to pass the box to another member of your team, allows to use the same plug-ins and so on: Just think about Integration with version-Control: Cowboy-Coder A uses Eclipse which has a bug with Perforce-Integration, Cowboy-Coder B insists on using IntelliJ, which has no Perforce-Integration at all: And the Newbie-Coder comes in and is totally confused as there exist three ways of setting up your enviroment. No Standards at all are ok if you have a team-size of one... --- Ursprüngliche Nachricht --- Datum: 21.01.2003 16:20 Von: James Childers [EMAIL PROTECTED] An: Struts Users Mailing List [EMAIL PROTECTED] Betreff: RE: [OT] Eclipse IDE - The Two Towers I second this. Different people work in different ways; standardizing an IDE for every developer ignores this rather key fact of human nature. If my company were to standardize on an IDE that some people don't like, they're just going to be frustrated and bitter, decreasing productivity. *shudder* Thank Baal they don't do that at my company. Everybody can use whatever development tools they want, so long as the code compiles and passes the unit tests. I use Eclipse and Vim, primarily. If management tried to take away Vim I would have to tell them to... well... You get the idea. Speaking of which, I've been tinkering with IDEA lately, and it looks quite promising. Tight, and as fast as Eclipse. Plus I like the fact that I can do everything within it without using the keyboard. And it can do regexp search and replaces, which is one of the main things keeping me married to Vim right now. -= J -Original Message- From: Alex [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 9:16 AM To: Struts Users Mailing List Subject: Re: [OT] Eclipse IDE - The Two Towers On Tue, 21 Jan 2003, Daniel H. F. e Silva wrote: My boss wants a standard environment to all developers. So, order is order. I think his concern about this task is to improve productivity. So, what is more productive? If he wants productivity then let the developers use the tools they are familiar with. -- 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: Session Values for Action.LOCALE_KEY Change
What server are you using? I've seen this behaviour with Resin-ee-2.1.4. It worked for me when I used Tomcat, so I assumed it was a Resin bug. david David Graham wrote: Do you directly link to the index.jsp or go through the controller servlet? You say the locale in the session is different on index.jsp, verify that you're in the same session between pages. Hope that helps, Dave From: micael [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Session Values for Action.LOCALE_KEY Change Date: Tue, 10 Sep 2002 14:13:28 -0700 I set the session locale in a language.jsp page with: session.setAttribute(Action.LOCALE_KEY, new Locale(language)); where language is a return from a form parameter locale via: String localeValue = request.getParameter(locale); String language = localeValue.substring(0, 2); This works on all pages, except the index.jsp page. I can set the language variable to ko and the entire site will stay on Korean, but when I go to the index.jsp page, it is back to English. If I go from the index.jsp page back to the other pages, they stay in Korean. I am very puzzled. Any ideas. I posted this before, but it chopped my code off. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx -- 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: Help with master-details screens
If you forward, the URL won't change. If you really want it to change, you can do a redirect instead. david Hoang, Hai wrote: Transaction token only prevent resubmitting. How can I prevent URL of the detail page from showing on the master page? -Original Message- From: Trieu, Danny [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 10:55 AM To: 'Struts Users Mailing List' Subject: RE: Help with master-details screens Use transaction token provided by the form tags. -Original Message- From: Hoang, Hai [mailto:[EMAIL PROTECTED]] Sent: Monday, September 09, 2002 8:53 AM To: 'struts-user' Subject: Help with master-details screens The user clicks on a link on the master page, which lead to a detail page so that the user can modify stuff. Once he is done and submitted the changes, I saved it and forwarded the request back to the master page. The problem is that the URL still shows the link of the detail page on the master screen. If I reload the master page, the changes I made on detail screen submits to the back end database again. How can I prevent URL from showing on the master screen and prevent resubmitting? Thanks, Hai _ Introducing the all new and improved continental.com. With a totally new personalized design, it's the best place to go. Before you go. Continental Airlines. Work Hard. Fly Right. http://www.continental.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Introducing the all new and improved continental.com. With a totally new personalized design, it's the best place to go. Before you go. Continental Airlines. Work Hard. Fly Right. http://www.continental.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: Struts -- JSF roadmap
Craig R. McClanahan wrote: I will have time to expand on this at length over the weekend ... but the things I described in my JavaOne BOF on Struts 1.1 last March look like they're going to come true (which is good news for Struts folks). In the meantime, here's a short summary of JSF: Faces is essentially Struts with a Component UI model. Components are server-side Java objects that implement client-side controls such as HTML textfields, buttons, forms, etc. Components are sort of like Swing components that speak HTTP and are fitted with an HTML (or WAP, or whatever else you want) look and feel. Faces compenents can be fitted with renderers, event handlers, and validators. Faces comes with a standard set of HTML components and a corresonding JSP tag library (like Struts html tags) that let you use those components. Faces also manages the lifecycle of your web application with a controller servlet, very similar to Struts. You can associate renders and event-handlers to server-side components. That means you can write your own custom components for the markup language of your choice. For example, you could implement a component that renders a calendar in HTML or a component that renders a simple WAP form. You can also associate validators with a component. Validators validate a component's input. Another way to think of Faces is this: Take the Struts html tags and rewrite them so that instead of producing html directly, the tags delegate to a component that produces HTML. And you can plug your own custom components into those tags for a different markup language (although you'll want to change the html prefix to something else, like faces). Finally, you can create a new tag and a corresponding component to implement something wild like a WAP calendar. Faces overlaps to a great extent with Struts, although for the EA release, it implements that overlapping functionality much more inelegantly than Struts. For example: 1. If you want a form bean, you've got to create it yourself with jsp:useBean in a JSP page. [gasp!] 2. You must manually specify the component field that a control stores its value in, instead of letting the framework take care of it with reflection. Ugh. 3. You specify validators, not in a config file, but for each control in a JSP page. 4. There are no actions: you handle all of your application's controller code in one method (processEvent) in a Java class called the Application Handler. Unless this changes in subsequent releases, your controller logic with Faces will be much more difficult to maintain than it is with Struts. 5. The tag names are quite verbose compared to Struts html tags. For example, here's how you might declare a form that contains a textfield with Faces: %-- Create the form bean --% jsp:useBean id='loginFormBean' class='LoginFormBean' scope='session'/ faces:usefaces faces:form id='simpleForm' formName='simpleForm' table tr tdName:/td td %-- Create an HTML input element, specifying the associated model property and two validators -- faces:textentry_input id='name' modelReference='loginFormBean.name' faces:validator className ='javax.faces.validator.RequiredValidator/ faces:validator className ='javax.faces.validator.LengthValidator/ /faces:textentry_input /td /tr tr tdPassword:/td td faces:textentry_secret id='password' modelReference='loginFormBean.password'/ /td /tr /table pfaces:command_button id='submit' commandName='Log In'/ /faces:form /faces:usefaces Unless you can somehow plug Face's component model into Struts, I don't see much of an integration strategy. We'll have to let Craig enlighten us on that. david Craig On 6 Sep 2002, Bryan Field-Elliot wrote: Date: 06 Sep 2002 12:33:37 -0600 From: Bryan Field-Elliot [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts-User [EMAIL PROTECTED] Subject: Struts -- JSF roadmap I was wondering if there are others out there who have read the (preliminary) JSF (Java Server Faces) drafts, tutorials, etc., with opinions on how they relate to Struts? With Craig the spec lead on JSF, and Craig also being a primary mover (as well as original inventor) of Struts, I am hoping he will come forward with some real opinions on the matter, such as, where are the areas of overlap between the two? I believe there may be overlap in validation area, as well as in the general
Re: concern over validation results
Rick Reumann wrote: On Thursday, September 5, 2002, 5:11:40 PM, Devin wrote: RDND are you doing your validations in JavaScript (html:javascript RDND formName=myForm /) or are you doing it on the server with Java RDND (myForm::validate())? I'm using DynaValidatorForm and the validation that should take place after I set up validation.xml and use the validator-rules.xml. It only seems to return the required errors first, then it will go through and check again upon the next submit for any other errors. Maybe I have things set up wrong, but that's how it's behaving for me. I doubt that you've set things up wrong, because I've experienced the same problem, among others, using the validator. My feeling is that the validator's not quite ready for prime-time with Struts; I've gone back to implementing form beans by hand and coding validation in the bean's validate method. That works, and I have more control over the process. david -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JavaServer Faces and Struts
I'd really like to hear about the overlap and integration between Struts and JSF also. david Sandra Cann wrote: Craig, You'd mentioned in one email on this list more news when JSR-127 eventually goes to public draft. Now that that's happened I was wondering if you might tell us more about how you see things happening as related to a good integration between Struts and JavaServer Faces is clearly important, and I will be in a pretty good position to make sure that it happens :-). I was curious how your role as lead on both projects has influenced your ideas for how they integrate together? It was my understanding that there was some overlap between JSF and Struts. How do you see this changing if at all? How do you expect the spec to influence the future direction of Struts? Sandra [EMAIL PROTECTED] P.S. Expresso 4.1ea4 is available for download; and we expect very soon releasing a full 4.1 release. -- 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: Not using JSP as the view
Ted Husted wrote: There are also tags for doing XML/XLS conversions within the JSP. http://jakarta.apache.org/taglibs/doc/xsl-doc/intro.html I suggest that folks use the JSP Standard Tag Library (JSTL) XML actions instead. I'm not familiar with the taglib cited above, but after a quick perusal of the website it looks as though the JSTL actions have the same functionality. And, of course, JSTL is a standard. david -Ted. Billy Ng wrote: Hi folks, I am thinking to repsonse the XML instead of HTML. In Struts, how can I response to the browser without displaying the JSP as the view? Thanks! Billy Ng -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VALIDATOR] Bad Error Message when Validating a Range
Ted Husted wrote:
It looks right to me, David (and welcome back, BTW).
Me too, and thanks.
Maybe we need to add a test case to the validator sample app to be
sure everything is still working as advertised.
That's probably a good idea. I think it needs some rigorous testing;
I've run into other problems also.
Are you using beta 2 or what?
I'm using the nightly build from 8/19.
david
-Ted.
David Geary wrote:
Sorry to repost this, but it got buried in a bunch of biere messages
yesterday...
I'm trying to validate a range using the validator. I've got this in
validation.xml...
form-validation
formset
form name='loginForm'
field property='number' depends='range'
arg0 key='login.number.displayName'/
arg1 name='min' key='${var:min}' resource='false'/
arg2 name='max' key='${var:max}' resource='false'/
var
var-namemin/var-name
var-value5/var-value
/var
var
var-namemax/var-name
var-value10/var-value
/var
/field
/form
/formset
/form-validation
...and this is how the field is defined in the form:
html:form action='login.do' focus='name'
table
tr
tdfmt:message key='login.number.displayName'/td
tdhtml:text property='number'//td
/tr
/table
/html:form
The validation works: If I enter a value outside of the range, I get
an error, and if not, I don't. But it's the error message that's the
problem:
Number is not in the range null through null.
For some reason, even though the validator uses the correct min and
max for validation, the error message doesn't reflect that. I've got
the field display name and error message defined in my resource
bundle, like this:
login.number.displayName=Number
errors.range={0} is not in the range {1} through {2}.
Does anyone know what's wrong?
Thanks,
david
--
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: template
Hi Keven, Struts templates do not work with HTML frames; I believe that's the cause of your problem. (If anyone has gotten them to work with frames, please holler). When I originally developed templates, I tried to get them to work with frames, but it was very difficult. If I remember correctly it's because each frame creates its own request, which wreaks havoc with templates. That said, you really shouldn't need to resort to frames, because templates gives you pretty much the same functionality, except for being able to resize regions. I don't know if Tiles (which is an extension of templates) works with frames; my guess is that they don't, but Cedric should be able to answer that. Cedric, are you listening? btw, you're probably better off using Tiles or a later version of templates. Both implementations offer similar capabilities; which you prefer is largely a matter of taste. You can read about the later version of templates and download the source code at: http://www.javaworld.com/javaworld/jw-12-2001/jw-1228-jsptemplate_p.html. david Keven wrote: Hi, All: I have a template jsp called template.jsp. The content of template.jsp is: %@ taglib uri=/WEB-INF/struts-template.tld prefix=template % html head titletemplate:get name='title'//title /head frameset rows=20%,* FRAME src=template:get name='header' flush='true'/ FRAME src=template:get name='content' flush='true'/ /frameset /html I have another jsp file called index.jsp which uses the template.jsp. The content of index.jsp is: %@ taglib uri=/WEB-INF/struts-template.tld prefix=template % template:insert template='/template.jsp' template:put name='title' content='Templates' direct='true'/ template:put name='header' content='/welcome.html' direct='true'/ template:put name='content' content='/tour.html' direct='true' / /template:insert Whenever I tried to run it in tomcat, I got Apache Tomcat/4.0.4 - HTTP Status 404 - /welcome.html type Status report message /Welcome.html description The requested resource (/Welcome.html) is not available. Apache Tomcat/4.0.4 - HTTP Status 404 - /tour.html type Status report message /tour.html description The requested resource (/tour.html) is not available. I got the above messages in different frame.I don't know what cause the problem. Some one knows how to fix it? Thank you very much Keven -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Using the template tag library with parameters like jsp:param
CB Thomas wrote: With jsp:include, I can pass parameter values to the included page by using jsp:param. Can I get this functionality using the Struts template tag library? Yes. Use the direct attribute, like this: template:put name='title' content='Templates' direct='true'/ Then in your template, you can access that value; for example, like this: htmlheadtitletemplate:get name='title'//title/head.../html Normally, the template:get tag will include content associated with the named parameter, but if you specify direct='true' with template:put, the template:get tag will just retrieve the value. See http://www.javaworld.com/javaworld/jw-09-2000/jw-0915-jspweb_p.html for more information about templates and the direct attribute. btw, if at all possible, I suggest that you use Tiles instead of templates. The former, which is an extension of the latter, has more functionality. If so, can I use request.getParameter to retrieve values in the included page? No, but you can use template:get as illustrated above. david _ Chat with friends online, try MSN Messenger: http://messenger.msn.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: [VALIDATOR] Bad Error Message when Validating a Range
Thanks for the suggestion, but that didn't work either.
It's strange because I'm validating other fields in the same form and
the error messages are correct for those fields. Also, If I change the
range message in the resource bundle, that change is reflected in the
message, but it always displays null for both the min and max values,
even though the validator correctly uses those values to perform the
validation.
david
micael wrote:
David, should you be adding the msg/ as I have below AND,
shouldn't login.number.displayName=Number be
login.number.displayName=number?
At 08:40 AM 8/30/2002 -0600, you wrote:
Sorry to repost this, but it got buried in a bunch of biere messages
yesterday...
I'm trying to validate a range using the validator. I've got this in
validation.xml...
form-validation
formset
form name='loginForm'
field property='number' depends='range'
msg name=number key=
login.number.displayName/
arg0 key='login.number.displayName'/
arg1 name='min' key='${var:min}' resource='false'/
arg2 name='max' key='${var:max}' resource='false'/
var
var-namemin/var-name
var-value5/var-value
/var
var
var-namemax/var-name
var-value10/var-value
/var
/field
/form
/formset
/form-validation
...and this is how the field is defined in the form:
The validation works: If I enter a value outside of the range, I get
an error, and if not, I don't. But it's the error message that's the
problem: Number is not in the range null through null. For some
reason, even though the validator uses the correct min and max for
validation, the error message doesn't reflect that. I've got the
field display name and error message defined in my resource bundle,
like this: login.number.displayName=Number errors.range={0} is not in
the range {1} through {2}. Does anyone know what's wrong? Thanks, david
--
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]
[I18N] Locale Mysteriously Reverts to null
I have an action that sets the user's locale with Action.setLocale(). After I set the locale, I verify that it's been set with request.getSession().getAttribute(Action.LOCALE_KEY). It has. Then the action forwards to a JSP page and within that JSP page, the locale is null, which I verify with %= session.getAttribute(Action.LOCALE_KEY) %. How do I make the locale stick, and why does it revert to null? Thanks, david -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [I18N] Locale Mysteriously Reverts to null
Resin 2.1.2. I hadn't thought to try it with another container, so I tried it with Tomcat 4.1.3, and it works as expected, that is, the locale doesn't revert back to null. I just assumed it was something I was doing wrong, but evidently it's a Resin bug. Thanks, david James Mitchell wrote: That sounds a bit odd. What container are you using? James Mitchell Software Engineer\Struts Evangelist Struts-Atlanta, the Open Minded Developer Network http://www.open-tools.org/struts-atlanta -Original Message- From: David Geary [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 31, 2002 10:51 PM To: [EMAIL PROTECTED] Subject: [I18N] Locale Mysteriously Reverts to null I have an action that sets the user's locale with Action.setLocale(). After I set the locale, I verify that it's been set with request.getSession().getAttribute(Action.LOCALE_KEY). It has. Then the action forwards to a JSP page and within that JSP page, the locale is null, which I verify with %= session.getAttribute(Action.LOCALE_KEY) %. How do I make the locale stick, and why does it revert to null? Thanks, david -- 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: [I18N] Locale Mysteriously Reverts to null
Resin 2.1.2. I hadn't thought to try it with another container, so I tried it with Tomcat 4.1.3, and it works as expected, that is, the locale doesn't revert back to null. I assumed it was something I was doing wrong, but evidently it must be a Resin bug. Thanks, david James Mitchell wrote: That sounds a bit odd. What container are you using? James Mitchell Software Engineer\Struts Evangelist Struts-Atlanta, the Open Minded Developer Network http://www.open-tools.org/struts-atlanta -Original Message- From: David Geary [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 31, 2002 10:51 PM To: [EMAIL PROTECTED] Subject: [I18N] Locale Mysteriously Reverts to null I have an action that sets the user's locale with Action.setLocale(). After I set the locale, I verify that it's been set with request.getSession().getAttribute(Action.LOCALE_KEY). It has. Then the action forwards to a JSP page and within that JSP page, the locale is null, which I verify with %= session.getAttribute(Action.LOCALE_KEY) %. How do I make the locale stick, and why does it revert to null? Thanks, david -- 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]
[VALIDATOR] Bad Error Message when Validating a Range
Sorry to repost this, but it got buried in a bunch of biere messages
yesterday...
I'm trying to validate a range using the validator. I've got this in
validation.xml...
form-validation
formset
form name='loginForm'
field property='number' depends='range'
arg0 key='login.number.displayName'/
arg1 name='min' key='${var:min}' resource='false'/
arg2 name='max' key='${var:max}' resource='false'/
var
var-namemin/var-name
var-value5/var-value
/var
var
var-namemax/var-name
var-value10/var-value
/var
/field
/form
/formset
/form-validation
...and this is how the field is defined in the form:
html:form action='login.do' focus='name'
table
tr
tdfmt:message key='login.number.displayName'/td
tdhtml:text property='number'//td
/tr
/table
/html:form
The validation works: If I enter a value outside of the range, I get an
error, and if not, I don't. But it's the error message that's the problem:
Number is not in the range null through null.
For some reason, even though the validator uses the correct min and max
for validation, the error message doesn't reflect that. I've got the
field display name and error message defined in my resource bundle, like
this:
login.number.displayName=Number
errors.range={0} is not in the range {1} through {2}.
Does anyone know what's wrong?
Thanks,
david
Re: [VOTE] Should this list discontinue it's long, treasured heritage of relaxed fridays?
I don't mind the relaxed Fridays, but I wish important emails wouldn't get buried in an avalanche of nonsense. I've posted a question about validation twice now, only to see it disappear under a mountain of beer messages (I'm guilty of generating one myself) and this voting business. I wish someone would take a look at my validation question, and I'm sure others get frustrated when the same thing happens to their questions. david Eddie Bush wrote: Do you feel this list should discontinue it's long heritage of relaxed fridays? ( ) Yes ( ) No --- Rather than being a jerk, as some people don't mind to do, I thought it would be very much in the spirit of your community to let everyone have a say. Cast your 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: Java Server Faces and Developer Life Comments
Elderclei R Reami wrote: Hi, Even though, I'm passionate about Java, I need to recognize: M$ really makes UI development a lot easier than Sun/Java/Open Source Community. If you ever developed a VB app and a Swing-based Java app, knows what I mean. FWIW, I agree that .NET is a great deal easier to use than any open source J2EE combo pack currently available. Last fall, I was invited to a 3-day, all expenses paid workshop that introduced .NET to Java authors, (since when would Sun do anything like that for MS authors?) and I was blown away by the simplicity and elegance of .NET. Also, I noticed that Scott McNealy himself made a comment in a recent interview to the effect that whoever advertises the most wins. I'm an avid reader of the New York Times and I've noticed numerous full-page .NET advertisements in that newspaper over the past few months and zero adds for Java or J2EE. One degree of freedom. Indeed. Finally, as a Java author, I've watched in abject horror as Java book sales have plummeted over the past year and .NET books have gradually gained ground. Watch out, J2EE, the .NET juggernaut is at your back and coming up fast. I haven't read the entire JSF spec, but I've seen the tutorial, and as far as I understand it, JSF does not make programming UI interface much easier than Struts. Actually, it's much worse than that. After reading through the JSF tutorial, JSF makes developing UIs *more difficult* than Struts. As it's currently spec'd, JSF can't hold a candle to Struts, even though it's obviously a blatant, inelegant Struts imitation. Want to use form beans with JSF? You've got to create them yourself with jsp:useBean. Want validation with JSF? Get ready to write some Java code and plug it into the framework. All that for what -- 2 years of development (not to mention a year late)? I just sent feedback to the JSF expert group stating my concerns with JSF and I suggest that others on this mailing list read the tutorial and spec and do the same. In the spirit of the Friday biere messages: c'est dommage! david Any comments? The matter is: I have a family, and want to get home earlier, not 4:00AM. A lot of philosophy and online psychoterapy for FRIDAY, but... :) Cheers, Elderclei R Reami Vertis Tecnologia +55 11 3887-0835 www.vertisnet.com.br -- 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]
Documentation for writing custom validators available?
Is there any documentation available that shows how to implement a custom validator for a field form with the validator? I've read the section in the O'Reilly book, but I found it to be more confusing than helpful. Thanks, david -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Validating a Range
I'm trying to validate a range using the validator. I've got this in
validation.xml...
form-validation
formset
form name='loginForm'
field property='number' depends='range'
arg0 key='login.number.displayName'/
arg1 name='min' key='${var:min}' resource='false'/
arg2 name='max' key='${var:max}' resource='false'/
var
var-namemin/var-name
var-value5/var-value
/var
var
var-namemax/var-name
var-value10/var-value
/var
/field
/form
/formset
/form-validation
...and this is how the field is defined in the form:
html:form action='login.do' focus='name'
table
tr
tdfmt:message key='login.number.displayName'/td
tdhtml:text property='number'//td
/tr
/table
/html:form
The validation works: If I enter a value outside of the range, I get an
error, and if not, I don't. But it's the error message that's the problem:
Number is not in the range null through null.
For some reason, even though the validator uses the correct min and max
for validation, the error message doesn't reflect that. I've got the
field display name and error message defined in my resource bundle, like
this:
login.number.displayName=Number
errors.range={0} is not in the range {1} through {2}.
Does anyone know what's wrong?
Thanks,
david
Re: [BEER] Is it Friday Yet?
Je bois beacoup de biere dans mon bureau tous les jour. ;-) david Galbreath, Mark wrote: Je pars du bureau tot pour obtenir une biere. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 2:21 PM Can we have a [Mark] tag added? +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: PROPOSAL: Template Screens
Cedric's got some good ideas here, and I agree with someone else who said he should be a committer. Craig? david Cedric Dumoulin wrote: Hi David, and everybody, I understand David's position, there is a proverb which said "who go slowly go surely" ;-) But, please, don't forget that I have already work for a long time on Components proposal. A lot of peoples have tried them, and give positive feedback, as well as improvement, on proposed features. Also, people hesitate to use Components in long term because they are not sure that Components will be maintained if they are not part of a large project. I think that everyone could take advantages if we join our efforts to propose a strong "Extended Templates Proposal", rather than to propose two tools providing nearly the same. Saying that, here are some ideas for Template Screens Proposal : I think that we can reuse actual Templates syntax, rather than introducing too much new tags or using scriptlet. This will simplify learning and comprehension of Templates. Following is an example of how we could define a screen inside a jsp : -- template:screenDefinition id='introductionScreen' scope='request' template='/chapterTemplate.jsp' template:put name='title' content='Templates' direct='true'/ template:put name='header' content='/header.html' / template:put name='sidebar' content='/sidebar.jsp' / template:put name='content' content='/introduction.html'/ template:put name='footer' content='/footer.html' / /template:screenDefinition --- To use it : template:insert definition='introductionScreen' / --- Or, if you want to overload one attribute : template:insert template='/anotherchapterTemplate.jsp' definition='introductionScreen' / --- Or, if you want to overload or add others attributes : template:insert definition='introductionScreen' put name='title' content='Another Title' / put name='leftSidebar' content='/leftsidebar.jsp' / /template:insert' --- Some comments : * In the "screenDefinition", you can define all or only some of the attributes. So, you can drop "template='/chapterTemplate.jsp' " * If you specify some attributes in 'insert' tag, they overload previously defined attributes, or add new one. * This syntax is implementation independent : object produced by tag handler 'template:screenDefinition' could be a Map, or a complex structure. * There is no 'role' attribute in the example, but we can use it. * Advantage of this syntax is that it is the same than 'insert'. This syntax can also be used in a xml description file, without introducing new concepts. * Another advantage, is that there is no scriplet inside JSP page. Now, we need to find a way to define 'screenDefinition' outside a JSP page (ex: in action). A Map could be a candidate. But putting 'content', 'content-type' (direct) and 'role' inside Map's value is not so easy to use. We could thing of a class ScreenDefinition, having some method reflecting the tag syntax : setTemplate( String templateName ) put( String name, Object content ); put( String name, Object content, boolean direct ); put( String name, Object content, boolean direct, String role ); ... Such class could be easiest to use in code. Once an instance is created, it is put in servlet context (request, session, ...). Then, object is used in the same way as if it is define in the JSP page : template:insert definition='screenDefinitionName' / However, it is possible to implement insert definition="aDefinition" / in order to accept a Map as well as a ScreenDefinition, if we want to keep both possibilities. Last, I thing that tag name 'template:screenDefinition' is too restrictive : we could effectively define a screen , but we can do much more with it, like defining a 'Component' ;-) . So maybe we need to propose something else for this tag name (first ideas : 'template:definition', or 'template:instance' ). Cedric David Geary wrote: I see template screens as a first step towards Cedric's Components. Template screens provide the foundation necessary for Components: Programmatically defining screens. The next step is adding support for defining screens from an XML file, whether that's struts-config.xml or a separate file. Then we can add inheritance and locale support. I want to build this iteratively, with a design that reflects Struts design patterns (such as screen definitions that are analagous to the Map bean in the Link tag)*, rather than adopting Cedric's code wholesale. I'm more than willing to have Cedric or others pitch in some code. david * The Struts map-bean-property-to-request-parameter design pattern. Cedric Dumoulin wrote: A kind of "screen configuration" (calle
Re: PROPOSAL: Template Screens
Yes, that's a good idea, applicable for static screens. We should still allow for programmatic definitions, though. Servlets or servlet filters are good candidates for creating dynamic screen definitions. david Wong Kok Wai wrote: Is it possible to define the screen definition in the struts-config.xml? I think this will be more flexible. __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
PROPOSAL: Template Screens
Joel Regen wrote:
David,
Wouldn't it make sense to introduce a few attributes to the template tags
that allow specification of values using references to beans? This idea is
used extensively in the other struts tags. Look at the html:link tag, for
example. It allows you to specify a bean that contains a property that can
be used as the value for a named request parameter. This kind of
parameterization is fairly powerful.
Indeed.
With these attributes in place you can leverage the use of the controller
actions (in an MVC architecture) to setup one or more 'template specifiers'
in session or request context and redirect to the JSP that contains the
template tags. It alleviates the need for extensive use of logic: tags.
yes?
Absolutely. Thanks to Joel for pointing this out! I found his email so
inspiring that I took a crack at this in my local build. Here's how it works:
Currently, you use templates like this: (this is from the struts-template
example)
%@ taglib uri='/WEB-INF/tlds/struts-template.tld' prefix='template' %
template:insert template='/chapterTemplate.jsp'
template:put name='title' content='Templates' direct='true'/
template:put name='header' content='/header.html' /
template:put name='sidebar' content='/sidebar.jsp' /
template:put name='content' content='/introduction.html'/
template:put name='footer' content='/footer.html' /
/template:insert
Collectively, template:put tags within a template:insert tag define a screen,
which is equivalent to a single Web page. Each screen contains regions; for
example, there are five regions in the code fragment above: title, header,
sidebar, content, and footer. Those regions, identified by the name attribute,
either include content or print it directly, depending upon the direct
attribute.
The template:put tag stores its three attributes--name, content, and direct--in
an instance of ScreenDefinition. That class is a simple faade for a hash
table. (See org.apache.struts.taglib.template.util.ScreenDefinition).
I've added a new template tag** that lets you specify that screen definition
directly. Here's how you use it:
%@ page import='org.apache.struts.taglib.template.util.Content'%
%@ page import='org.apache.struts.taglib.template.util.ScreenDefinition' %
% ScreenDefinition screenDefinition = new ScreenDefinition();
screenDefinition.put("title", new Content("Struts Templates Example",
"true"));
screenDefinition.put("header", new Content("/header.html", "false"));
screenDefinition.put("sidebar", new Content("/sidebar.jsp", "false"));
screenDefinition.put("content", new Content("/introduction.html",
"false"));
screenDefinition.put("footer", new Content("/footer.html", "false"));
%
template:screen template='/chapterTemplate.jsp'
screen='%= introductionScreen %'/
The template:screen tag effectively lets you move the template:put tags into a
bean (a ScreenDefinition). But creating that bean is too painful because the
author must know about the Content and ScreenDefinition classes (I can hardly
remember where they are or what they're called). We can fix the problem with
another tag that creates a screen definition, like this:
template:screenDefinition id='introductionScreen' scope='request'
regions='%= new String[] {
"title", "header", "sidebar", "content", "footer" } %'
content='%= new String[][] {
{ "Struts Template Example", "true" }, // title
{ "/header.html","false" }, // header
{ "/sidebar.jsp","false" }, // sidebar
{ "/introduction.html", "false" }, // content
{ "/footer.html","false" } // footer
}%'
/
The template:screenDefinition tag creates a screen definition and stores it in
the specified scope, with the specified id. For the code listed above, that
screen definition is named introductionScreen and it's placed in request scope.
You can specify any of the four scopes (page/request/session/application).
With the screenDefinition tag, the author only deals with String arrays,
instead of Content and ScreenDefinitions.
Templates are powerful because they centralize page layout, which simplifies
page maintenance, and allows global changes. The tags proposed here let you
define numerous screen definitions in a single JSP file, which centralizes your
screen definitions.
Like templates themselves, which simplify page layout and enable global layout
changes, screens simplify screen creation and maintenance, and allow global
screen changes.
david
* The ContentMap class has been renamed to ScreenDefinition.
** I wanted to
Re: Has anyone implemented security and authentication in a Struts app?
Davina and Mac wrote: Has anybody out there implemented a roles-based security system in a Struts application? If so, did you use an existing class library or write your own? It seems to me that relying on container providers for security schemes makes it almost impossible to write portable applications, and Struts/MVC, with its single point of access and clearly defined actions would be an ideal place to implement security... thoughts anyone? Relying on container provided authentication is, by definition, nonportable. So you are correct: It is impossible to write a portable application that relies on container provided authentication. On the other hand, it's not that hard to bypass servlet containers and write your own authentication. This is what the Struts example application does with a CheckLogon custom tag. david
Re: Has anyone implemented security and authentication in a Struts app?
Mihir Parekh wrote: role based security is part of servlet 2.2 specs. That's true. So, if you are using servlet 2.2 container the application will remain portable. The servlet specification does not address how to specify users and roles; for example, Tomcat3.2 specifies them in $TOMCAT_HOME/conf/tomcat-users.xml, which you edit to suit your application. Resin, on the other hand doesn't have a XML file like Tomcat does, so you must write some code (by implementing an Authenticator) to specify users and roles. The bottom line is that you must specify users and roles in a nonportable way. It gets worse, from a portability standpoint, when you consider that the servlet specification does not provide setter methods for user principals and roles. That restriction means that only servlet containers can set user principals and roles. Most servlet containers provide an API to set them, but use of that API is obviously nonportable. The only way to ensure portability is to implement authentication from scratch, including support for user principals and roles, if you need them. Fortunately, it's not that difficult to do. david Mihir Davina and Mac wrote: Has anybody out there implemented a roles-based security system in a Struts application? If so, did you use an existing class library or write your own? It seems to me that relying on container providers for security schemes makes it almost impossible to write portable applications, and Struts/MVC, with its single point of access and clearly defined actions would be an ideal place to implement security... thoughts anyone? Mac Ferguson
Re: Struts, WebLogic 6.0 and template tags
"Craig R. McClanahan" wrote: Maya Muchnik wrote: Hello, Torsen, It is not an answer to your question. But I would like to use this email and ask the struts development team about compatibility template library and components library (http://www.lifl.fr/~dumoulin/components/). Components allow to define "instances" to reuse them with different parameter values. They have good examples how to use them for implementation. They do not have a "role" attribute yet. Both components and templates have a lot of common. Why not combine the best parts both of them and put under struts project before 1.0 release? There is no end to good ideas for improvements to Struts, and the components library is one of them. However, if we kept adding new functionality we'd never have a 1.0 release, and that's not good either. This is definitely high on my personal priority list to look at for 1.1. Me too. As soon as I get my book out the door, I'll take a look at adding components to Struts. david (the Struts templates guy)
Re: Template tags?
Andrew Boyko wrote: during this process. First off, the web pages we will be creating will have a common navigation bar used across the whole web site. It would be great if we can create one HTML file called navigation.jsp which all pages use. If that's the only common element on the pages, you can do that using the JSP include tags, pulling in the common nav bar within each content page. True, but templates are so much cooler. ;-) The template tags (as we've been using them, at least) support a somewhat different model: your content pages push their specific content into common templates, which place the content into regions of the template. This allows you to have standard headers, footers, or any other common content and layout without the content pages needing to know or care what the standard layout is; it also allows you to redesign the template, potentially completely re-ordering the content presentation, without changing the content pages at all. Another benefit is that templates encourage you to divide your JSP pages into reusable components, although the same could be said of jsp:include. We've introduced the template tags to both java coders and HTML authors, and all found it easy to understand and like, and quite powerful. Amen. It seems that the struts template taglibs might be the solution, unfortunately the 0.5 version of struts we downloaded does not contain these taglibs. In my experience, cvs or nightly builds have been solid for a long while, and have been quite safe for development, not only for the template tags, but for the entire library. Templates are in Struts to stay. david
Wanted: Translator For JSP Book
I'm looking for somebody that can translate some English phrases into a CJK (Chinese-Japanese-Korean) language. This is for my Advanced JSP book; please reply to this email for details. david (Sorry for this off-topic message to struts-user)
Re: Proposal: RetroFit Struts with the Delegation Event Model
"Craig R. McClanahan" wrote:
* As fleshed out, the only events reported with this model so far
are before and after an Action's perform() method is called.
The abstract talks about building listeners for all "interesting"
events. If we're going to do a listeners model, I think we should
extend it to basically all of the processXxx methods, not just
processPerform().
Yes.
* If we go with generalized events, putting the firing logic inside
Action seems wrong -- general purpose support classes, or
public methods inside ActionServlet, seem more appropriate.
Agreed. I vote for a support class.
* Given that there will be many more events, we've got some
representation choices:
* Single ActionEvent class, or subclasses for various types
of events that have different properties (some events care
about the current ActionMapping and some don't).
I envision an event hierarchy.
* SIngle registrations of ActionListeners that receive all types of
events, or separate registrations for separate event families?
The latter would be more type-safe, and is probably preferred.
* I also have a couple of nit-picky type thoughts:
* Event type codes inside the ActionEvent seem redundant,
given that the type is implicitly defined by which listener
method you call.
True, but that assumes that the handler will never pass the event
to other methods that need to distinguish the event type -- the
information's not available to those methods.
* An ActionEvent, or the ActionListener that receives it,
should have knowledge of the ActionServlet
it is associated with, to provide access to underlying resources
provided by the servlet. (The whole event listener model is
intimately tied to Struts anyway, so this does not seem onerous).
Agreed.
* We need to use collection classes (with an implementation I'm
currently working on) that do not require lots of synchronization locks
or new object creations when processing event notifications, since
they happen on every request.
Ok.
david
Thoughts?
Craig
David Geary wrote:
ABSTRACT
It's often convenient, and sometimes necessary, to handle Struts events,
such as when an action has its locale set, or when the action servlet
processes an action's form. This document proposes retrofitting Struts
with the delegation event model. That model, which is used by the AWT
and
Swing, makes event handling simple, flexible, and scalable.
CREDITS
Delegation and Event Model for Struts? -- posted to struts-dev by
Robert Leland
INTRODUCTION
Currently, you can use inheritance to handle Struts events like those
described above. Typically, that means extending ActionServlet and
overriding a protected method, such as
ActionServlet.processActionPerform.
Inheritance-based event handling is inflexible and does not scale well
because event sources and listeners are tightly coupled at compile time.
This was evident to AWT engineers, who replaced the AWT's original
inheritance-based event model with the delegation event model.
The delegation event model, which has its roots in java.util, implements
the Observer design pattern to loosely couple event sources and event
listeners at runtime. That loose coupling makes it easy to associate
disparate types of objects, so that event listeners can easily react to
changes in event sources.
STRUTS AND THE DELEGATION EVENT MODEL
So what does it mean to retrofit Struts with the delegation event model?
It means that Struts will fire events when it performs certain
functions. You can register with Struts as an event listener, and
handle events as you see fit.
This proposal advocates firing events for all interesting Struts
functions; for example, the action servlet should fire a robust set of
events for processing actions and forms, performing mappings, etc.
Implementing support for those events follows the same
design pattern discussed in this proposal for implementing action
events.
This proposal illustrates how to modify Struts to fire events just
before, and immediately after, a Struts action has its perform method
invoked. Those events are hereafter known as action events.
IMPLEMENTING ACTION EVENTS AND ACTION LISTENERS
Getting Struts to fire action events is easy. First, we define a
listener interface and an event class:
org/struts/apache/event/action/ActionListener.java
org/struts/apache/event/action/ActionEvent.java
Here's the listing for ActionListener:
public interface ActionListener {
public void beforeActionPerform(ActionEvent event)
throws ServletException;
public void afterActionPerform(ActionEvent event)
throws ServletException;
}
Ac
Re: Proposal: RetroFit Struts with the Delegation Event Model
These are excellent questions, which I've answered below. Some of you have suggested the Barracuda (formerly Rocks) event model, which I'm looking into. You can read more about it at http://xmlc.enhydra.org/EventHandler/. Ted Husted wrote: Could the model be extended to optionally log events as they are fired, for debugging? It could, but you could implement a listener that logged events without extending the event model. Could the listeners be loaded via a configuraton file, like Struts actions? They could, and in most cases, they probably should. Could a ACTION_PERFORM be added to completely supercede the current control flow? Augment, yes. Supercede, no. Basically, the way this works is that Struts, meaning, for the moment, ActionServlet, fires events when it does something interesting. I used the Action.perform method for something interesting -- the action servlet fires events to actions just before, and immediately after the servlet calls Action.perform for every action. Those actions fire events to register listeners. You can think of Struts as a garden hose. The water running through the hose represents Struts events, such as actions being told to perform. I want to poke holes in that hose, so that developers can siphon those events. In the Form Resubmission example: Are the "sensitive" forms essential those that should only be submitted once per session (if at all)? No. Sensitive forms are forms with sensitive actions. In the example, the form in Figure 2 is a sensitive form because it's action is new-account-action. That action is sensitive to form resubmissions. Every sensitive action must be submitted by a sensitive form for the form resubmission example to work. Could this handle the common occurence of a payment form being submitted more than once, resulting in multiple payments? That's exactly what the form resubmission example does, other than providing a simple example of how you'd use the proposed delegation event model. david
Proposal: Tokens and Events Guard Against Form Resubmission
ABSTRACT
It's easy for Web application users to inadvertently resubmit forms
with bookmarks or the reload and back buttons. Because of this potential
for mischief, web applications must guard against resubmission of sensitive
forms. This document proposes using the delegation event model and tokens
to restrict access to sensitive pages.
Note: This proposal depends on action events as proposed in 'Proposal:
Retrofit Struts with the Delegation Event Model'.
CREDITS
'Command Token Implementation', posted to struts-dev by
Robert Leland
Struts Web Application Safety' on struts-dev, by Craig
McClanahan
'What about This Model?', posted to struts-user by Dan
Cancro
Web Development with JavaServer Pages, by Kolb and Fields,
p 270
INTRODUCTION
Web browsers were designed for browsing the Web, not for applications.
Some browser features, such as the back button, reload button, and bookmarks,
are difficult for web applications to deal with because they disrupt the
normal flow of an application. This proposal shows how to trap those browser
features in Struts using the delegation event model and tokens.
THE PROBLEM
Consider the following sequence of actions, as Timothy creates a new
account. First, Timothy tries to login, but since he does not have an account,
he's forwarded to the Login Failed page:
Figure 1. The Login Failed Page
Timothy clicks on the open new account link and is forwarded to this
page:
Figure 2. The Open New Account Page
Timothy fills in the form shown in Figure 2, clicks the create
account button, and is forwarded to the login page:
Figure 3. The Login Page
At this point, Timothy's account has been created and he can login,
but what if he reloads the page instead? Or what if he hits the back button,
and then clicks on the create account button without changing the form's
data? In both cases, a duplicate request will be sent to the new-account-action.
That action might detect the duplicate, but it's a lot to ask all actions
to test for duplicate submissions. Let's see how Struts can trap such illicit
access at a higher level.
TRAPPING ILLICIT ACCESS WITH STRUTS
WHAT IT DOES
Guard against sensitive form resubmission. If a sensitive form is resubmitted,
Struts throws an exception.
HOW IT'S IMPLEMENTED
Trapping illicit access is implemented in this proposal with tokens,
as described by Fields and Kolb (see credits). Here's how it works:
From the discussion above, it's apparent that some actions, such as
new-account-action.do, are sensitive to access by the back button, the
reload button, or bookmarks. In addition to sensitive actions, we will
also speak of sensitive forms, which are forms that forward to sensitive
actions; for example, the form shown in Figure 2 is a sensitive form.
When Struts performs an action with a sensitive form, the following
sequence of events takes place:
1. The action's perform method is invoked.
2. A token (a unique string) is stored in the session, and a copy of
that token is stored in request scope.
3. When the sensitive form is submitted, the token in request scope
stows away in the form as a hidden form variable.*
Before the corresponding sensitive action is performed by Struts:
1. The token, stored as a hidden form parameter, is compared to the
token in the session.
2. Iff the tokens match, the sensitive action is performed; otherwise,
an exception is thrown.
* The original token stored in request scope in step #2 is lost when
the sensitive form is submitted, because that submission results in a new
request. That's why the token is stored in a hidden form parameter.
HOW YOU USE IT
Protecting pages with sensitive actions is a three-step process:
1. Specify sensitive='true' in struts-config.xml for sensitive actions;
for example, for the new-account-action:
action path='/new-account-action' ... sensitive='true'
...> ... /action>
2. Specify hasSensitiveForms='true' in struts-config.xml for actions
that have sensitive forms; for example, for the query-account-action:
action path='/query-account-action' ... hasSensitiveForms='true'
...> ... /action>
3. Add a hidden field to each sensitive form. That field's value is
obtained from the "token" request attribute, like this:
%@ taglib uri='/WEB-INF/struts-bean.tld' prefix='bean'
%>
...
bean:token/>
Or, alternatively:
input type='hidden' value='%= request.getAttribute("token")
%>'/>
THE CODE
Two new classes--Token and SensitiveActionListener--and a custom tag,
bean:token>, are added to Struts and minor modifications are made to
Action.java and ActionServlet.java. The Token class, which maintains a
unique, ecrypted string, is listed below:
public class Token {
private String token;
public Token(HttpServletRequest req) throws ServletException
{
HttpSession session = req.getSession(true);
long systime = System.currentTimeMillis();
byte[] time = new Long(systime).toString().getBytes();
byte[] id = session.getId().getBytes();
try {
MessageDigest md5
= MessageDigest.getInstance("MD5");
md5.update(id);
Proposal: RetroFit Struts with the Delegation Event Model
ABSTRACT
It's often convenient, and sometimes necessary, to handle Struts events,
such as when an action has its locale set, or when the action servlet
processes an action's form. This document proposes retrofitting Struts
with the delegation event model. That model, which is used by the AWT
and
Swing, makes event handling simple, flexible, and scalable.
CREDITS
Delegation and Event Model for Struts? -- posted to struts-dev by
Robert Leland
INTRODUCTION
Currently, you can use inheritance to handle Struts events like those
described above. Typically, that means extending ActionServlet and
overriding a protected method, such as
ActionServlet.processActionPerform.
Inheritance-based event handling is inflexible and does not scale well
because event sources and listeners are tightly coupled at compile time.
This was evident to AWT engineers, who replaced the AWT's original
inheritance-based event model with the delegation event model.
The delegation event model, which has its roots in java.util, implements
the Observer design pattern to loosely couple event sources and event
listeners at runtime. That loose coupling makes it easy to associate
disparate types of objects, so that event listeners can easily react to
changes in event sources.
STRUTS AND THE DELEGATION EVENT MODEL
So what does it mean to retrofit Struts with the delegation event model?
It means that Struts will fire events when it performs certain
functions. You can register with Struts as an event listener, and
handle events as you see fit.
This proposal advocates firing events for all interesting Struts
functions; for example, the action servlet should fire a robust set of
events for processing actions and forms, performing mappings, etc.
Implementing support for those events follows the same
design pattern discussed in this proposal for implementing action
events.
This proposal illustrates how to modify Struts to fire events just
before, and immediately after, a Struts action has its perform method
invoked. Those events are hereafter known as action events.
IMPLEMENTING ACTION EVENTS AND ACTION LISTENERS
Getting Struts to fire action events is easy. First, we define a
listener interface and an event class:
org/struts/apache/event/action/ActionListener.java
org/struts/apache/event/action/ActionEvent.java
Here's the listing for ActionListener:
public interface ActionListener {
public void beforeActionPerform(ActionEvent event)
throws ServletException;
public void afterActionPerform(ActionEvent event)
throws ServletException;
}
ActionListener methods are passed instances of ActionEvent. Here's the
listing for that class:
public class ActionEvent extends java.util.EventObject {
public static final int BEFORE_ACTION_PERFORM=0,
AFTER_ACTION_PERFORM=1;
private int eventType;
private HttpServletRequest request;
private HttpServletResponse response;
public ActionEvent(Action action, int eventType,
HttpServletRequest request,
HttpServletResponse response) {
super(action); // specifies action as the event source
this.eventType = eventType;
this.request = request;
this.response = response;
}
public int getEventType() { return eventType; }
public HttpServletRequest getRequest() { return request; }
public HttpServletResponse getResponse() { return response; }
}
Through action events, action listeners have access to:
event type (BEFORE_ACTION_PERFORM, AFTER_ACTION_PERFORM)
action
request
response
HANDLING ACTION EVENTS
Here's how you use action events and listeners:
// first, implement a listener that handles action events
public class MyListener implements
org.apache.struts.event.ActionListener {
public void beforeActionPerform(ActionEvent event) {
// handle event
}
public void afterActionPerform(ActionEvent event) {
// handle event
}
}
// Then register your listener with an action:
someAction.addActionListener(new MyListener());
Thereafter, MyListener.beforeActionPerform and
MyListener.afterActionPerform will be called before and after
someAction's perform method, respectively.
Let's see what changes need to be made to Struts to make this work.
STRUTS MODIFICATIONS FOR SUPPORTING ACTION EVENTS
Only two Struts classes need to be modified to support firing action
events: Action and ActionServlet. Methods are added to the Action class
for registering action listeners and firing events:
// the following is added to org.apache.struts.action.Action:
import java.util.Enumeration;
import java.util.Vector;
import org.apache.struts.event.action.ActionEvent;
import org.apache.struts.event.action.ActionListener;
public class
Re: Templating Mechanism
I just committed changes to the template:put tag and the template tld. The tag works exactly like it did before, but now you can put direct content in the body of the put tag. If the put tag has body content: 1. You can't have a content attribute. (the tag body is the content) 2. You can't specify direct='false'. (tag body content is printed directly) The tag will throw an exception if either of those conditions are violated. david "Holloway, Kevin (DEH)" wrote: Hi, For a trial, we modified the template code so that a template:put tag with NO "content" attribute took its content from the tag body. A template:put with a "content" attribute took its content by including the file named by the content attribute. This did away with the "direct" attribute entirely. The only small issue was what if you had both content attribute and tag body. An exception could be thrown. We just ignore the body, making it clear in the documentation that this is what happens. We can send our code if that would help. Kevin Holloway Applications Architect Department for Environment and Heritage Government of South Australia -Original Message- From: Tan Siow Boon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 28, 2000 11:59 AM To: [EMAIL PROTECTED] Subject: Re: Templating Mechanism Hi, We found the template:ExtPut tag extension provided by Oleg V Alexeev very useful. Is there a plan to incorporate it into Struts 1.0 ? Regards, SiowBoon Oleg V Alexeev wrote: Hello Andrew, Some time ago I write tag to extend template mechanism in this way. Use it if you find it useful. This tag can be used like template:put tag except one feature - if you omit content property in it, then body of this tag will be treated as content. For example - template:extput name="body" Some content /template:extput Sourse you can find in attachment. This class - whole mirror of PutTag except some strings of code. Strings to add to the struts-template.tld tag nameextput/name tagclassorg.apache.struts.taglib.template.ExtPutTag/tagclass bodycontentJSP/bodycontent attribute namename/name requiredtrue/required rtexprvaluetrue/rtexprvalue /attribute attribute namecontent/name requiredfalse/required rtexprvaluetrue/rtexprvalue /attribute attribute namedirect/name requiredfalse/required rtexprvaluetrue/rtexprvalue /attribute /tag Monday, November 13, 2000, 7:45:55 PM, you wrote: The template mechanism in the article is nearly identical to the one in Struts. See org.apache.struts.taglib.template. AB I've been looking at the templating code, and AB have what I hope is a simple question. AB When using direct="true" in the template:put tag, AB to place literal text into the template, the text must AB necessarily be very limited because it's contained in AB the value of the content attribute. What I'd like to be AB able to do is something like: AB !-- the contents of a specific page -- AB template:insert template='/pagetemplate.jsp' AB template:put name="navigation" AB... page-specific navigation here AB /template:put AB template:put name="pagebody" AB... page body here... AB /template:put AB /template:insert AB which seems similar to your examples, except that the AB contents of the navigation and pagebody sections are AB stated in line, instead of loaded from external files, AB which I'd rather not do because of how many tiny AB little documents that would end up creating. AB Is this feasible? If the tag lib doesn't already AB support this function (and I believe it doesn't), AB is it possible to implement, and is it contrary to AB the intent? I'm not comfortable enough with AB taglib implementation to know if doing it this way AB would affect the evaluation of the page body in AB some undesirable way. AB Andy Boyko [EMAIL PROTECTED] -- Best regards, Oleg mailto:[EMAIL PROTECTED] Name: ExtPutTag.java ExtPutTag.javaType: application/x-unknown-content-type-java_auto_file Encoding: base64
Java Report Struts Article (was Re: Article on JavaWorld)
Ted Husted wrote: Anyone have other struts article or powered by references? The November issue of Java Report has an article on Struts that focuses on Struts MVC. The article's code is a little out of date, due to all of the changes that have occurred since the article was written. david
Re: design question
Jim Richards wrote:
As I understand it, is the basic design of struts generally to avoid
any direct java code in the .jsp files, and do everything through tags?
Tags and beans, yes.
And although we can so things within % % tags, it is not
preferred?
That's the conventional wisdom; however, IMHO it's sometimes
permissible to use scriplets. Consider this JSP page:
%
java.util.Enumeration e = request.getParameterNames();
boolean hasParams = false;
while(e.hasMoreElements()) {
String name = (String)e.nextElement();
String[] values = request.getParameterValues(name);
hasParams = true;
for(int i=0; i values.length; ++i) {
String next = values[i];
if(i == 0) { %
b%= name %:/b %= next %
% }
else { %
, %= next %
% }
} %
% }
if(!hasParams) { %
iNo parameters with this request/i
% } %
The JSP page listed above prints request parameters, which is useful for
debugging. I refer to JSP pages that are mostly scriptlets with a small
amount of HTML sprinkled throughout as JSP components, for lack of a better
term. In such cases, I believe scriptlets are just fine.
Of course, the functionality in the JSP page listed above could be
implemented as a custom tag. Whether you implement JSP pages or custom tags
is largely a matter of taste. Custom tags are a little more difficult to
develop, but they are easier for page authors to use. JSP components are
easier to develop, but they are a little more difficult for page authors to
use because they must be included.
Just wondering before I embark on my project, if it's worth including the
design of any extra tags, or just doing the things I want in % % ...
The bottom line is twofold: reuse and division of labor. You can't reuse
scriptlets buried in a JSP page, but you can reuse custom tags or JSP
components. If you're on a large project with software developers and page
authors, ideally you'd like the page authors to use tags implemented by
developers. This helps maintain a division of labor where software developers
and page authors can work in parallel, with few dependencies.
david
Re: *.jsp back door issue
Joel Schneider wrote: Description of Problem: A typical Struts based web site might be configured to have requests matching the pattern"*.do" sent to the ActionServlet. After a request is handled by its Action class, processing is typically forwarded to a .jsp page. However, it's also possible for users to directly request a .jsp page. When this happens, the JSP container (in my case, Orion) will process the .jsp page without any involvement by the ActionServlet. Some .jsp pages may yield unexpected results when called in this manner. Put those JSP pages in a directory under WEB-INF; for example, WEB-INF/jsp. Files under the WEB-INF directory cannot be directly accessed. david
Re: Templating Mechanism
The template mechanism in the article is nearly identical to the one in Struts. See org.apache.struts.taglib.template. david [EMAIL PROTECTED] wrote: Take a look at this Sept Javaworld article. It explains how to use a JSP template mechanism with three custom tags. http://www.javaworld.com/javaworld/jw-09-2000/jw-0915-jspweb.html Matt "Vincent Harcq" [EMAIL PROTECTED] on 11/12/2000 10:46:39 PM Please respond to [EMAIL PROTECTED]; Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Matas Veitas/AMS/AMSINC) Subject: Templating Mechanism After reading the User Guide, I am not sure if Struts does have a Templating Mechanism or not. By that I mean one (or 2 or 3) that defines the basic structure of the site in 3 (for example) parts : a header, the left panel and a body. This template will always be the jsp:forward and have two jsp:include to include the two static (for example) header and left panes pages and one jsp:include that would get a parameter from the request to now which page to include. Something similar to the PetStore example. I like that because it push a lot of DIV or LAYER HTML code in only the template page. Is it possible ? _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
