Re: Using validate() and returning to original page dynamically
Hi Nic, Struts does not allow to do things like this declaratively, but you can do it manually. 1) you can obtain mapping name from the ActionMapping. This will solidify the mapping name where you want to return, in code. I am not sure that this is worse that to solidify it in struts-config.xml, but people say that struts-config.xml is more flexible in deploy time. Hardly. 2) You can set the params too, it is not a big deal. Do not edit existing ActionForward from findForward, instead create a new one and append query parameters. Referer is a great thing, but some browsers and firewalls can turn it off, so it is not reliable. On the other hand, are you sure that you want to design your actions like this? How about this: * createItem - creates new empty item; forwards (better yet, redirects) to editItem. * editItem - allows to set/change value for a new or for an existing item; * storeItem - persists modified item (inserts the one just created or updates already existing, called from editItem); But in this case, if you use redirection, you would need to patch the path to the action too, to include item ID. If interested, see more here: http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost2. It has a link to the source code, too. WBR, Michael Jouravlev. On 4/18/05, Nic Werner [EMAIL PROTECTED] wrote: Hi again, I'm calling the validate() method in my MappingDispatchAction to check errors on page. Which is fine, except that I want to return to the URL (Action w/params) that was called. I have two Actions, Edit and Add, which both refer to Attributes.jsp, and depending on the type param set, this page forwards to either Update or Insert, respectively. Therefore, setting 'input='Attributes.jsp' won't work as the bean isn't setup properly for the Edit Action. So, the flow is that I want '/Edit.do?Id=32' to check for errors, and if there is one, return to '/Edit.do?Id=32', not Attributes.jsp. It isn't enough to set the type (Edit/Add) in the session scope, I would need to set the params also, which seems like more complex handling/overhead. Is there a solution workaround to this? I've searched, and of course Rick has written some good articles on this, but I haven't seen the situation where it needs to return to a dynamic page *with* the params, aka the calling page. I suppose I could get the referer URI, but I don't think I could call mapping.getInput() that way. Thanks, - Nic. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.IllegalArgumentException calling an Action
Probably the problem is in your ActionForm. It seems that a submitted form field does not match with the corresponding ActionForm property (e.g. you submit a alphanumeric string while in the ActionForm the property is int). Hope it helps. Ciao Antonio Petrelli Rodolfo García Esteban/CYII wrote: Hi all, I'm developing with struts 1.2.4, I have an action with form as beans, not dynamic, field in which I introduce data are String, and I have another field without values. When I do commit, then programs doesn't touch my action I obtain befere the next error: javax.servlet.ServletException: BeanUtils.populate org.apache.struts.util.RequestUtils.populate(RequestUtils.java:497) org.apache.struts.action.RequestProcessor.processPopulate(RequestProcesso r.java:798) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:2 05) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) javax.servlet.http.HttpServlet.service(HttpServlet.java:709) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) Root Cause: java.lang.IllegalArgumentException: argument type mismatch sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI mpl.java:25) java.lang.reflect.Method.invoke(Method.java:324) org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtil s.java:1789) org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtil s.java:1684) org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java :1713) org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019) org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808) org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495) org.apache.struts.action.RequestProcessor.processPopulate(RequestProcesso r.java:798) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:2 05) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) javax.servlet.http.HttpServlet.service(HttpServlet.java:709) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) Could somebody help me? Thanks Rodolfo ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On 4/18/05, Martin Cooper [EMAIL PROTECTED] wrote: To get beyond doing the grunt work yourself for Ajax, I recommend taking a look at this: http://dojotoolkit.org/intro_to_dojo_io.html and downloading the dojo.io package from their site. Personally, I'm not convinced that we need anything new in Struts to make using Ajax easier. I'm building products today that make extensive use of the two technologies together, and haven't found a need to enhance Struts to do it. However, if we do add any Ajax (or Ajax-like) support to Struts, I want to be able to plug in my plumbing of choice (which would be Dojo right now) to get the most robust communication scheme available. -- Martin Cooper This is exactly the area I've been having trouble with this proposal as well ... tell me again why you can't use Ajax techniques with the standard Struts HTML tags? If you can do it with handwritten HTML pages (which you certainly can), you can also do it with existing Struts HTML tags (or the standard JSF components, for that matter) that offer attributes like onchange and onclick to plug in your calls to JavaScript methods that do the actual background calls, and then update the client side DOM of your page. It seems to me that a framework can provide value add in primarily the following areas: * Provide a client side JavaScript library that does the grunt work of making the back-end XmlHttpRequest call, and updating the corresponding portion of your DOM. Martin likes DOJO for this; there are also a bunch of other libraries that do the same sort of thing that should be leveraged, instead of inventing something new. * Provide a server side framework that makes it easy to map a particular XHR invocation to the corresponding business logic, and (for extra credit) maps the response data to a generic data format so you don't have to write specific formatting logic for every single response type. I sort of like what JSON provides as a transport protocol, but there's room for value add here on the server side, with a generic data abstraction that maps into the appropriate transport formats. * Provide encapsulated functionality (JSP custom tags, JSF component tags, whatever) that totally hides the fact that Ajax techniques are used into the HTML and JavaScript markup that is automatically generated. If you make the page developer have to do a *lot* more (i.e. a bunch of nested tags) on every Ajax-sensitive component, that doesn't seem to make application development easier ... it only makes it more tedious. Use case to consider -- as an application developer, I want to use a progress bar widget that periodically polls the server for the progress of a long running function, and then updates the client side visual representation. If I have to do more than add a single attribute (some way to map to the server side function that returns the completion percentage to be displayed), plus an optional parameter that says how often to check, over what it takes to specify a static image with an html:img tag (for example), then I'm likely to say thanks but no thanks to your version of that widget. If, on the other hand, you let me say: html:progressBar progressURL=/filecopy.do/ or html:progressBar progressURL=/filecopy.do interval=3/ then I'm fat, dumb, and happy. Why should *i* (the application developer) care that you're using XmlHttpRequest behind the scenes? Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: content management tool
Slide jakarta project does provide a struts based taglib to access content management :/ Le Lundi 18 Avril 2005 23:52, sudip shrestha a écrit : Just curious if there are any struts based content managment tools out there! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Delbecq Royal Meteorological Institute of Belgium - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.IllegalArgumentException calling an Action
The problem must be other, because I test submit with numbers, alphanumeric, empty, and the result is ever the same. I will debug struts to obtain more information, thanks Antonio. Rodolfo [EMAIL PROTECTED] 19/04/2005 08:36 Por favor, responda a Struts Users Mailing List Para: user@struts.apache.org cc: (cco: Rodolfo García Esteban/CYII) Asunto: Re: java.lang.IllegalArgumentException calling an Action Probably the problem is in your ActionForm. It seems that a submitted form field does not match with the corresponding ActionForm property (e.g. you submit a alphanumeric string while in the ActionForm the property is int). Hope it helps. Ciao Antonio Petrelli Rodolfo García Esteban/CYII wrote: Hi all, I'm developing with struts 1.2.4, I have an action with form as beans, not dynamic, field in which I introduce data are String, and I have another field without values. When I do commit, then programs doesn't touch my action I obtain befere the next error: javax.servlet.ServletException: BeanUtils.populate org.apache.struts.util.RequestUtils.populate(RequestUtils.java:497) org.apache.struts.action.RequestProcessor.processPopulate(RequestProcesso r.java:798) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:2 05) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) javax.servlet.http.HttpServlet.service(HttpServlet.java:709) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) Root Cause: java.lang.IllegalArgumentException: argument type mismatch sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI mpl.java:25) java.lang.reflect.Method.invoke(Method.java:324) org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtil s.java:1789) org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtil s.java:1684) org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java :1713) org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019) org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808) org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495) org.apache.struts.action.RequestProcessor.processPopulate(RequestProcesso r.java:798) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:2 05) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) javax.servlet.http.HttpServlet.service(HttpServlet.java:709) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) Could somebody help me? Thanks Rodolfo ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: content management tool
I'm developing an open source CMS.. it's in the very alpha stage, still nothing released to the public.. www.jclubhouse.org I'll post more info when something is released.. Simone sudip shrestha wrote: Just curious if there are any struts based content managment tools out there! - 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: java.lang.IllegalArgumentException calling an Action
Hi, I have changed the server from Tomcat 5.0.28 to Tomcat 4.1.31, and I come back to struts-bean and struts-logic tags, and now the app works well. Its very strange. do Nobody Know the diference Tomcat 5.0 and 4.1 fills the ActionForms, I think here is the difference. Thanks Rodolfo ___ Rodolfo García Esteban/CYII [EMAIL PROTECTED] 19/04/2005 09:26 Por favor, responda a Struts Users Mailing List Para: Struts Users Mailing List user@struts.apache.org cc: (cco: Rodolfo García Esteban/CYII) Asunto: Re: java.lang.IllegalArgumentException calling an Action The problem must be other, because I test submit with numbers, alphanumeric, empty, and the result is ever the same. I will debug struts to obtain more information, thanks Antonio. Rodolfo [EMAIL PROTECTED] 19/04/2005 08:36 Por favor, responda a Struts Users Mailing List Para: user@struts.apache.org cc: (cco: Rodolfo García Esteban/CYII) Asunto: Re: java.lang.IllegalArgumentException calling an Action Probably the problem is in your ActionForm. It seems that a submitted form field does not match with the corresponding ActionForm property (e.g. you submit a alphanumeric string while in the ActionForm the property is int). Hope it helps. Ciao Antonio Petrelli Rodolfo García Esteban/CYII wrote: Hi all, I'm developing with struts 1.2.4, I have an action with form as beans, not dynamic, field in which I introduce data are String, and I have another field without values. When I do commit, then programs doesn't touch my action I obtain befere the next error: javax.servlet.ServletException: BeanUtils.populate org.apache.struts.util.RequestUtils.populate(RequestUtils.java:497) org.apache.struts.action.RequestProcessor.processPopulate(RequestProcesso r.java:798) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:2 05) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) javax.servlet.http.HttpServlet.service(HttpServlet.java:709) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) Root Cause: java.lang.IllegalArgumentException: argument type mismatch sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java :39) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI mpl.java:25) java.lang.reflect.Method.invoke(Method.java:324) org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtil s.java:1789) org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtil s.java:1684) org.apache.commons.beanutils.PropertyUtils.setProperty(PropertyUtils.java :1713) org.apache.commons.beanutils.BeanUtils.setProperty(BeanUtils.java:1019) org.apache.commons.beanutils.BeanUtils.populate(BeanUtils.java:808) org.apache.struts.util.RequestUtils.populate(RequestUtils.java:495) org.apache.struts.action.RequestProcessor.processPopulate(RequestProcesso r.java:798) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:2 05) org.apache.struts.action.ActionServlet.process(ActionServlet.java:1164) org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:415) javax.servlet.http.HttpServlet.service(HttpServlet.java:709) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) Could somebody help me? Thanks Rodolfo ___ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
-Original Message- Users that turn off JS are akin, in my mind, to automobile drivers who decide they would rather play Fred Flintstone, cut holes in the floorboards and not bother starting the engine. Oh, you'll get around, but your missing out! While I am certainly not trying to say there aren't very legitimate concerns with using JS, like most things they are overcome with knowledge and ability. I mean, no one complains because Windows ships with fdisk and format, they are at least as dangerous potentially! -Original Message- Well,... If we look behind the problems that could arise with JavaScript... I am really convinced that JS in a webapp is a really BAD idea. Think about Cross-Scripting. It is not that your web-applicaiton is the culprit, but someoneelse's bad-behaving Javascript that does the damage. I am just waiting to here about the first case where a developer has to take the responsibilities for real damage to a use, because he required JS for a web-app and in this way forcing the user to switch on JS-support in his browser, rendering him susceptible to damage by another websites ill-behaving JS-code... I also think that a well-designed web-UI does not need JS at all... regards Alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote: On Mon, April 18, 2005 11:12 am, Emmanouil Batsis said: I haven't really studied the samples yet, but it would seem more semantically correct to me if the html:form was used to make this work. I'll try to come up with more concrete suggestions. I thought of that too, but what changed my mind is the question of how do you handle it if you want to have a number of different elements doing different things. For instance, if you have three select elements and you want one to populate a textarea with text retrieved from the server when changed, another to pop up an alert with a message from the server when changed, and the other to go to the URL selected with a query string appended on that is generated by the server when changed... If the functionality was tied to the form, how would you allow for that? Good point, but my perspective is focused on basic 80/20 functionality and fallback behavior, plus proper semantics (the last one just as a practice that usually pays back). To clarify, i support implementing this in (or on top of!) the existing html taglib and start specifically from the html:form simply because it's the only way to include proper fallback behaviour for UAs unable to handle the client side of things by making a normal form submission. For this to work however, the action has to know whether it has to send back the complete document or the document fragment. I'm looking for a way to meaningfully make all this easier. Also, i don't think the client side of things can be left as a developer's choice for the same reason the validator scripting is not a developer's choice; there is no way to manage the complexity of that in a usefull way. That's why i'm offering the sarissa code to be put under the Apache license; about 18 versions have been published since early 2003 (long before the ajax hype), it has an active and healthy user/developer base, is well documented and is used by other open source projects like OSCOM's Kupu editor. Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
requiredif
Hi, I'm stuck with Struts 1.1b2 and I need to do some conditional validation. AFAIK, the way to do this for this version is using the requiredif validator. The problem is, I cannot find any reference information on how to add this validator to the validator-rules.xml configuration file. Please advise on how to do this and if there's a better way to do this with this old version. For example, is it possible to configure the old Struts/Validator versions to use validwhen? Any help is appreciated. Tarek Nabil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using validate() and returning to original page dynamically
At 11:06 PM -0700 4/18/05, Michael J. wrote: 2) You can set the params too, it is not a big deal. Do not edit existing ActionForward from findForward, instead create a new one and append query parameters. Note that about two months ago, a class called ActionRedirect was added to clean up this particular use case (adding parameters to a redirecting ActionConfig.) http://cvs.apache.org/viewcvs.cgi/struts/core/trunk/src/share/org/apache/struts/action/ActionRedirect.java?root=Apache-SVNrev=153901view=markup No Struts release has been made since this was added, but you should know it's there and if you're using a nightly build, you should use it. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Narrow minds are weapons made for mass destruction -The Ex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: requiredif
!-- requiredif -- validator name=requiredif classname=org.apache.struts.validator.FieldChecks method=validateRequiredIf methodParams=java.lang.Object, org.apache.commons.validator.ValidatorAction, org.apache.commons.validator.Field, org.apache.struts.action.ActionErrors, org.apache.commons.validator.Validator, javax.servlet.http.HttpServletRequest msg=errors.required/ Erik tarek.nabil wrote: Hi, I'm stuck with Struts 1.1b2 and I need to do some conditional validation. AFAIK, the way to do this for this version is using the requiredif validator. The problem is, I cannot find any reference information on how to add this validator to the validator-rules.xml configuration file. Please advise on how to do this and if there's a better way to do this with this old version. For example, is it possible to configure the old Struts/Validator versions to use validwhen? Any help is appreciated. Tarek Nabil - 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: AJAX: Whoa, Nellie!
Jesse Alexander (KBSA 21) a écrit : Well,... If we look behind the problems that could arise with JavaScript... I am really convinced that JS in a webapp is a really BAD idea. Think about Cross-Scripting. It is not that your web-applicaiton is the culprit, but someoneelse's bad-behaving Javascript that does the damage. I am just waiting to here about the first case where a developer has to take the responsibilities for real damage to a use, because he required JS for a web-app and in this way forcing the user to switch on JS-support in his browser, rendering him susceptible to damage by another websites ill-behaving JS-code... I also think that a well-designed web-UI does not need JS at all... Mmmh. Well, Firefox lets users choose which site have the right to popup() or not. Let's do the same for JavaScript, and the problem disappears (of course, the other browsers should do the same). -- Stéphane Zuckerman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Displaying data :: Best practise
What goes to the front (for viewing purposes)? For capturing data we use ActionForms! But how do you display data (from your model) nicely? Send Businesobjects, Businessobjects stuffed in Beans, ActionForm or something else to the view layer? Regards, Nils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Displaying data :: Best practise
What goes to the front (for viewing purposes)? For capturing data we use ActionForms! But how do you display data (from your model) nicely? Send Businesobjects, Businessobjects stuffed in Beans, ActionForm or something else to the view layer? Regards, Nils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Displaying data :: Best practise
Good Question! I think. When I started to use struts I made the same question, and I doubt a lot between use ActionForm or Beans, at least I decided to use ActionForms, because I can view the contents in the html-struts tags without doing anything, and I want to avoid to have much more classes. I hope this helps you, but I wait for others replies to contras points of view. Cheers! Rodolfo García Esteban Canal Isabel II División de Aplicaciones Técnicas C/ Santa Engracia, 125 Edificio 8 Tel. 91 545 10 00 - Ext. 2128 Fax. 91 545 14 41 ___ Nils Liebelt [EMAIL PROTECTED] 19/04/2005 14:39 Por favor, responda a Struts Users Mailing List Para: 'Struts Users Mailing List' user@struts.apache.org cc: (cco: Rodolfo García Esteban/CYII) Asunto: Displaying data :: Best practise What goes to the front (for viewing purposes)? For capturing data we use ActionForms! But how do you display data (from your model) nicely? Send Businesobjects, Businessobjects stuffed in Beans, ActionForm or something else to the view layer? Regards, Nils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Displaying data :: Best practise
Nils I tend to use ActionForms where I can, but I also have a set of wrappers for Collections that handle ordering of the columns within the collection, retrieve individual items by key etc. and adapters for single objects that enable the front-end to pull all the details out of the beans with simple getters. This make life easy and consistent for the JSP developers as it gives a consistent interface. I am more than willing to pop these up somewhere so you can have a look, if it helps. Christopher Marsh-Bourdon www.marsh-bourdon.com -Original Message- From: Nils Liebelt [mailto:[EMAIL PROTECTED] Sent: 19 April 2005 13:40 To: 'Struts Users Mailing List' Subject: Displaying data :: Best practise What goes to the front (for viewing purposes)? For capturing data we use ActionForms! But how do you display data (from your model) nicely? Send Businesobjects, Businessobjects stuffed in Beans, ActionForm or something else to the view layer? Regards, Nils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. 3167 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Editing jsp pages
I wanted to know what is the best way to edit jsp pages that gives you a GUI interface versus using a text editor. If I should post this question to a different group, sorry in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Displaying data :: Best practise
Great Question, If I was to use an ActionForm to populate my presentation layer, how would I go about it. Would I use a struts tag, or this jstl I hear people going on about (I know one day I should rtfm). An example of displaying a value as text in my JSP from a form bean (myform) with property firstName would be greatly appreciated. -Original Message- From: Marsh-Bourdon, Christopher [mailto:[EMAIL PROTECTED] Sent: 19 April 2005 13:58 To: 'Struts Users Mailing List' Subject: RE: Displaying data :: Best practise Nils I tend to use ActionForms where I can, but I also have a set of wrappers for Collections that handle ordering of the columns within the collection, retrieve individual items by key etc. and adapters for single objects that enable the front-end to pull all the details out of the beans with simple getters. This make life easy and consistent for the JSP developers as it gives a consistent interface. I am more than willing to pop these up somewhere so you can have a look, if it helps. Christopher Marsh-Bourdon www.marsh-bourdon.com -Original Message- From: Nils Liebelt [mailto:[EMAIL PROTECTED] Sent: 19 April 2005 13:40 To: 'Struts Users Mailing List' Subject: Displaying data :: Best practise What goes to the front (for viewing purposes)? For capturing data we use ActionForms! But how do you display data (from your model) nicely? Send Businesobjects, Businessobjects stuffed in Beans, ActionForm or something else to the view layer? Regards, Nils - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. 3167 - 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: Editing jsp pages
Joe, this message pops up every once in a while. FCK Editor is popular http://www.fckeditor.net/demo/default.html However I wrote my own, don't groan ;), based on this because I wanted to work with the back end integration more. An editable div is essentially the best way to go. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 19 April 2005 14:00 To: Struts Users Mailing List Subject: Editing jsp pages I wanted to know what is the best way to edit jsp pages that gives you a GUI interface versus using a text editor. If I should post this question to a different group, sorry in advance. - 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]
Apostrophes in bean:write
Has anyone run into this, and if so do you have a work around?
I have a Struts bean:write tag inside a JavaScript onClick command like
so:
tdinput type=image src=images/EditIcon.gif alt=Add/Edit External
Note
onClick=showExtNoteModal('nested:write
property=pendingExtNote/nested:write',
'%= rowIndex.toString() %','editExternalNote')//td
The problem is the dastardly single quote embedded in the nested:write
property, for example (Chris's Test Note). It works fine as long as
there is no JavaScript, but with the JavaScript wrapping it you get
script errors. It seems struts is nice enough to replace the single
quote with the hex code equivalent of
tdinput type=image src=images/EditIcon.gif alt=Add/Edit Internal
Note
onClick=showIntNoteModal('Chris#39;s Other Test',
'0','editInternalNote')//td
I made a routine to add the escape character (\') if I detect the ('),
but struts is still nice enough to recognize this and replace it with
the hex code again, removing my escape character. I also tried to add
multiple slashes before the ' which gets past the JavaScript error but,
it shows up on the page with \\' I guess struts doesn't recognize the
\\' as a special character.
Thanks,
Scott Mulligan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Based on my experience porting the Struts tags to AJAX/SWF
(swf.dev.java.net), I would agree with Craig that the existing Struts
tags would be sufficient; however, tweaking the event handler attrs,
as in SWF, does provide some simplification. For example (in SWF), w/
o the tweak we would need ...onchanged=updateEvent('#userSelected',
'')... whereas with the tweak we
have ...onchanged=swf:userSelected...
Not necessary, but nice.
On another note, there are ways to use AJAX that degrade gracefully
to regular form submits and reloads when the AJAX preconditions are
not met or ill advised. The dominate AJAX view point at the moment is
service oriented: 1) something (even an interval or timeout hook)
happens in the browser, 2) a service call is made to the server, and
3) the DOM is possibly modified. There is another way to view AJAX
that I believe fits better with existing frameworks like Struts,
WebWork, and Spring. Coming from a windowing system view point, AJAX
can look like the means of refreshing dirty regions in the page: 1)
something happens, 2) the form is submitted, and 3) any modified
regions are rendered and sent back to the browser. You can do all the
same things as AJAX-the-service-mechanism plus 1) to the server side
it looks just like the same ole form submits, 2) as a result of (1)
the page can degrade gracefully to submit/reload, and 3) the
application engineer rarely needs to get into JavaScript.
As evidence for my point, the SWF works this way very effectively
and is built upon the single primitive of an updateable region. I
have ported this primitive to Struts using a very small (8k) tag lib
with two trivial tags and no modifications to Struts itself (https://
swf.dev.java.net/docs/Struts.html.) Given this primitive, everything
else is possible once one has switched from viewing AJAX as a service
mechanism to a means of updating regions in a page. IMO, this
direction would be an interesting way to resolve the AJAX/Struts
debate in this thread.
Cheers!
On Apr 19, 2005, at 12:47 AM, Craig McClanahan wrote:
On 4/18/05, Martin Cooper [EMAIL PROTECTED] wrote:
To get beyond doing the grunt work yourself for Ajax, I recommend
taking a
look at this:
http://dojotoolkit.org/intro_to_dojo_io.html
and downloading the dojo.io package from their site.
Personally, I'm not convinced that we need anything new in Struts
to make
using Ajax easier. I'm building products today that make extensive
use of
the two technologies together, and haven't found a need to enhance
Struts to
do it. However, if we do add any Ajax (or Ajax-like) support to
Struts, I
want to be able to plug in my plumbing of choice (which would be
Dojo right
now) to get the most robust communication scheme available.
--
Martin Cooper
This is exactly the area I've been having trouble with this proposal
as well ... tell me again why you can't use Ajax techniques with the
standard Struts HTML tags? If you can do it with handwritten HTML
pages (which you certainly can), you can also do it with existing
Struts HTML tags (or the standard JSF components, for that matter)
that offer attributes like onchange and onclick to plug in your
calls to JavaScript methods that do the actual background calls, and
then update the client side DOM of your page.
It seems to me that a framework can provide value add in primarily the
following areas:
* Provide a client side JavaScript library that does the grunt work
of making the back-end XmlHttpRequest call, and updating the
corresponding portion of your DOM. Martin likes DOJO for this;
there are also a bunch of other libraries that do the same sort
of thing that should be leveraged, instead of inventing something
new.
* Provide a server side framework that makes it easy to map
a particular XHR invocation to the corresponding business logic,
and (for extra credit) maps the response data to a generic data
format so you don't have to write specific formatting logic for
every single response type. I sort of like what JSON provides as a
transport protocol, but there's room for value add here on the
server side, with a generic data abstraction that maps into
the appropriate transport formats.
* Provide encapsulated functionality (JSP custom tags, JSF component
tags, whatever) that totally hides the fact that Ajax techniques
are used
into the HTML and JavaScript markup that is automatically generated.
If you make the page developer have to do a *lot* more (i.e. a
bunch of
nested tags) on every Ajax-sensitive component, that doesn't seem to
make application development easier ... it only makes it more
tedious.
Use case to consider -- as an application developer, I want to use a
progress bar widget that periodically polls the server for the
progress of a long running function, and then updates the client side
visual representation. If I have to do more than add a single
attribute (some way to map to the
Re: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 2:47 am, Craig McClanahan said: This is exactly the area I've been having trouble with this proposal as well ... tell me again why you can't use Ajax techniques with the standard Struts HTML tags? No one, at least not me, has made that statement at any point. I frankly do not use the Struts tags most of the time, yet I do AJAX just fine. There is no debate on this point: there is no NEED for the Struts HTML tags to do AJAX. If you can do it with handwritten HTML pages (which you certainly can), you can also do it with existing Struts HTML tags (or the standard JSF components, for that matter) that offer attributes like onchange and onclick to plug in your calls to JavaScript methods that do the actual background calls, and then update the client side DOM of your page. Agreed. But then you have to do everything yourself. If 80% of the time people are doing the same kinds of things like replacing the content of a specific DOM elements' innerHTML, why not provide a standard approach to that? Further, we are constantly talking about the dichotomy of having a separate group of page developers and back-end developers. Why should a page developer need to know Javascript? Isn't that like saying they need to know Java on the server? You could of course make the argument that scripting is appropriately a part of a page developers' reportoire, and I don't think I would argue, but they already avoid a great deal of scripting by using various taglibs, so why shouldn't they want to avoid scripting to implement at least basic AJAX techniques? That is what is at the heart of what I did. It seems to me that a framework can provide value add in primarily the following areas: See, when we start talking about a framework we are starting to talk about something more grandiose than what I put together. That is in no way to say it isn't a good idea, just that it is different. * Provide a client side JavaScript library that does the grunt work of making the back-end XmlHttpRequest call, and updating the corresponding portion of your DOM. Martin likes DOJO for this; there are also a bunch of other libraries that do the same sort of thing that should be leveraged, instead of inventing something new. Not everyone likes throwing the kitchen sink into their projects to provide a relatively small amount of functionality. It is amazing to me that anyone would make the argument against something that is too simple! Why do we always have to develop the next big thing rather than something that will help 80% of the people 80% of the time? Why is the later a seemingly Bad Thing? * Provide a server side framework that makes it easy to map a particular XHR invocation to the corresponding business logic, and (for extra credit) maps the response data to a generic data format so you don't have to write specific formatting logic for every single response type. I sort of like what JSON provides as a transport protocol, but there's room for value add here on the server side, with a generic data abstraction that maps into the appropriate transport formats. I do actually like this idea, but again, the difference between this and what I put together is night and day... this is leading down a much more complex and expansive path. It's a path I would be excited to walk down, but it puts delivered results further away as opposed to what I did that could be completed in relatively short order and help people NOW. Also, what you are talking about, and what Martin has been talking about, while a good idea to be sure, doesn't really help people with existing apps. It is akin to my Struts Web Services project... I have never at any time promoted that as the be-all and end-all of Web Services. What I have said is that if you have an existing Strtus-based application and need to expose parts of it as Web Services, here's one quick and easy way to do it. Likewise, what I proposed is a quick and easy way to introduce AJAX functionality into an existing app with a minimum of fuss and muss. There is not a lot of code to write (none if I do it right) and it's not an all-or-nothing proposition, you don't have to use a whole new framework on the client and the server to make it work. The what you and Martin are talking about, I can't see how that would be the case. So, while the ideas may have a great deal of merit, they require a far greater change for developers and don't, I think, help anyone NOW. * Provide encapsulated functionality (JSP custom tags, JSF component tags, whatever) that totally hides the fact that Ajax techniques are used into the HTML and JavaScript markup that is automatically generated. If you make the page developer have to do a *lot* more (i.e. a bunch of nested tags) on every Ajax-sensitive component, that doesn't seem to make application development easier ... it only makes it more tedious. Granted. My proposal very much
[OT] how to reject non-HTTPS instead of redirect?
Sorry for the OT but I thought I'd try here since this should be simple and I don't subscribe to tomcat-user. Anyone know how to configure Tomcat (5.0) to simply reject a non-HTTPS request when the transport guarantee is CONFIDENTIAL, rather than to issue a redirect? I can't find anything on this in the documentation. I tried removing the redirectPort attribute from the Connector element, and it seemed to make no difference. The doc says this: |redirectPort| If this *Connector* is supporting non-SSL requests, and a request is received for which a matching |security-constraint| requires SSL transport, Catalina will automatically redirect the request to the port number specified here. How do I turn off this automatic redirect? I would rather issue an error response. Thanks, Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 12:53 am, Martin Cooper said: To get beyond doing the grunt work yourself for Ajax, I recommend taking a look at this: http://dojotoolkit.org/intro_to_dojo_io.html and downloading the dojo.io package from their site. It does look cool. However, in some ways what I provided is actually better... I have the concept of default return handlers (and default submission handlers) that would save the developer, in some percentage of situations at least, from writing ANY server-side code whatsoever. True enough, one could implement that concept with Dojo too, but then I'm just helping develop Dojo! Personally, I'm not convinced that we need anything new in Struts to make using Ajax easier. Easier for who? For you? You are a super-genius Martin :) It's a cakewalk for you. For me too frankly. *I* certainly don't need new tags because I don't even use the tags as they are now 95% of the time! Let's look at it this way... I don't consider the validation framework to be any great shakes. I mean, the client-side portion of it anyway. I don't need tags that can write validation logic for me. I suspect you don't need it either. Was it a bad idea then? Most certainly not! Same thing here... if we can provide to 80% of the people a capability that requires so very little extra work for them (a single config file and a single attribute on any tag involved) that will handle 80% of their needs, why in the world wouldn't we jump at the chance? I'm building products today that make extensive use of the two technologies together, and haven't found a need to enhance Struts to do it. You and I both :) However, if we do add any Ajax (or Ajax-like) support to Struts, I want to be able to plug in my plumbing of choice (which would be Dojo right now) to get the most robust communication scheme available. And that is a reasonable point I feel. But, then you get into a situation where you have to build something more complex in all probability to provide that degree of flexibility... I have to make sure it is generic enough to handle any plumbing you want to put in, and then what happens when some new plumbing comes down the pipe that doesn't quite fit? I would rather take the tact here is an available method to do this AJAX stuff, here are the limitations, and when you bump up against them you will have to use something else. I just don't see that as a bad thing because it helps some people now, as opposed to helping no one, or more precisely, leaving them out to entirely help themselves. P.S. - Take a look at my proposal again... If you really wanted to use Dojo, I believe you could with just one minor change: I would have to allow for calling custom functions when submitting to the server. This was on the slate anyway, and that means you could use your dojo.io.bind() stuff here). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 5:30 am, Jesse Alexander (KBSA 21) said: I also think that a well-designed web-UI does not need JS at all... Then what results is exactly what you say: a WEB UI. This was good enough five years ago, it isn't today. People expect, generally, more robust UIs delivered in a browser. They expect webapps that look, feel and work more like fat clients. This is all a virtual impossibility without some dergee of scripting. There are of course cases where this doesn't natter... sometimes the simplistic Google front page approach is perfect. But you'll pretty quickly run up against some serious roadblocks to developing anything other than classic web UIs without scripting. Your point is well-taken... scripting does indeed entail some level of danger... but so does driving a car, and we all do that without much thought :) (which is of course part of the problem with driving today, but I digress...) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apostrophes in bean:write
Mulligan, Scott H wrote the following on 4/19/2005 9:51 AM:
tdinput type=image src=images/EditIcon.gif alt=Add/Edit External
Note
onClick=showExtNoteModal('nested:write
property=pendingExtNote/nested:write',
'%= rowIndex.toString() %','editExternalNote')//td
The problem is the dastardly single quote embedded in the nested:write
property, for example (Chris's Test Note).
Have you tried:
onClick='showExtNoteModal(nested:write property='pendingExtNote'
filter='false'/,%= rowIndex.toString() %,editExternalNote)'//td
I'm not positive if changing the quotes around will work but it should,
although you might have the problem then if they have in the text.
Usually the html conversion is what I want. Depends what I need to do.
By the way you can replace the scriplet for %= rowIndex.toString() %
with a bean:write also. Not sure what you are using for your loop
though. Are you using logic:iterate or c:forEach ?
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Editing jsp pages
I think this is not what Joe was looking for... you provided the solution for the question: How can I edit an HTML text from a JSP? I think he was looking for a JSP editor, to make JSP pages... unfortunately I cannot help you... I use e text editor, but I'm starting to use Eclipse... anyway eclipes is in text mode for editing jsp Simone Mark Benussi wrote: Joe, this message pops up every once in a while. FCK Editor is popular http://www.fckeditor.net/demo/default.html However I wrote my own, don't groan ;), based on this because I wanted to work with the back end integration more. An editable div is essentially the best way to go. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 19 April 2005 14:00 To: Struts Users Mailing List Subject: Editing jsp pages I wanted to know what is the best way to edit jsp pages that gives you a GUI interface versus using a text editor. If I should post this question to a different group, sorry in advance. - 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: AJAX: Whoa, Nellie!
-Original Message- I also think that a well-designed web-UI does not need JS at all... Then what results is exactly what you say: a WEB UI. This was good enough five years ago, it isn't today. People expect, generally, more robust UIs delivered in a browser. They expect webapps that look, feel and work more like fat clients. This is all a virtual impossibility without some dergee of scripting. There are of course cases where this doesn't natter... sometimes the simplistic Google front page approach is perfect. But you'll pretty quickly run up against some serious roadblocks to developing anything other than classic web UIs without scripting. Your point is well-taken... scripting does indeed entail some level of danger... but so does driving a car, and we all do that without much thought :) (which is of course part of the problem with driving today, but I digress...) -Original Message- Maybe I'm to old (in respect to IT-technology), but for me most of those highly sophisticated apps (be them client or web) are not very usable... I prefer a simple processing scheme. And from there comes my preference for pure HTML-UI's without any javascript If it MUST be more, then something like Canoo's ULC http://www.canoo.com/ulc/index.html is a possible way to go... but that's (according to my assessment of normal business apps) about 0.001% of all web-applications... Most user-requirements for RIA might be fulfilled by intensively refactoring the UI's... for more simplicity regards Alexander - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Validation Problems
Try using DynaValidatorActionForm...
-Original Message-
From: Andrew Thorell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 19, 2005 10:44 AM
To: Struts Mailing List
Subject: Validation Problems
Hey all,
I've been trying for some time now to figure out what my problem is
with my Validations not displaying error messages back to the page
from where the request came from. It's a simple login page which
pretty much follows Ted's Struts in Action example.
I'm using a Form which extends ValidatorForm, using the html:errors
/ tag in my jsp.
If you need anymore code that what's below, let me know.
public static final String errors_login=lifont
color=\red\Wrong User Name and/or Password/font/li;
public static final String errors_userpassequal=liInvalid Email
Address./li;
public ActionErrors validate(ActionMapping mapping,
HttpServletRequest request)
{
ActionErrors errors = null;
errors = super.validate(mapping, request);
if (errors == null)
{
errors = new ActionErrors();
}
if (username.equals(password))
{
errors.add(password, new
ActionMessage(Constants.errors_login));
}
if (! org.apache.commons.validator.GenericValidator.isEmail(
getusername() ) )
{
errors.add(username, new
ActionMessage(Constants.errors_userpassequal));
}
return errors;
}
// Execute Method from my Action which extends just Action:
public ActionForward execute(ActionMapping mapping, ActionForm
form, HttpServletRequest request,
HttpServletResponse response) throws IOException,
ServletException
{
boolean validate = false;
if (!validate)
{
ActionErrors errors = new ActionErrors();
errors.add(ActionErrors.GLOBAL_MESSAGE, new
ActionMessage(Constants.errors_login) );
saveErrors(request, errors);
// getInput() just returns to index.jsp where the html:errors / tag
resides.
return (new ActionForward(mapping.getInput() ) );
}
}
I'm purposely making the whole validation process fail just to get any
error message to display (Which they aren't). I was going to try using
html:messages but I'm unsure how to assign the id= tag and where I
can set the attribute for it.
Thanks for any help in advance, let me know if I can clear anything up.
-
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: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 10:37 am, Jesse Alexander (KBSA 21) said: Maybe I'm to old (in respect to IT-technology), but for me most of those highly sophisticated apps (be them client or web) are not very usable... I prefer a simple processing scheme. No doubt there were (are still are) some very highly unusable non-web applications out there. And from there comes my preference for pure HTML-UI's without any javascript Many people share this preference. There are some good reasons for it, but also some good arguments against not. Perfectly valid viewpoint though. If it MUST be more, then something like Canoo's ULC http://www.canoo.com/ulc/index.html is a possible way to go... but that's (according to my assessment of normal business apps) about 0.001% of all web-applications... I would say this is very highly environment-specific. Going by my own experience, I would say that only about 10% of the webapps I deal with in my enterprise are as simple as you are talking about. Even then I'm not sure *any* of them are completely script-free. This would echo what my experience in other environment is as well. The requirements themselves are dictating this by the way, not just some developer wanting to do something cool. Part of that comes from business analysts that know fat-clients reasonably well and expect similar experiences on the web. We might argue they have the wrong mindset, but it is what it is. I happen to agree with them, but there is room for disagrement there. Most user-requirements for RIA might be fulfilled by intensively refactoring the UI's... for more simplicity Depending on the target audience this can be good advice. If you are trying to reach the largest audience then indeed you should be thinking simplicity... Anyone ever trying accessing a more modern site with a browser on a cell phone? Ugh! Assuming it works at all, which is doubtful, it is painful in the extreme to try and use it. If this is a possibility then I think what your saying is good advice Alexander. regards Alexander - 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: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote: On Tue, April 19, 2005 5:30 am, Jesse Alexander (KBSA 21) said: I also think that a well-designed web-UI does not need JS at all... Then what results is exactly what you say: a WEB UI. This was good enough five years ago, it isn't today. People expect, generally, more robust UIs delivered in a browser. They expect webapps that look, feel and work more like fat clients. This is all a virtual impossibility without some dergee of scripting. I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. Erik -- who prefers mail2web to GMail. There are of course cases where this doesn't natter... sometimes the simplistic Google front page approach is perfect. But you'll pretty quickly run up against some serious roadblocks to developing anything other than classic web UIs without scripting. Your point is well-taken... scripting does indeed entail some level of danger... but so does driving a car, and we all do that without much thought :) (which is of course part of the problem with driving today, but I digress...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Editing jsp pages
I use My Eclipse, a plugin for Eclipse, http://myeclipseide.org. It works reasonably well and provides syntax coloring and XML validation for JSPs, and if things are set up right, it will provide context completion for standard JSP tags. I haven't had it work for JSTL tags, but that could be a setup issue on my part. I'm not trying to give a plug, just a happy user. And at $30/yr, the price can't be beat, there is a 30-day trial. -ed On 4/19/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I wanted to know what is the best way to edit jsp pages that gives you a GUI interface versus using a text editor. If I should post this question to a different group, sorry in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Validation Problems
Thanks for the speedy reply, My time is limited to solve this particular problem, but I'll definitely look into using DynaValidatorActionForm. I do have another question though, why would not using DynaValidatorActionForm prevent my code from display the error back to the jsp? Is there a limitation that I'm unaware of with my current setup? Thanks again, Andrew On 4/19/05, Folashade Adeyosoye [EMAIL PROTECTED] wrote: Try using DynaValidatorActionForm... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Struts-JSF London Networking BOF VIII / Monday / 9th MAY 2 005 @ 18:30 / Oracle City of London
WHAT: I would like to formally announce that ``The Struts-JSF London Networking'' group is holding the ninth meet-up event on Monday 9th May 2005 at Oracle office in the city of London at ``18:45'' The meeting will take place in a room with Audio/Visual facilities between 6:30-8:00 pm. Afterwords members we would all like to find an eatery for a bit to eat. WHERE: The address is: Oracle City Of London One South Place London, England EC2M 2RB. Here is some relevant travel information By Underground: - Moorgate: Take the Moorgate East exit, turn right, one block to South Place. Bank: Take the Northern line to Moorgate. Liverpool Street:Take the Broadgate exit, turn right onto South Place Map: http://www.oracle.com/global/uk/corporate/locations/citymap.html The venue has kindly been organised by Duncan Mills. AGENDA: Duncan Mills will continue with Introduction into JSF part II and Intro Shale URLS http://www.strutslondon.com http://struts.meetup.com And finally I will off to the ACCU Conference 2005 in Oxford tomorrow. http://www.accu.org/conference/ from Wednesday til Saturday Lunchtime -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 == This message is for the sole use of the intended recipient. If you received this message in error please delete it and notify us. If this message was misdirected, CSFB does not waive any confidentiality or privilege. CSFB retains and monitors electronic communications sent through its network. Instructions transmitted over this system are not binding on CSFB until they are confirmed by us. Message transmission is not guaranteed to be secure. == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 10:46 am, Michael J. said:
Struts-only or JSP-only solution is not good enough. The more portable
is the better, so when I read Frank's proposal I thought, why those
input controls are generated with custom tags? What if controls were
created with Javascript? Custom tags would be generating setup
parameters for these Javascript instead of generating input controls
directly. The result is greater portability for the control library:
basically, it would be a pure Javascript library.
You may not believe this, but I started down this path something like five
years ago... In fact, I still have the first POC I threw together.
It treated a web UI much like SWING in the sense that you wouldn't
actually write markup, you would write code instead. Now, this is a **BAD
IDEA** imho, and I recognize that now, but it is interesting and somewhat
relevant none the less. Here's an example:
html
head
link rel=StyleSheet href=VisML_Styles.css type=text/css
script language=javascript src=VisML_Base.js/script
script language=javascript src=VisML_Spinner.js/script
script language=javascript src=VisML_Swapper.js/script
script language=javascript src=VisML_Button.js/script
script
var myGUI = new VisML(myGUI);
function createGUI() {
myGUI.createComponent(myGUI.componentButton, Button1, lyrComponent);
myGUI.Button1.registerCallback(myGUI.eventOnClick, Button1_onClick);
myGUI.Button1.setLabel(This is a button - CLICK ME);
myGUI.createComponent(myGUI.componentSpinner, Spinner1,
lyrComponent);
myGUI.Spinner1.setMinimum(5);
myGUI.Spinner1.setMaximum(15);
myGUI.Spinner1.setValue(10);
myGUI.createComponent(myGUI.componentSwapper, Swapper1,
lyrComponent);
myGUI.Swapper1.setWidth(80);
myGUI.Swapper1.addItem(myGUI.Swapper1.swapperSource, Item #1, I1);
myGUI.Swapper1.addItem(myGUI.Swapper1.swapperSource, Item #2, I2);
myGUI.Swapper1.addItem(myGUI.Swapper1.swapperSource, Item #3, I3);
myGUI.Swapper1.addItem(myGUI.Swapper1.swapperSource, Item #4, I4);
}
function Button1_onClick() {
alert(You clicked the button!);
}
/script
/head
body onLoad=createGUI();
td height=160 align=centerdiv id=lyrComponentnbsp;/div/td
/body
/html
I was starting to create custom widgets as well, aside from the usual...
the spinner is just like a spinner in windows with the up and down arrows,
and the swapper is two textboxes side to side where you can move items
from one side to another and reorder them. All of them could be rendered
in a completely custom way, i.e., they didn't have to use the base HTML
button at all (although they did the first time around).
Your idea is interesting because if we created a taglib to basically
create the code you see above, that could be something interesting. Just
provide for the ability for the event callbacks to be server-side and it
begins to look kinda cool. I also was beginning to create layout
managers, which would be another logical addition.
Frank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 10:47 am, Erik Weber said: I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. You describe a good web SITE, and I couldn't agree with your criteria more! However, what you don't describe well is a web APPLICATION. Web APPLICATIONS are where the scripting is, generally, needed, and where the UI tends to be more complex. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. No doubt, information is what makes it all worth it, absolutely. I might have a nice Mac OS UI, but if all it can show me is Wiggles videos and 3rd-grade math and naked pictures of Rue Paul, the information stinks and the whole thing isn't worth anything to me. Erik -- who prefers mail2web to GMail. Frank -- who would prefer to never have the words naked pictures of Rue Paul enter his brain again under ANY circumstances! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
Hear-hear. My users would brain me if I just provided that amount of interface on a web application. -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: 19 April 2005 16:17 To: Struts Users Mailing List Cc: Struts Users Mailing List Subject: Re: AJAX: Whoa, Nellie! On Tue, April 19, 2005 10:47 am, Erik Weber said: I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. You describe a good web SITE, and I couldn't agree with your criteria more! However, what you don't describe well is a web APPLICATION. Web APPLICATIONS are where the scripting is, generally, needed, and where the UI tends to be more complex. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. No doubt, information is what makes it all worth it, absolutely. I might have a nice Mac OS UI, but if all it can show me is Wiggles videos and 3rd-grade math and naked pictures of Rue Paul, the information stinks and the whole thing isn't worth anything to me. Erik -- who prefers mail2web to GMail. Frank -- who would prefer to never have the words naked pictures of Rue Paul enter his brain again under ANY circumstances! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- The information contained herein is confidential and is intended solely for the addressee. Access by any other party is unauthorised without the express written permission of the sender. If you are not the intended recipient, please contact the sender either via the company switchboard on +44 (0)20 7623 8000, or via e-mail return. If you have received this e-mail in error or wish to read our e-mail disclaimer statement and monitoring policy, please refer to http://www.drkw.com/disc/email/ or contact the sender. 3167 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: requiredif
Thanks Erik. I was wondering, is there a client side JavaScript part? Also, is it possible to use validwhen with the old versions of struts (1.1b2). Thanks for your help. -Original Message- From: Erik Weber [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 3:24 PM To: Struts Users Mailing List Subject: Re: requiredif !-- requiredif -- validator name=requiredif classname=org.apache.struts.validator.FieldChecks method=validateRequiredIf methodParams=java.lang.Object, org.apache.commons.validator.ValidatorAction, org.apache.commons.validator.Field, org.apache.struts.action.ActionErrors, org.apache.commons.validator.Validator, javax.servlet.http.HttpServletRequest msg=errors.required/ Erik tarek.nabil wrote: Hi, I'm stuck with Struts 1.1b2 and I need to do some conditional validation. AFAIK, the way to do this for this version is using the requiredif validator. The problem is, I cannot find any reference information on how to add this validator to the validator-rules.xml configuration file. Please advise on how to do this and if there's a better way to do this with this old version. For example, is it possible to configure the old Struts/Validator versions to use validwhen? Any help is appreciated. Tarek Nabil - 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: AJAX: Whoa, Nellie!
I wholeheartedly agree that often times, simplicity is the best way to go for web (and webapp) UIs. However, end-user simplicity does not always imply developer simplicity (i.e. bare-bones HTML). Case in point: Google Maps vs. Mapquest, specifically in the Scroll Map use case. Which one is simpler and more intuitive for the user? For me, grabbing and dragging the map with my cursor (in any direction I desire) is more intuitive than clicking on arrow buttons to scroll the map (in N/S and E/W directions only). Sometimes it takes more developer effort/technology to create something that's easier to use. Sometimes it doesn't. But to say that client-side scripting is completely unnecessary for well designed application UIs is incorrect, IMO. It depends on what your users need to do. - Scott -Original Message- From: Erik Weber [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 10:48 AM To: Struts Users Mailing List Subject: Re: AJAX: Whoa, Nellie! Frank W. Zammetti wrote: On Tue, April 19, 2005 5:30 am, Jesse Alexander (KBSA 21) said: I also think that a well-designed web-UI does not need JS at all... Then what results is exactly what you say: a WEB UI. This was good enough five years ago, it isn't today. People expect, generally, more robust UIs delivered in a browser. They expect webapps that look, feel and work more like fat clients. This is all a virtual impossibility without some dergee of scripting. I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. Erik -- who prefers mail2web to GMail. There are of course cases where this doesn't natter... sometimes the simplistic Google front page approach is perfect. But you'll pretty quickly run up against some serious roadblocks to developing anything other than classic web UIs without scripting. Your point is well-taken... scripting does indeed entail some level of danger... but so does driving a car, and we all do that without much thought :) (which is of course part of the problem with driving today, but I digress...) - 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: AJAX: Whoa, Nellie!
Sometimes it takes more developer effort/technology to create something that's easier to use. Sometimes it doesn't. But to say that client-side scripting is completely unnecessary for well designed application UIs is incorrect, IMO. It depends on what your users need to do. People just should stop thinking in terms of client-side scripting and start thinking multi-tier programming ;) Webapp is an _application_ after all. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Slightly Off topic: JSTL vs Bean tags w/ message resources
I'd say there's two approaches to dealing with this. In the scope of
just this issue, I think bean:write is just a little more convenient,
but there may be other considerations.
One way would be to read in your properties file in an action and put
them into application scope. That's probably overkill just to get the
format keys easily available.
Another way would be to use fmt:message, referencing the property key,
and placing the result into a variable. Then, use that variable in the
fmt:formatDate tag, for the pattern attribute. If you have a small
number of these, and you reference it in several places, this is
probably a good approach.
-Original Message-
From: Brian McGovern [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 19, 2005 5:36 AM
To: Struts Users Mailing List
Subject: Slightly Off topic: JSTL vs Bean tags w/ message resources
Hi,
Got a slightly OT question. I want to put a date format mask
in a properties file and format dates with this key in my
presentation jsp. I can do this with struts bean tags but
seeming have to hard code it into the jstl tags. Both
approaches work but i would like to know if anyone has a way
to make the properties driven format masking work in jstl.
Bean:
bean:write name=Performance property=performanceDate
formatKey=conf.dateformat.long /
JSTL:
fmt:formatDate pattern=MM/dd/
value=${Company.membershipStartDate} /
thanks
-B
-
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]
Editing jsp pages
Thank you all for your responses. They are very helpful and will help in deciding which tool(s) to use. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: requiredif
Hi Erik, I tried it and it didn't work. I checked out the validator and struts jar files and it turned out that the org.apache.struts.validator.FieldChecks class does not exist in either of them. Is it possible that it was introduced after 1.1b2? I'm sure it's in RC1 because I'm using the documentation shipped in 1.1RC1. Thanks again for your help. -Original Message- From: tarek.nabil Sent: Tuesday, April 19, 2005 7:41 PM To: Struts Users Mailing List Subject: RE: requiredif Thanks Erik. I was wondering, is there a client side JavaScript part? Also, is it possible to use validwhen with the old versions of struts (1.1b2). Thanks for your help. -Original Message- From: Erik Weber [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 3:24 PM To: Struts Users Mailing List Subject: Re: requiredif !-- requiredif -- validator name=requiredif classname=org.apache.struts.validator.FieldChecks method=validateRequiredIf methodParams=java.lang.Object, org.apache.commons.validator.ValidatorAction, org.apache.commons.validator.Field, org.apache.struts.action.ActionErrors, org.apache.commons.validator.Validator, javax.servlet.http.HttpServletRequest msg=errors.required/ Erik tarek.nabil wrote: Hi, I'm stuck with Struts 1.1b2 and I need to do some conditional validation. AFAIK, the way to do this for this version is using the requiredif validator. The problem is, I cannot find any reference information on how to add this validator to the validator-rules.xml configuration file. Please advise on how to do this and if there's a better way to do this with this old version. For example, is it possible to configure the old Struts/Validator versions to use validwhen? Any help is appreciated. Tarek Nabil - 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: requiredif
Oh, I'm sorry. I pulled that from the last release of 1.1. Zoinks, you are stuck with a pre-1.1 version? Perhaps you could write a custom validator plugin that basically does the same thing? tarek.nabil wrote: Hi Erik, I tried it and it didn't work. I checked out the validator and struts jar files and it turned out that the org.apache.struts.validator.FieldChecks class does not exist in either of them. Is it possible that it was introduced after 1.1b2? I'm sure it's in RC1 because I'm using the documentation shipped in 1.1RC1. Thanks again for your help. -Original Message- From: tarek.nabil Sent: Tuesday, April 19, 2005 7:41 PM To: Struts Users Mailing List Subject: RE: requiredif Thanks Erik. I was wondering, is there a client side JavaScript part? Also, is it possible to use validwhen with the old versions of struts (1.1b2). Thanks for your help. -Original Message- From: Erik Weber [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 3:24 PM To: Struts Users Mailing List Subject: Re: requiredif !-- requiredif -- validator name=requiredif classname=org.apache.struts.validator.FieldChecks method=validateRequiredIf methodParams=java.lang.Object, org.apache.commons.validator.ValidatorAction, org.apache.commons.validator.Field, org.apache.struts.action.ActionErrors, org.apache.commons.validator.Validator, javax.servlet.http.HttpServletRequest msg=errors.required/ Erik tarek.nabil wrote: Hi, I'm stuck with Struts 1.1b2 and I need to do some conditional validation. AFAIK, the way to do this for this version is using the requiredif validator. The problem is, I cannot find any reference information on how to add this validator to the validator-rules.xml configuration file. Please advise on how to do this and if there's a better way to do this with this old version. For example, is it possible to configure the old Struts/Validator versions to use validwhen? Any help is appreciated. Tarek Nabil - 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: AJAX: Whoa, Nellie!
We need to agree to disagree on the virtue/detriment of javascript in web pages. Different applications for different audiences with different purposes have different solutions. At my company we've implemented intranet apps where the users do a significant amount of heads-down data entry. They need validation and adding in of date and telephone mark-up and they want it to happen without waiting for a server round-trip. That needed some heavy js. Other applications have been internet apps where we needed to support the widest variety of browsers and os'es. For that environment js is anathema. Frank W. Zammetti wrote: On Tue, April 19, 2005 10:47 am, Erik Weber said: I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. You describe a good web SITE, and I couldn't agree with your criteria more! However, what you don't describe well is a web APPLICATION. Web APPLICATIONS are where the scripting is, generally, needed, and where the UI tends to be more complex. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. No doubt, information is what makes it all worth it, absolutely. I might have a nice Mac OS UI, but if all it can show me is Wiggles videos and 3rd-grade math and naked pictures of Rue Paul, the information stinks and the whole thing isn't worth anything to me. Erik -- who prefers mail2web to GMail. Frank -- who would prefer to never have the words naked pictures of Rue Paul enter his brain again under ANY circumstances! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
+1 Frank! Good old agility and Xtreme principles say do it and worry about all this wah wah wah wah later. You have a simple and very useful idea which is at the beginning stages but which is well-thought out and which is based on a solid engineering foundation. Go for it as you initially conceived it. Jack On 4/19/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Tue, April 19, 2005 2:47 am, Craig McClanahan said: This is exactly the area I've been having trouble with this proposal as well ... tell me again why you can't use Ajax techniques with the standard Struts HTML tags? No one, at least not me, has made that statement at any point. I frankly do not use the Struts tags most of the time, yet I do AJAX just fine. There is no debate on this point: there is no NEED for the Struts HTML tags to do AJAX. If you can do it with handwritten HTML pages (which you certainly can), you can also do it with existing Struts HTML tags (or the standard JSF components, for that matter) that offer attributes like onchange and onclick to plug in your calls to JavaScript methods that do the actual background calls, and then update the client side DOM of your page. Agreed. But then you have to do everything yourself. If 80% of the time people are doing the same kinds of things like replacing the content of a specific DOM elements' innerHTML, why not provide a standard approach to that? Further, we are constantly talking about the dichotomy of having a separate group of page developers and back-end developers. Why should a page developer need to know Javascript? Isn't that like saying they need to know Java on the server? You could of course make the argument that scripting is appropriately a part of a page developers' reportoire, and I don't think I would argue, but they already avoid a great deal of scripting by using various taglibs, so why shouldn't they want to avoid scripting to implement at least basic AJAX techniques? That is what is at the heart of what I did. It seems to me that a framework can provide value add in primarily the following areas: See, when we start talking about a framework we are starting to talk about something more grandiose than what I put together. That is in no way to say it isn't a good idea, just that it is different. * Provide a client side JavaScript library that does the grunt work of making the back-end XmlHttpRequest call, and updating the corresponding portion of your DOM. Martin likes DOJO for this; there are also a bunch of other libraries that do the same sort of thing that should be leveraged, instead of inventing something new. Not everyone likes throwing the kitchen sink into their projects to provide a relatively small amount of functionality. It is amazing to me that anyone would make the argument against something that is too simple! Why do we always have to develop the next big thing rather than something that will help 80% of the people 80% of the time? Why is the later a seemingly Bad Thing? * Provide a server side framework that makes it easy to map a particular XHR invocation to the corresponding business logic, and (for extra credit) maps the response data to a generic data format so you don't have to write specific formatting logic for every single response type. I sort of like what JSON provides as a transport protocol, but there's room for value add here on the server side, with a generic data abstraction that maps into the appropriate transport formats. I do actually like this idea, but again, the difference between this and what I put together is night and day... this is leading down a much more complex and expansive path. It's a path I would be excited to walk down, but it puts delivered results further away as opposed to what I did that could be completed in relatively short order and help people NOW. Also, what you are talking about, and what Martin has been talking about, while a good idea to be sure, doesn't really help people with existing apps. It is akin to my Struts Web Services project... I have never at any time promoted that as the be-all and end-all of Web Services. What I have said is that if you have an existing Strtus-based application and need to expose parts of it as Web Services, here's one quick and easy way to do it. Likewise, what I proposed is a quick and easy way to introduce AJAX functionality into an existing app with a minimum of fuss and muss. There is not a lot of code to write (none if I do it right) and it's not an all-or-nothing proposition, you don't have to use a whole new framework on the client and the server to make it work. The what you and Martin are talking about, I can't see how that would be the case. So, while the ideas may have a great deal of merit, they require a far greater change for developers and don't, I think, help anyone NOW. * Provide
Re: AJAX: Whoa, Nellie!
I don't think he said absolutely everyone, including specifically Erik Weber, Erik. You turn out, in the end, to be just a person: not people. ///;-) Jack On 4/19/05, Erik Weber [EMAIL PROTECTED] wrote: Frank W. Zammetti wrote: On Tue, April 19, 2005 5:30 am, Jesse Alexander (KBSA 21) said: I also think that a well-designed web-UI does not need JS at all... Then what results is exactly what you say: a WEB UI. This was good enough five years ago, it isn't today. People expect, generally, more robust UIs delivered in a browser. They expect webapps that look, feel and work more like fat clients. This is all a virtual impossibility without some dergee of scripting. I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. Erik -- who prefers mail2web to GMail. There are of course cases where this doesn't natter... sometimes the simplistic Google front page approach is perfect. But you'll pretty quickly run up against some serious roadblocks to developing anything other than classic web UIs without scripting. Your point is well-taken... scripting does indeed entail some level of danger... but so does driving a car, and we all do that without much thought :) (which is of course part of the problem with driving today, but I digress...) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using validate() and returning to original page dynamically
On 4/19/05, Joe Germuska [EMAIL PROTECTED] wrote:
At 11:06 PM -0700 4/18/05, Michael J. wrote:
2) You can set the params too, it is not a big deal. Do not edit
existing ActionForward from findForward, instead create a new one and
append query parameters.
Note that about two months ago, a class called ActionRedirect was
added to clean up this particular use case (adding parameters to a
redirecting ActionConfig.)
http://cvs.apache.org/viewcvs.cgi/struts/core/trunk/src/share/org/apache/struts/action/ActionRedirect.java?root=Apache-SVNrev=153901view=markup
No Struts release has been made since this was added, but you should
know it's there and if you're using a nightly build, you should use
it.
Joe
Whoa, a whole class. I use just a simple method, which appends
parameters for redirected request. There is no point to do this for
forwarded parameters, they can be passed through server-side objects.
This utility method is quite simple, it does not do a lot of error
handling, nor does it check for character set or for maximum URL
length. I use the same mappings from struts-config.xml file, I just
append request query parameters.
This is my action class:
public ActionForward execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) {
...
return ActionTools.goForward(
mapping, // mapping of this action
editItem, // edit action name: editItem.do
true,// redirect == true
new String[] {id=+itemId} // ex: id=1234
);
}
This is my helper method:
-
/**
* Updates ActionForward object with URL parameters.
* @param actionMapping action mapping object
* @param forwardNamemapping name
* @param redirect true if redirect, false if forward
* @param urlParams array of key=value strings which
* should be added to actionForward path
* as HTTP GET parameters
* @return modified ActionForward object with updated GET parameters
*/
public static ActionForward goForward(ActionMapping actionMapping,
String forwardName,
String[] urlParams)
{
// Find ActionForward object, defined in struts-config.xml
ActionForward actionForward = actionMapping.findForward(forwardName);
if (actionForward == null) return null;
// Append URL parameters. Important on redirect.
String actionPath = actionForward.getPath();
if (actionPath != null urlParams != null) {
for (int i = 0; i urlParams.length; i++) {
actionPath += i==0 ? ? : ;
actionPath += urlParams[i];
}
}
// Create new ActionForward object. Stuts does not
// allow to modify ActionForward objects, statically
// defined in struts-config.xml
ActionForward actionRedirect =
new ActionForward(actionForward.getName(),
actionPath,
redirect
);
return actionRedirect;
}
Michael.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Michael J. wrote: People just should stop thinking in terms of client-side scripting and start thinking in terms of client-side rendering :-) (XAML, XUL, Flex, JDNC, DHTML(Ajax, JavaScript)). UI naturaly should be done on client side, asking for domain and other services from the server. The more you do client-side the richer the UI. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Slightly Off topic: JSTL vs Bean tags w/ message resources
I tried it but got no luck. I think the pattern attrib of formatDate only
takes in literal strings in form of mm/dd/ or something like that.
fmt:message key=${conf.dateformat.long} var=DateFormatMaskfmt:formatDate
pattern=${DateFormatMask} value=${Company.membershipStartDate}
//fmt:message
Am i doing something wrong there?
-B
-Original Message-
From: Karr, David [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 19, 2005 11:51 AM
To: Struts Users Mailing List
Subject: RE: Slightly Off topic: JSTL vs Bean tags w/ message resources
I'd say there's two approaches to dealing with this. In the scope of
just this issue, I think bean:write is just a little more convenient,
but there may be other considerations.
One way would be to read in your properties file in an action and put
them into application scope. That's probably overkill just to get the
format keys easily available.
Another way would be to use fmt:message, referencing the property key,
and placing the result into a variable. Then, use that variable in the
fmt:formatDate tag, for the pattern attribute. If you have a small
number of these, and you reference it in several places, this is
probably a good approach.
-Original Message-
From: Brian McGovern [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 19, 2005 5:36 AM
To: Struts Users Mailing List
Subject: Slightly Off topic: JSTL vs Bean tags w/ message resources
Hi,
Got a slightly OT question. I want to put a date format mask
in a properties file and format dates with this key in my
presentation jsp. I can do this with struts bean tags but
seeming have to hard code it into the jstl tags. Both
approaches work but i would like to know if anyone has a way
to make the properties driven format masking work in jstl.
Bean:
bean:write name=Performance property=performanceDate
formatKey=conf.dateformat.long /
JSTL:
fmt:formatDate pattern=MM/dd/
value=${Company.membershipStartDate} /
thanks
-B
-
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: AJAX: Whoa, Nellie!
HUZZAH! +1 This is about AJAX, not about JavaScript. I am with those who say that if you don't like abortion, don't have one. Also, if you don't like JavaScript, don't use it. But, in the middle of an AJAX discussion all this pro and con JavaScript discussion is ridiculous. Jack On 4/19/05, Jason King [EMAIL PROTECTED] wrote: We need to agree to disagree on the virtue/detriment of javascript in web pages. Different applications for different audiences with different purposes have different solutions. At my company we've implemented intranet apps where the users do a significant amount of heads-down data entry. They need validation and adding in of date and telephone mark-up and they want it to happen without waiting for a server round-trip. That needed some heavy js. Other applications have been internet apps where we needed to support the widest variety of browsers and os'es. For that environment js is anathema. Frank W. Zammetti wrote: On Tue, April 19, 2005 10:47 am, Erik Weber said: I, with respect for the author, disagree with this entirely. I am people, and this is not what I expect or desire at all. As a user, I expect and desire 1) A fast download 2) my bookmarks to work/easy to remember URLs 3) an organized and well-thought-out left rail 4) a go home link at the top 5) a two-field registration 6) an encrypted log on 7) content I can read in a text-only browser. None of these require any browser scripting at all. You describe a good web SITE, and I couldn't agree with your criteria more! However, what you don't describe well is a web APPLICATION. Web APPLICATIONS are where the scripting is, generally, needed, and where the UI tends to be more complex. And most importantly, I want information that I regard as being of great quality. Anything beyond the seven I mentioned only gets in my way. No doubt, information is what makes it all worth it, absolutely. I might have a nice Mac OS UI, but if all it can show me is Wiggles videos and 3rd-grade math and naked pictures of Rue Paul, the information stinks and the whole thing isn't worth anything to me. Erik -- who prefers mail2web to GMail. Frank -- who would prefer to never have the words naked pictures of Rue Paul enter his brain again under ANY circumstances! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
That's an interesting comment Vic... are you saying you favor an approach where the entire client view itself is rendered on the client? I ask because that used to be my thinking, and I'm moved away from it to some degree. By way of example: * The little proof of concept thing I mentioned ealier that treated the UI more like Swing, i.e., what came back from the server was essentially nothing but code that was executed on the client to create the UI on-the-fly. * I've previously done two apps that when you first access them you download about 200K of HTML that is stuck in some frames (a couple hidden). From that point on all you get back from the server regardless of what you do is some Javascript variables, and those variables are used to populate the HTML that is already on the client and the proper page shown. What I'm getting at is that it is more than possible that every request to the server results in very little being returned (maybe XML, maybe just comma-separated data, maybe just some Javascript), which implies the entire UI is either rendered on-the-fly on the client with each request or else it already exists and is just modified with the data returned by the server. I'm interested in knowing if that's what you are actually saying because, while I have moved away from it a bit as I've said, I still believe that approach has significant advantages, but for a long time I thought I was the only one that thought so! :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, April 19, 2005 12:57 pm, Vic Cekvenich (netsql) said: Michael J. wrote: People just should stop thinking in terms of client-side scripting and start thinking in terms of client-side rendering :-) (XAML, XUL, Flex, JDNC, DHTML(Ajax, JavaScript)). UI naturaly should be done on client side, asking for domain and other services from the server. The more you do client-side the richer the UI. .V - 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: AJAX: Whoa, Nellie!
Dakota Jack wrote: I don't think he said absolutely everyone, including specifically Erik Weber, Erik. You turn out, in the end, to be just a person: not people. ///;-) Not me, though; I'm actually people. I may be schizophrenic, but at least I have each other. on-topic obligatory='true' I like fast download times, but I hate the web: I want any page that's more complicated than Here, download this, you'll be better off to have functionality that doesn't make me wait all the time. For a server round-trip. Sometimes it's faster the Ajax way, as far as I can tell. I _hate_ the way maps work on mapquest; I _love_ the google maps--much more intuitive, much easier to maintain continuity across map sections, etc. Blows me away every time I drag that sucker. /on-topic Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On 4/19/05, Dave Newton [EMAIL PROTECTED] wrote: on-topic obligatory='true' I like fast download times, but I hate the web: I want any page that's more complicated than Here, download this, you'll be better off to have functionality that doesn't make me wait all the time. For a server round-trip. Sometimes it's faster the Ajax way, as far as I can tell. I _hate_ the way maps work on mapquest; I _love_ the google maps--much more intuitive, much easier to maintain continuity across map sections, etc. Blows me away every time I drag that sucker. /on-topic Dave offtopic Have you tried this one: http://map.search.ch/ Try to magnify ;) /offtopic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Fw: Java DevCon 2005 - May 25
Our local Atlanta Java Users Group is hosting a Developer Conference and if you live anywhere in the Southeastern U.S. (or visiting at that time), I would encourage you to attend. This is going to be a great event and I look forward to meeting more of my fellow developers out there in the OSSC (Open Source Software Community) and POJC (Plain Old Java Community ;) -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Burr Sutter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 10:16 AM Subject: Java DevCon 2005 - May 25 Please join fellow Atlanta-based Java developers to learn from internationally and regionally recognized Java experts and share best practices. - Matt Thompson - Sun Group Manager of Technology Evangelism - Gavin King - The founder of the Hibernate project - John Bobowicz - www.java.net CTO and Founder - Kevin Barfield - Expert on business process management - JBoss jBPM - James Mitchell - Active Struts Committer - Struts Best Practices - Keith Donald - Co-lead Developer of Spring Framework Web Flow project - RIAs with Flex J2EE by Dan Glauser, Leif Wells and Jesse Warden Java DevCon 2005 - Atlanta Java Users Annual Conference Date: May 25, 2005 Time: 8am to 6pm Location: Cobb Galleria Price: $75 (includes breakfast, lunch refreshments) Registration: www.ajug.org/devcon2005 Hibernate, Spring, JBoss jBPM, Struts, JSF, Flash RIAs and much more. We have the several of the developers behind the some of the most popular open source projects! Java DevCon 2005 is a software developers' conference and represents the most economical educational event a professional Java developer can attend in Atlanta. The typical developers' conference normally costs $300 or more a day plus you have to convince the boss to let you purchase a plane ticket and be absence from your projects for an entire week. The meals and breaks are organized to maximize attendee interaction so you can learn what other local Java experts are working on in Atlanta! The Atlanta Java Users Group, Inc is a volunteer managed 501c non-profit organization. AJUG is the focal point for Java evangelism by providing community-driven educational and networking opportunities for software developers. --- ** Topic: Struts Best Practices Speaker: James Mitchell Bio: James serves as a member of the Apache Struts PMC (Project Management Committee) and is one of a handful of active committers on the Apache Struts and Jakarta Commons projects. James is the owner and CEO of EdgeTech, Inc. He works as an independent consultant with clients in Atlanta, California, and New York. James has over 11 years of experience in building Web Applications for the E-commerce, Banking, Government, and Financial Services industries. Through his company, James also provides specialized services and training for companies needing team development training, mentoring, and/or project recovery. ** Topic: Integrating Flash Rich Internet Applications (RIA) with Java Speaker: Dan Glauser, Leif Wells, Jesse Warden Bio: Dan Glauser has 8 years of industry experience and has architected, written, deployed, and maintained numerous large scale applications for companies like BellSouth (southeast), Benefit Point (San Francisco, CA), and numerous others. Dan has a B.S. in Computer Science for the University of Massachusetts at Amherst. Leif Wells is the Director of Multimedia Services at Roundbox Media. Leif has 15 years of interactive media experience as a lead developer with companies like IBM, Coca-Cola, Home Depot, UPS, and Georgia-Pacific. Leif runs the Atlanta Macromedia User Group Jesse Warden is a professional multimedia developer working at Round Box Media, and specializes in Flash Development. He has spoken at many venues including MXDU 2003, 2005, multiple Atlanta Macromedia User Groups, and other venues about various Macromedia products and technologies. ** Topic: Spring Unleashed Speaker: Keith Donald Bio: Keith has been involved with the Spring Framework as a user and core contributor since July 2003. He is the founder of the Spring Rich Client Project (spring-rich), an emerging module built on core Spring that substantially reduces the time and effort required to build a well-architected, enterprise-ready java desktop applications. He is also the co-lead of the Spring Web Flow module, a core Spring web offering that lets developers model business processes that span many screens in a logical manner. ** Topic: Insider's View of Hibernate 3.0 Speaker: Gavin King Bio: Gavin is the founder of the Hibernate project, the leading persistence solution for Java. He is an active member of the JSR-220 expert group, and contributed heavily to the design of EJB 3.0. With Christian Bauer, he was author of /Hibernate in Action/. Gavin works for JBoss,
Re: AJAX: Whoa, Nellie!
You would, I think, love some of the apps I've put together. The problem though, as far as other developers go, is that they really are a whole different paradigm than what most are used to. Ironically, the very first web app I did for my current employer some five years ago is the best example of it... You have to sit through a 10-second delay at startup, give or take, and after that it is blazingly fast (except when database or mainframe access has to happen). Simply put, there isn't the usual HTML rendering happening on the server because the HTML essentially already exists. Any request simply results in what amounts to token replacements in existing markup. It is a bit more dependant on the capabilities of the client, i.e., you can notice a difference in the performance of the app between a 500MHz P3 and a 2GHz P4, more than you would a typical webapp. To think it could be even better now with the dawning of the AJAX age (XMLHttpRequest was brand-spanking new then, the app was already nearing completion) is an amazing thought. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, April 19, 2005 1:10 pm, Dave Newton said: Dakota Jack wrote: I don't think he said absolutely everyone, including specifically Erik Weber, Erik. You turn out, in the end, to be just a person: not people. ///;-) Not me, though; I'm actually people. I may be schizophrenic, but at least I have each other. on-topic obligatory='true' I like fast download times, but I hate the web: I want any page that's more complicated than Here, download this, you'll be better off to have functionality that doesn't make me wait all the time. For a server round-trip. Sometimes it's faster the Ajax way, as far as I can tell. I _hate_ the way maps work on mapquest; I _love_ the google maps--much more intuitive, much easier to maintain continuity across map sections, etc. Blows me away every time I drag that sucker. /on-topic Dave - 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: AJAX: Whoa, Nellie!
Michael J. wrote: offtopic Have you tried this one: http://map.search.ch/ Try to magnify ;) /offtopic Oh, that's neat. If you could drag it it'd be like a real application! Cool! Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote: Simply put, there isn't the usual HTML rendering happening on the server because the HTML essentially already exists. Just a nitpick; there's never any HTML rendering on the server. Generation, perhaps, but not rendering. /bitchiness Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
This may be straying a bit from the AJAX discussion? On 4/19/05, Michael J. [EMAIL PROTECTED] wrote: On 4/19/05, Dave Newton [EMAIL PROTECTED] wrote: on-topic obligatory='true' I like fast download times, but I hate the web: I want any page that's more complicated than Here, download this, you'll be better off to have functionality that doesn't make me wait all the time. For a server round-trip. Sometimes it's faster the Ajax way, as far as I can tell. I _hate_ the way maps work on mapquest; I _love_ the google maps--much more intuitive, much easier to maintain continuity across map sections, etc. Blows me away every time I drag that sucker. /on-topic Dave offtopic Have you tried this one: http://map.search.ch/ Try to magnify ;) /offtopic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Well, to the extent that AJAX techniques can make a site seem faster, it is actually on-topic. And I don't care if this map thing is on-topic or not, it is cool as hell :) By the way, not sure who said it, but you can in fact scroll around this map, just like Google Maps, by dragging. The zoom is very nice, and cross-browser... I'm surprised the pixelation effect worked in Firefox, I thought that was still an IE-specific DirectX-based filter. Sweet! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, April 19, 2005 1:27 pm, Dakota Jack said: This may be straying a bit from the AJAX discussion? On 4/19/05, Michael J. [EMAIL PROTECTED] wrote: On 4/19/05, Dave Newton [EMAIL PROTECTED] wrote: on-topic obligatory='true' I like fast download times, but I hate the web: I want any page that's more complicated than Here, download this, you'll be better off to have functionality that doesn't make me wait all the time. For a server round-trip. Sometimes it's faster the Ajax way, as far as I can tell. I _hate_ the way maps work on mapquest; I _love_ the google maps--much more intuitive, much easier to maintain continuity across map sections, etc. Blows me away every time I drag that sucker. /on-topic Dave offtopic Have you tried this one: http://map.search.ch/ Try to magnify ;) /offtopic - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - 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: [ANN] Fw: Java DevCon 2005 - May 25
Dang, What's really bad is I live in Atlanta (well ok, north of Atlanta on the I-75 corridor) but I work in Chicago M-Thurs so I won't be able to make it. :( Al -Original Message- From: James Mitchell [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 12:20 PM To: Struts Users Mailing List Cc: Struts Developers List Subject: [ANN] Fw: Java DevCon 2005 - May 25 Our local Atlanta Java Users Group is hosting a Developer Conference and if you live anywhere in the Southeastern U.S. (or visiting at that time), I would encourage you to attend. This is going to be a great event and I look forward to meeting more of my fellow developers out there in the OSSC (Open Source Software Community) and POJC (Plain Old Java Community ;) -- James Mitchell Software Engineer / Open Source Evangelist Consulting / Mentoring / Freelance EdgeTech, Inc. 678.910.8017 AIM: jmitchtx Yahoo: jmitchtx MSN: [EMAIL PROTECTED] - Original Message - From: Burr Sutter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 10:16 AM Subject: Java DevCon 2005 - May 25 Please join fellow Atlanta-based Java developers to learn from internationally and regionally recognized Java experts and share best practices. - Matt Thompson - Sun Group Manager of Technology Evangelism - Gavin King - The founder of the Hibernate project - John Bobowicz - www.java.net CTO and Founder - Kevin Barfield - Expert on business process management - JBoss jBPM - James Mitchell - Active Struts Committer - Struts Best Practices - Keith Donald - Co-lead Developer of Spring Framework Web Flow project - RIAs with Flex J2EE by Dan Glauser, Leif Wells and Jesse Warden Java DevCon 2005 - Atlanta Java Users Annual Conference Date: May 25, 2005 Time: 8am to 6pm Location: Cobb Galleria Price: $75 (includes breakfast, lunch refreshments) Registration: www.ajug.org/devcon2005 Hibernate, Spring, JBoss jBPM, Struts, JSF, Flash RIAs and much more. We have the several of the developers behind the some of the most popular open source projects! Java DevCon 2005 is a software developers' conference and represents the most economical educational event a professional Java developer can attend in Atlanta. The typical developers' conference normally costs $300 or more a day plus you have to convince the boss to let you purchase a plane ticket and be absence from your projects for an entire week. The meals and breaks are organized to maximize attendee interaction so you can learn what other local Java experts are working on in Atlanta! The Atlanta Java Users Group, Inc is a volunteer managed 501c non-profit organization. AJUG is the focal point for Java evangelism by providing community-driven educational and networking opportunities for software developers. --- ** Topic: Struts Best Practices Speaker: James Mitchell Bio: James serves as a member of the Apache Struts PMC (Project Management Committee) and is one of a handful of active committers on the Apache Struts and Jakarta Commons projects. James is the owner and CEO of EdgeTech, Inc. He works as an independent consultant with clients in Atlanta, California, and New York. James has over 11 years of experience in building Web Applications for the E-commerce, Banking, Government, and Financial Services industries. Through his company, James also provides specialized services and training for companies needing team development training, mentoring, and/or project recovery. ** Topic: Integrating Flash Rich Internet Applications (RIA) with Java Speaker: Dan Glauser, Leif Wells, Jesse Warden Bio: Dan Glauser has 8 years of industry experience and has architected, written, deployed, and maintained numerous large scale applications for companies like BellSouth (southeast), Benefit Point (San Francisco, CA), and numerous others. Dan has a B.S. in Computer Science for the University of Massachusetts at Amherst. Leif Wells is the Director of Multimedia Services at Roundbox Media. Leif has 15 years of interactive media experience as a lead developer with companies like IBM, Coca-Cola, Home Depot, UPS, and Georgia-Pacific. Leif runs the Atlanta Macromedia User Group Jesse Warden is a professional multimedia developer working at Round Box Media, and specializes in Flash Development. He has spoken at many venues including MXDU 2003, 2005, multiple Atlanta Macromedia User Groups, and other venues about various Macromedia products and technologies. ** Topic: Spring Unleashed Speaker: Keith Donald Bio: Keith has been involved with the Spring Framework as a user and core contributor since July 2003. He is the founder of the Spring Rich Client Project (spring-rich), an emerging module built on core Spring that substantially reduces the time and effort required to build a well-architected, enterprise-ready java desktop applications. He is also the co-lead of the Spring Web Flow module, a
Re: AJAX: Whoa, Nellie!
That's actually a good point... We've all heard about JSF and ASP.Net, how they handle client-side events server-side, which is a concept I've never been especially enamored with. But, when you see some actual examples of this in things like what Google is doing, you start to reconsider that position a bit. This isn't about richer UIs because, let's be honest folks, GMail is no great shakes interface-wise. What is cool about it is the overall performance and efficiency of it, and as Jack says, that is all about interaction with the server, not what the user sees. Another benefit of AJAX that I haven't seen mentioned much is error handling... Instead of seeing 404s or 500s or cryptic stack dumps or whatever else the server spews out, the user only sees what the AJAX developer wants them to see. Error handling no longer results in the entire flow of a web app breaking down, it can be handled considerably more gracefully than before, especially now that try...catch is a supported JS function (it wasn't always as I recall). All this is of course in the realm of client-server interaction as Jack is talking about, but in this case it ALSO results in a better user experience. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, April 19, 2005 1:23 pm, Dakota Jack said: I have another perspective on this. Rich UIs are good, but what I like about AJAX in addition to that somewhat peripheral concern (to me) is that it cooperates with the serverside and allows the serverside to be more efficient. The relationship between the server and the client in AJAX is what is most interesting and is what makes it so useful. There is a reason why the sites using AJAX, e.g. Google, do so. It is not because they are seeking, necessarily, any sort of rich clients. They are seeking robustness and usefulness. That is where AJAX is at, I think. All this other talk is fine, but it misses the main point of what makes AJAX interesting for Struts. The rich client stuff can be a dark hole for serverside discussions. AJAX is not. Jack On 4/19/05, Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Michael J. wrote: People just should stop thinking in terms of client-side scripting and start thinking in terms of client-side rendering :-) (XAML, XUL, Flex, JDNC, DHTML(Ajax, JavaScript)). UI naturaly should be done on client side, asking for domain and other services from the server. The more you do client-side the richer the UI. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - 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: AJAX: Whoa, Nellie!
I may be nuts, many have said I am on this list, unfairly, but isn't rendering HTML capable of being understood either as rendering the HTML meaning creating the HTML or rendering the HTML meaning creating the view from the HTML? At least people like David Geary talk about serverside rendering all the time with layout applications. Jack On 4/19/05, Dave Newton [EMAIL PROTECTED] wrote: Frank W. Zammetti wrote: Simply put, there isn't the usual HTML rendering happening on the server because the HTML essentially already exists. Just a nitpick; there's never any HTML rendering on the server. Generation, perhaps, but not rendering. /bitchiness Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Dakota Jack wrote: This may be straying a bit from the AJAX discussion? ...which is straying a bit from Struts? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
I think this AJAX discussion was about integrating AJAX and Struts. Not complaining about your asides, Dave. Just trying to maintain some focus. ///;-) On 4/19/05, Dave Newton [EMAIL PROTECTED] wrote: Dakota Jack wrote: This may be straying a bit from the AJAX discussion? ...which is straying a bit from Struts? Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Dakota Jack wrote: I may be nuts, many have said I am on this list, unfairly, but isn't rendering HTML capable of being understood either as rendering the HTML meaning creating the HTML or rendering the HTML meaning creating the view from the HTML? At least people like David Geary talk about serverside rendering all the time with layout applications. Sure, we can define it to be whatever you want, that's the beauty of language. Maybe you could say rendering a view and the view is rendered _as_ HTML, but the HTML still isn't rendered until it's drawn on a screen (or other media, yeah yeah). Or maybe rendering _to_ HTML, as one definition of render means to express in another language. Rendered sounds funny now. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Not if I complete my project! ;) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Tue, April 19, 2005 1:37 pm, Dave Newton said: Dakota Jack wrote: This may be straying a bit from the AJAX discussion? ...which is straying a bit from Struts? Dave - 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]
Token question
if (null == request.getParameter(Constants.TOKEN_KEY)) {
saveToken(request);
}
else {
if (!isTokenValid(request, true)) {
response.sendError(HttpServletResponse.SC_CONFLICT, The request
received was out
of sequence, perhaps due to a second submit, refresh, or unexpected
post
data.);
return null;
}
}
I have this code in my execute method. The request won't have a token unless
it is a form submission. Therefore, I think I can safely get away with this
code.
Is this true? I believe using tokens is the preferred way to handle duplicate
form submits. However, I'm not clear on the best way to do this.
Thanks,
Derrick
RE: Token question
I typically save the token in the action responsible for forwarding to
the page that displays the form. Then the action that reads the form
data can check the token and re-save (and forward to the input page) if
the user needs to retry a failed request (not validation related).
-Original Message-
From: Derrick Koes [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 19, 2005 11:23 AM
To: [EMAIL PROTECTED]
Subject: Token question
if (null == request.getParameter(Constants.TOKEN_KEY)) {
saveToken(request);
}
else {
if (!isTokenValid(request, true)) {
response.sendError(HttpServletResponse.SC_CONFLICT, The request
received was out
of sequence, perhaps due to a second submit, refresh, or
unexpected post
data.);
return null;
}
}
I have this code in my execute method. The request won't have a token
unless it is a form submission. Therefore, I think I can safely get
away with this code.
Is this true? I believe using tokens is the preferred way to handle
duplicate form submits. However, I'm not clear on the best way to do
this.
Thanks,
Derrick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote: Not if I complete my project! ;) I hope you do! See if you can put some version on struts.sf.net, this is how some committers got in. I am no JavaScript guru, but something similar to XUL and new W3 XForms, were it's even possible to just send XML-RPC style XML to the server, beyond the XMLRequest or inside it. And then have a .js library that generates HTML. I got this from MC (not CM), but it's a strech I think. http://nwidgets.org http://dojotoolkit.org The more generating of html you do in browser, the more scalability you have on server and the faster it appears to user. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On Tue, April 19, 2005 2:33 pm, Vic Cekvenich (netsql) said: Frank W. Zammetti wrote: Not if I complete my project! ;) I hope you do! See if you can put some version on struts.sf.net, this is how some committers got in. That's my plan at the moment. There frankly isn't a ton left to do to get it to an initial release, maybe 20 hours or so of solid wokr, so if I can find some time this week or next I should be able to bang it out, then the fun of testing and blowing it up begins :) I am no JavaScript guru, but something similar to XUL and new W3 XForms, were it's even possible to just send XML-RPC style XML to the server, beyond the XMLRequest or inside it. And then have a .js library that generates HTML. My only concern with those ideas is the requirement of using XML. To be honest, where I've used AJAX-type techniques in the past, I've only used XML one time. I plan on allowing for both with what I'm doing, but looking down the road, I'm not really convinced that XML being sent and received all the time is the way to go... XML has never seemed to me a good way to go for things that are essentially transactional (where transactional here really just means potentially numerous and rapid-fire, i.e., UI events). The transport time is greater, although that concern isn't as great as it used to be, and there is also the added delay of parsing and creating it. Then again, I wouldn't want to create my own protocol for something like that, so it's a tough call either way. I got this from MC (not CM), but it's a strech I think. http://nwidgets.org http://dojotoolkit.org The Dojo things looks cool, but at least upon a quick read through it, didn't strike me as much more than a wrapper (albeit a very nice one) around XMLHttpRequest, with the added capability of using other transports, whatever that means in this case. That isn't meant to belittle it in any way, it does look nice for what it is, but my initial impression is that it's just a piece of the puzzle, not a full-fledged solution. I'll check it out in more detail though, I could certainly have missed something as quick as I went through it. The more generating of html you do in browser, the more scalability you have on server and the faster it appears to user. I agree, however, the caveat is that if you do too much you'll have just the opposite effect. Case in point... The app I've been referring to today from a couple of years back had on one screen the ability to page through data and do real-time sorting. This was done by making calls to the server to get chunks of data which was returned something along these lines: htmlheadscript a = new Array(); a[0][0] = Frank; a[0][1] = Zammetti; a[1][0] = Cindy; a[1][1] = Crawford; /script/head body onLoad=window.top.fraAPI.doLoad();/body /html So, when this is returned (to a hidden frame), it fires the doLoad() function in another hidden frame (named fraAPI), which would take the data from the array and generate the HTML. It's nice because only data is ever returned from the server (plus the small amount of scripting and page infrastructure). The problem arose, initially, because we were allowing for something like 300 records max at a time. Such a request was taking like 5 seconds on a P3 550. As it turns out, the response from the server was sub-second (VERY low, better than anything we see even today in current apps doing everything on the server), the rest was the actual rendering. We simply reduced the number of records you could look at at one time, but you could see a big different if you went to a more powerful PC. This isn't ideal either, so you have to deal with the tradeoffs well to make this approach work well. Frank .V - 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: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote: The problem arose, initially, because we were allowing for something like 300 records max at a time. Such a request was taking like 5 seconds on a P3 550. As it turns out, the response from the server was sub-second (VERY low, better than anything we see even today in current apps doing everything on the server), the rest was the actual rendering. We simply reduced the number of records you could look at at one time, but you could see a big different if you went to a more powerful PC. See for rich UI, you assume people have better PC's. Do look more into dojo, it be nice to integrate some .js componet libraries w/. I am sure that some devs are doing very rich .js and know .js component libs. (similar to how validate tag emits .js and then leverage the onclient library to render an avialbe component. Like a .js tree. again, my ignorance of .js will get me in trouble) GOOD LUCK! .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Token question
On 4/19/05, Derrick Koes [EMAIL PROTECTED] wrote:
if (null == request.getParameter(Constants.TOKEN_KEY)) {
saveToken(request);
}
else {
if (!isTokenValid(request, true)) {
response.sendError(HttpServletResponse.SC_CONFLICT, The request
received was out
of sequence, perhaps due to a second submit, refresh, or
unexpected post
data.);
return null;
}
}
I have this code in my execute method. The request won't have a token unless
it is a form submission. Therefore, I think I can safely get away with this
code.
Is this true? I believe using tokens is the preferred way to handle
duplicate form submits.
My strong opinion is that webapp should not have Do you want to
resubmit POSTDATA? situations. You can get into resubmit in one of
the following cases:
* reloading result page using Refresh/Reload browser button (explicit
page reload, implicit resubmit of request);
* clicking Back and then Forward browser buttons (implicit page reload
and implicit resubmit of request);
* returning back to HTML FORM after submission, and clicking Submit
button on the form again (explicit resubmit of request)
* quickly submitting page again, before it was replaced in browser by
a response page.
The first two issues can be solved, if you redirect from action to
JSP, instead of forwarding from action to JSP. The last one can be
solved with immediate disabling submit button after submit, and with
locking resources on the server when request is received.
The third one, explicit resubmit, can be solved on domain model level.
Say, you submitted information like shopping cart, for the first time.
You lock the cart on the server, process it, and then dispose it. The
user goes back, tries to submit the same cart, but oops! the cart was
already processed and disposed, so you just show explanatory message.
No tokens.
Even better, if your pages are non-cachable and are always reflect
server state, then when a user goes back, browser tries to reload
shopping cart, but it was already disposed. Then you show error page
or starting page, whatever you like. Again, no harm done and no
tokens.
Tokens are pure web framework solution. They do not know about your
domain model. But you do, so use this knowledge. With good domain
model tokens are not needed, and you will be able to build more robust
and user-friendly application.
If interested, read more here:
http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost
http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost2
Best regards,
Michael Jouravlev.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Using checkbox value in Validator validwhen test
Problem: I don't know how to test a checkbox setting in the validwhen test var-value. I have a checkbox and a text field. I only need to validate the text field when the checkbox is checked. I cannot get this to work using validwhen (other validwhens do work that use different types of tests). It always requires the text field value be supplied regardless of the checkbox setting. The checkbox sets the options.EMailConfig.enabled property (The enabled field in the code does have a getter - isEnabled()). Here is the xml I've tried: field property=options.EMailConfig.primaryServer depends=validwhen arg0 key=AlertsOptions.EMAIL_PRIMARY/ var var-nametest/var-name var-value((options.EMailConfig.enabled == null) or (*this* != null))/var-value /var /field I've also tried !options.EMailConfig.enabled for and it also fails. Thanks.
RE: JSF vs Struts
Hi, I was trying to find which would be best choice for a website development. JSF or Struts. JSF looks similar to Struts. does any one know any articles on which framework should go for. Thanks - Do you Yahoo!? Yahoo! Small Business - Try our new resources site!
Re: Using checkbox value in Validator validwhen test
It is a classic. Look on Ted Husted's website for tip. Basically, you need to clear checkbox value each time in the reset() method of a form bean, because cleared value is not sent to server. So you think that you cleared it, but it is still set (do you use session-scoped form bean?) Michael Jouravlev. On 4/19/05, Dornback, Ken [EMAIL PROTECTED] wrote: Problem: I don't know how to test a checkbox setting in the validwhen test var-value. I have a checkbox and a text field. I only need to validate the text field when the checkbox is checked. I cannot get this to work using validwhen (other validwhens do work that use different types of tests). It always requires the text field value be supplied regardless of the checkbox setting. The checkbox sets the options.EMailConfig.enabled property (The enabled field in the code does have a getter - isEnabled()). Here is the xml I've tried: field property=options.EMailConfig.primaryServer depends=validwhen arg0 key=AlertsOptions.EMAIL_PRIMARY/ var var-nametest/var-name var-value((options.EMailConfig.enabled == null) or (*this* != null))/var-value /var /field I've also tried !options.EMailConfig.enabled for and it also fails. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
i18n best practices
I am wondering about best practices in struts for internationalization of dates and numbers. Formatting is not too hard, but parsing and validation is trickier. We must simultaneously handle different formats for different users, so any validation or parsing has to take into account the user's locale. Date formats include mm/dd/ and dd/mm/. Number formats include 12,345.6 and 12.345,6 (these are US and German respectively). Also, for some things, like money, we want to enforce a fixed number of decimal places while other numbers should display however many decimal places they have. Some numbers are internal-use integers (always hidden) that should not be formatted. Examples or tutorials would be very appreciated. Thanks, Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSF vs Struts
Take a look at http://www.jsfcentral.com/reading/index.html . There are several links there to articles or blogs that attempt to help you compare the two. Hubert On 4/19/05, Murali [EMAIL PROTECTED] wrote: Hi, I was trying to find which would be best choice for a website development. JSF or Struts. JSF looks similar to Struts. does any one know any articles on which framework should go for. Thanks - Do you Yahoo!? Yahoo! Small Business - Try our new resources site! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
showing data
Hi folks. I have a problem. i don't really know how to do that.. i have a jsp it shows a list of customers. but for each costumer there is a link to another jsp called detail. my problem is i don't know how to connect both jsp. i populate the list jsp with my actionform. that's ok. but if the user clicks on a specific customer... how to send that customer to detail jsp in order to show data about this customer??.. If u have some code to review, i would thank u. -- Rafael Taboada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: showing data
On 4/19/05, Rafael Taboada [EMAIL PROTECTED] wrote: Hi folks. I have a problem. i don't really know how to do that.. i have a jsp it shows a list of customers. but for each costumer there is a link to another jsp called detail. my problem is i don't know how to connect both jsp. i populate the list jsp with my actionform. that's ok. but if the user clicks on a specific customer... how to send that customer to detail jsp in order to show data about this customer??.. Something like this: !-- Show item list -- logic:iterate id=item name=itemListForm property=itemList type=com.acme.business.BusinessObj tr tdbean:write name=item property=id//td tdbean:write name=item property=value//td !-- Edit Item -- td html:link page=/editItem.do paramId=id paramName=item paramProperty=idEdit/html:link /td /tr /logic:iterate html:link will create a link with query parameter id=..., so it will look like editItem.do?id=1234. It is not recommended (see Ted Husted's tips) to process request directly by JSP, better to pass it through action class, as shown here. But there are exceptions from each rule. If u have some code to review, i would thank u. As a matter of fact, I do: http://www.theserverside.com/articles/article.tss?l=RedirectAfterPost2 http://www.superinterface.com/files/prgpattern.zip Michael Jouravlev. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Inheritance using multiple validator.xml
Here's what I am trying to do: I need to use a default validator.xml file to configure validations for fields on forms. I also want to be able to specify another custom validator xml file, say validator-custom.xml which contain changes to the validations of some fields. When I do this using pathname while configuring the validator plugin field validations from the default validator.xml file are not inherited for the same form. Here's a simple example, Default validator.xml file contains: form-validation formset form name=emailForm field property=email depends=required msg name=email key=errors.invalid/ arg0 key=emailForm.label.email/ /field field property=test depends=required msg name=test key=errors.required/ arg0 key=emailForm.label.test/ /field /form /formset /form-validation validator-custom.xml contains: form-validation formset form name=emailForm field property=email depends=required,email msg name=email key=errors.invalid/ arg0 key=emailForm.label.email/ /field /form /formset /form-validation Tha behavior I want is for the validator to use the validation for the test field defined in the default validator.xml and to use the validation for the email field from validator-custom.xml. What is happening is that the validation for the test field is not used at all, since both the forms are the same emailForm. I needed this behavior to be able to specify default field validations for the base product and then allow the ability to customize them for a specific scenario without copying and changing the validator.xml file itself. Is there any way to accomplish this? Any help is much appreciated. thanks Anand Narayan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSF vs Struts
Well, that's just about the most dangerous question to ask around these parts lately :) But in the end, the answer is what it should be for any vs. choice... examine them both, play with them, understand them, and then make the decision that fits your needs the best. Neither is going away any time soon, so you are safe there. Just DON'T give in to the hype on *either* side. Certainly you should read others' opinions, but don't make your decision based on them. Spend some time getting to know both options and make up your own mind. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com Murali wrote: Hi, I was trying to find which would be best choice for a website development. JSF or Struts. JSF looks similar to Struts. does any one know any articles on which framework should go for. Thanks - Do you Yahoo!? Yahoo! Small Business - Try our new resources site! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JSF vs Struts
On 4/19/05, Murali [EMAIL PROTECTED] wrote: Hi, I was trying to find which would be best choice for a website development. JSF or Struts. JSF looks similar to Struts. does any one know any articles on which framework should go for. If you don't have experience with either, than one of the possible answers may be neither ;-) Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Perhaps I'm missing the simplicity of your proposal. Let's take the example
from your original RFC. Here it is, for convenience:
In the JSP page:
html:button property=button1 value=Click to do Ajax!
ajaxRef=button1/
In the Ajax config file:
AjaxConfig
ajaxElement
idbutton1/id
event
typeonClick/type
submitTypequeryString/submitType
submitItemsbuttonValue=button1,textValue=text1/submitItems
submitTargethttp://www.omnytex.com/submitTarget
returnActionstdInnerHTML/returnAction
returnTargetsresultLayer/returnTargets
/event
/ajaxElement
/AjaxConfig
Now let's look at the equivalent if I use the existing Struts HTML tags and
Dojo.
In the JSP page:
html: button property=button1 value=Click to do Ajax!
onclick=doButton1()/
Elsewhere in the JSP page, or maybe somewhere else:
function doButton1() {
dojo.io.bind({
url: http://www.omnytex.com?buttonValue=button1textValue=text1;,
load: function(type, data) {
document.getElementById(resultLayer).innerHTML = data; },
mimetype: text/plain
});
}
That's all there is to it.
Perhaps for XML-heads, your proposal is easier to deal with. But you still
need to understand how the URL is constructed from the different pieces and
what things like 'stdInnerHTML' mean, not to mention the fun of having
generated JavaScript to debug your problems through, rather than a simple
function call that you wrote yourself.
Personally, I think I'll stick with the simpler (to me, anyway) Dojo
solution. :-)
By the way, while Dojo's goals extend far beyond just dojo.io.bind, one of
the great things about it is that you can just pick up the pieces that you
want. So if all you want is Ajax-like functionality, that's all you need to
include. But if you want a full-blown client side framework, widgets and
all, you can get that too. (Or at least you will when it's done. ;)
--
Martin Cooper
Frank W. Zammetti [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On Tue, April 19, 2005 12:53 am, Martin Cooper said:
To get beyond doing the grunt work yourself for Ajax, I recommend taking
a
look at this:
http://dojotoolkit.org/intro_to_dojo_io.html
and downloading the dojo.io package from their site.
It does look cool. However, in some ways what I provided is actually
better... I have the concept of default return handlers (and default
submission handlers) that would save the developer, in some percentage of
situations at least, from writing ANY server-side code whatsoever. True
enough, one could implement that concept with Dojo too, but then I'm just
helping develop Dojo!
Personally, I'm not convinced that we need anything new in Struts to
make
using Ajax easier.
Easier for who? For you? You are a super-genius Martin :) It's a
cakewalk for you. For me too frankly. *I* certainly don't need new tags
because I don't even use the tags as they are now 95% of the time!
Let's look at it this way... I don't consider the validation framework to
be any great shakes. I mean, the client-side portion of it anyway. I
don't need tags that can write validation logic for me. I suspect you
don't need it either. Was it a bad idea then? Most certainly not! Same
thing here... if we can provide to 80% of the people a capability that
requires so very little extra work for them (a single config file and a
single attribute on any tag involved) that will handle 80% of their needs,
why in the world wouldn't we jump at the chance?
I'm building products today that make extensive use of
the two technologies together, and haven't found a need to enhance
Struts
to
do it.
You and I both :)
However, if we do add any Ajax (or Ajax-like) support to Struts, I
want to be able to plug in my plumbing of choice (which would be Dojo
right
now) to get the most robust communication scheme available.
And that is a reasonable point I feel. But, then you get into a situation
where you have to build something more complex in all probability to
provide that degree of flexibility... I have to make sure it is generic
enough to handle any plumbing you want to put in, and then what happens
when some new plumbing comes down the pipe that doesn't quite fit?
I would rather take the tact here is an available method to do this AJAX
stuff, here are the limitations, and when you bump up against them you
will have to use something else. I just don't see that as a bad thing
because it helps some people now, as opposed to helping no one, or more
precisely, leaving them out to entirely help themselves.
P.S. - Take a look at my proposal again... If you really wanted to use
Dojo, I believe you could with just one minor change: I would have to
allow for calling custom functions when submitting to the server. This
was on the slate anyway, and that means you could use your dojo.io.bind()
stuff here).
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Tue, April 19, 2005 2:47 am, Craig McClanahan said: This is exactly the area I've been having trouble with this proposal as well ... tell me again why you can't use Ajax techniques with the standard Struts HTML tags? No one, at least not me, has made that statement at any point. I frankly do not use the Struts tags most of the time, yet I do AJAX just fine. There is no debate on this point: there is no NEED for the Struts HTML tags to do AJAX. If you can do it with handwritten HTML pages (which you certainly can), you can also do it with existing Struts HTML tags (or the standard JSF components, for that matter) that offer attributes like onchange and onclick to plug in your calls to JavaScript methods that do the actual background calls, and then update the client side DOM of your page. Agreed. But then you have to do everything yourself. If 80% of the time people are doing the same kinds of things like replacing the content of a specific DOM elements' innerHTML, why not provide a standard approach to that? I just posted an example of how you would handle your example using Dojo. The do everything yourself can be much easier than you might think. Further, we are constantly talking about the dichotomy of having a separate group of page developers and back-end developers. Why should a page developer need to know Javascript? Isn't that like saying they need to know Java on the server? You could of course make the argument that scripting is appropriately a part of a page developers' reportoire, and I don't think I would argue, but they already avoid a great deal of scripting by using various taglibs, so why shouldn't they want to avoid scripting to implement at least basic AJAX techniques? That is what is at the heart of what I did. It seems to me that a framework can provide value add in primarily the following areas: See, when we start talking about a framework we are starting to talk about something more grandiose than what I put together. That is in no way to say it isn't a good idea, just that it is different. * Provide a client side JavaScript library that does the grunt work of making the back-end XmlHttpRequest call, and updating the corresponding portion of your DOM. Martin likes DOJO for this; there are also a bunch of other libraries that do the same sort of thing that should be leveraged, instead of inventing something new. Not everyone likes throwing the kitchen sink into their projects to provide a relatively small amount of functionality. Where's the kitchen sink in the dojo.io.bind package? It's lean and mean and robust. It does one thing, and does it very well. It is amazing to me that anyone would make the argument against something that is too simple! Why do we always have to develop the next big thing rather than something that will help 80% of the people 80% of the time? Why is the later a seemingly Bad Thing? * Provide a server side framework that makes it easy to map a particular XHR invocation to the corresponding business logic, and (for extra credit) maps the response data to a generic data format so you don't have to write specific formatting logic for every single response type. I sort of like what JSON provides as a transport protocol, but there's room for value add here on the server side, with a generic data abstraction that maps into the appropriate transport formats. I do actually like this idea, but again, the difference between this and what I put together is night and day... this is leading down a much more complex and expansive path. It's a path I would be excited to walk down, but it puts delivered results further away as opposed to what I did that could be completed in relatively short order and help people NOW. Also, what you are talking about, and what Martin has been talking about, while a good idea to be sure, doesn't really help people with existing apps. Huh? You can take any existing Struts app today, add in Dojo, and make Ajax-like invocations wherever you like. No other changes necessary. It is akin to my Struts Web Services project... I have never at any time promoted that as the be-all and end-all of Web Services. What I have said is that if you have an existing Strtus-based application and need to expose parts of it as Web Services, here's one quick and easy way to do it. Likewise, what I proposed is a quick and easy way to introduce AJAX functionality into an existing app with a minimum of fuss and muss. There is not a lot of code to write (none if I do it right) and it's not an all-or-nothing proposition, you don't have to use a whole new framework on the client and the server to make it work. The what you and Martin are talking about, I can't see how that would be the case. So, while the ideas may have a great deal of merit,
Re: showing data
yeap. i have that... But i want to know what i have to do in the detail jsp. I mean, how can i populate in the detail jsp using that id. i have an lstCustomer object in my actionform. when i'm in detail jsp, is it still populated? or it depends on the scope?. thanks -- Rafael Taboada - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Martin Cooper wrote:
Perhaps I'm missing the simplicity of your proposal. Let's take the example
from your original RFC. Here it is, for convenience:
snip
Now let's look at the equivalent if I use the existing Struts HTML tags and
Dojo.
In the JSP page:
html: button property=button1 value=Click to do Ajax!
onclick=doButton1()/
Elsewhere in the JSP page, or maybe somewhere else:
function doButton1() {
dojo.io.bind({
url: http://www.omnytex.com?buttonValue=button1textValue=text1;,
load: function(type, data) {
document.getElementById(resultLayer).innerHTML = data; },
mimetype: text/plain
});
}
That's all there is to it.
My approach is more declarative, that's where it is simpler: less
code=simpler, as a generality. Kind of ironic to me that you would be
advocating MORE code in a page... isn't that the whole point of a taglib
in the first place? Isn't that why we all agree scriplets are Evil
Incarnate?
What you demonstrate here I would also argue is worse for page authors,
who now have to be concerned with script writing as well as layout of
simple HTML tags. You can argue that a page author would know
Javascript as well, and you may be right in most cases, but the idea
that everyone seems to be pushing is that the page authors should really
be glorified graphics artists who just do markup and worry about layout,
not code. That doesn't jive, to me at least, with the example you post.
Also in your example you are explicitly constructing the query string...
my tags do that for you. I presume you could dynamically create it with
Dojo as well, but then your talking about more code. Plus, we're
talking a bunch of inline code which, to my eyes, is very ugly, in much
the same way anonymous inner classes are in Swing coding.
Come to think of it, at first glance I'm not even sure I understand what
is going on in that code! I don't recall ever having seem Javascript
done that way, which immediately makes me think twice about this... it's
going to be harder to find someone that understand such code than more
straight-forward Javascript. I'm sure if I spent two minutes on it I'd
get it no problem (looks like a bunch of nested functions, akin to
anonymous inner classes in a sense... ugh!)
Perhaps for XML-heads, your proposal is easier to deal with. But you still
need to understand how the URL is constructed from the different pieces and
what things like 'stdInnerHTML' mean, not to mention the fun of having
generated JavaScript to debug your problems through, rather than a simple
function call that you wrote yourself.
Yes, those that prefer a declarative approach will like mine better, but
isn't that the direction Struts has been moving for years?
DynaActionForms, validation, and so on? All of this requires MORE XML,
not less. Why would it be any different here?
Also, I'm not sure what you mean about ...need to understand how the
URL is constructed... in fact, all you need to be aware of is what
fields in your form you wish to be on the query string, beyond that you
have no care at all about it. I didn't get around to implementing the
simple XML generator, but the same would be true there. You are simply
naming the elements you wish to be submitted, and what key to place them
under. I would argue that anyone that knows what an HTML form is would
have no problem picking this up.
As far as generated Javascript goes, the same holds true for using
someone else' library... What if Dojo isn't working for some reason?
Whether the script is generated on-the-fly or part of some external .js
file I didn't write, either way I have code to debug that I didn't
write. What's the difference? Heck, the same holds true if something
in Struts isn't working right! What happens when the script emitted by
the validation framework doesn't work quite right? It's the same
hassle, but your OK with that I presume? :)
Fair point about the stdInnerHTML thing, but that's just a part of the
learning curve that goes along with any new technology. What the hell
does the parameter attribute of an Action mapping have to do with using
a DispatchAction? Doesn't make much sense at first glance, but you have
to do a little learning then it's crystal clear. Same thing here.
Personally, I think I'll stick with the simpler (to me, anyway) Dojo
solution. :-)
By all means! :) I never was trying to push this as the One True Ajax
Approach, and I believe I said that during the original RFC thread.
There are undoubtedly many ways to go about this, and I would be foolish
to assume I was proposing the best. I *DO* however still believe my
approach has merits that others may not.
By the way, while Dojo's goals extend far beyond just dojo.io.bind, one of
the great things about it is that you can just pick up the pieces that you
want. So if all you want is Ajax-like functionality, that's all you need to
include. But if you want a full-blown client side framework,
Re: showing data
On 4/19/05, Rafael Taboada [EMAIL PROTECTED] wrote: yeap. i have that... But i want to know what i have to do in the detail jsp. I mean, how can i populate in the detail jsp using that id. i have an lstCustomer object in my actionform. when i'm in detail jsp, is it still populated? or it depends on the scope?. You either have to write a scriptlet, or to go through action. The latter is the recommended approach. On the other hand, because all you need is to load data from database and to show it, you can stick it in validate() method of output form bean, and use standard ForwardAction instead of creating custom action class. This may not look like by book coding, but it works: request goes through Struts, which is good, and you save on one class, which is good to. If you cannot load data from database, you create error message right away, you are already in validate() method. In the action class you would load data from database, corresponding to item ID, and fill out item form bean. Then you forward to JSP, which would show fields from your form bean: %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % %@ taglib uri=/WEB-INF/struts-html.tld prefix=html % html:html locale=true !-- Show item: ID and value -- ID:nbsp;bean:write name=itemFormOutput property=id/br Value:nbsp;bean:write name=itemFormOutput property=value/ /html:html Don't forget to define form bean in struts-config.xml I prefer to use separate actions and form beans for input and for output. See this article: http://www.theserverside.com/articles/article.tss?l=StrutsActionMapping I like Two actions, two forms approach. If you decide to use it with redirection, please read the discussion for the article, where I explain how do I handle error messages. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Martin Cooper wrote: * Provide a client side JavaScript library that does the grunt work of making the back-end XmlHttpRequest call, and updating the corresponding portion of your DOM. Martin likes DOJO for this; there are also a bunch of other libraries that do the same sort of thing that should be leveraged, instead of inventing something new. Not everyone likes throwing the kitchen sink into their projects to provide a relatively small amount of functionality. Where's the kitchen sink in the dojo.io.bind package? It's lean and mean and robust. It does one thing, and does it very well. I was referring to Craig's bullet point there, not specifically Dojo. I'd have to look at it more before I would say the same about it, and maybe I'd come to the same conclusion you have in the end. Huh? You can take any existing Struts app today, add in Dojo, and make Ajax-like invocations wherever you like. No other changes necessary. But it requires adding CODE. That to me is an intrusive way to go about it. If it is possible to simple add the capability to the tags that are ALREADY ON THE PAGES, backed by a little XML, that is far less intrusive in my mind than having to add a bunch of code, and if you go the Dojo route, hand-crafted code. I disagree, at least with respect to what _I_ am talking about. ;-) See my other post. Fair enough. We have a difference of opinion here. Nothing wrong with that. If I was presenting this as the way everyone should do things, then it would be a problem, but that has never been my tact on it. I would hope you are not presenting Dojo as the way everyone should do things either Martin :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Dispatch Action Whitespace In Label Text and Missing Parameters
I've run into a strange problem with DispatchAction occasionally failing to find the parameter used to lookup the method to process the request. I get the following familiar error: Request[myAction] does not contain handler parameter named 'method'. This may be caused by whitespace in the label text. This error may occur one time out of five for the exact same workflow and values, so the action doesn't fail every time. Here's more information about the error: -) Seems to be IE-specific. Testing with Firefox doesn't cause the error. -) There is no Javascript submitting the form. -) There is only one form on the page. -) The user clicks the submit button to submit the form, instead of pressing enter. -) All of the HTTP parameters are gone, which explains why the 'method' parameter is missing. -) There are a handful of filters in the web application. Since the error doesn't occur each time, I don't think the filters cause the error. I've exhausted my other resources to find the cause of this problem. I'm stumped. Does anybody have suggestions? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dispatch Action Whitespace In Label Text and Missing Parameters
1) You checked that button value does not contain whitespaces? By the way, cannot action strip whitespaces itself? It even generates error message about this! Stupido. A method cannot contain spaces anyway. 2) Get HTTP sniffer or use Firefox and Live HTTP Header plugin. Oh, you say it is IE-specific. All I know, that IE often tries to be nice. For example, if you stick value into edit box, IE strips out spaces and newlines. Maybe it related somehow. Maybe your value actually DOES contain spaces, and IE sometime strips them out, but sometimes don't (hm, why?). Michael. On 4/19/05, Nick Heudecker [EMAIL PROTECTED] wrote: I've run into a strange problem with DispatchAction occasionally failing to find the parameter used to lookup the method to process the request. I get the following familiar error: Request[myAction] does not contain handler parameter named 'method'. This may be caused by whitespace in the label text. This error may occur one time out of five for the exact same workflow and values, so the action doesn't fail every time. Here's more information about the error: -) Seems to be IE-specific. Testing with Firefox doesn't cause the error. -) There is no Javascript submitting the form. -) There is only one form on the page. -) The user clicks the submit button to submit the form, instead of pressing enter. -) All of the HTTP parameters are gone, which explains why the 'method' parameter is missing. -) There are a handful of filters in the web application. Since the error doesn't occur each time, I don't think the filters cause the error. I've exhausted my other resources to find the cause of this problem. I'm stumped. Does anybody have suggestions? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Martin Cooper wrote:
Perhaps I'm missing the simplicity of your proposal. Let's take the
example
from your original RFC. Here it is, for convenience:
snip
Now let's look at the equivalent if I use the existing Struts HTML tags
and
Dojo.
In the JSP page:
html: button property=button1 value=Click to do Ajax!
onclick=doButton1()/
Elsewhere in the JSP page, or maybe somewhere else:
function doButton1() {
dojo.io.bind({
url: http://www.omnytex.com?buttonValue=button1textValue=text1;,
load: function(type, data) {
document.getElementById(resultLayer).innerHTML = data; },
mimetype: text/plain
});
}
That's all there is to it.
My approach is more declarative, that's where it is simpler: less
code=simpler, as a generality. Kind of ironic to me that you would be
advocating MORE code in a page... isn't that the whole point of a taglib
in the first place? Isn't that why we all agree scriplets are Evil
Incarnate?
That's why I said or maybe somewhere else. It would be perfectly fine to
put the JavaScript functions in a separate .js file and linked to from the
page. And neither of us are talking scriptlets here. ;-)
What you demonstrate here I would also argue is worse for page authors,
who now have to be concerned with script writing as well as layout of
simple HTML tags. You can argue that a page author would know
Javascript as well, and you may be right in most cases, but the idea
that everyone seems to be pushing is that the page authors should really
be glorified graphics artists who just do markup and worry about layout,
not code. That doesn't jive, to me at least, with the example you post.
Again, move the JavaScript out to a separate file. That's essentially all
you've done with your Ajax config file, other than using a new XML syntax
for it. Now the only difference between your JSP page and mine is that yours
uses customised tags while mine doesn't need them. ;-)
Also in your example you are explicitly constructing the query string...
my tags do that for you. I presume you could dynamically create it with
Dojo as well, but then your talking about more code. Plus, we're
talking a bunch of inline code which, to my eyes, is very ugly, in much
the same way anonymous inner classes are in Swing coding.
Well, at least going from your example, your construction is little more
than string concatenation. I don't think you're saving much.
Come to think of it, at first glance I'm not even sure I understand what
is going on in that code! I don't recall ever having seem Javascript
done that way, which immediately makes me think twice about this... it's
going to be harder to find someone that understand such code than more
straight-forward Javascript. I'm sure if I spent two minutes on it I'd
get it no problem (looks like a bunch of nested functions, akin to
anonymous inner classes in a sense... ugh!)
Hmm, perhaps we're used to different JavaScript. That's pretty normal stuff
to me. Certainly nothing unusual.
Perhaps for XML-heads, your proposal is easier to deal with. But you
still
need to understand how the URL is constructed from the different pieces
and
what things like 'stdInnerHTML' mean, not to mention the fun of having
generated JavaScript to debug your problems through, rather than a
simple
function call that you wrote yourself.
Yes, those that prefer a declarative approach will like mine better, but
isn't that the direction Struts has been moving for years?
DynaActionForms, validation, and so on? All of this requires MORE XML,
not less. Why would it be any different here?
Going from writing ActionForm classes to dyna beans defined in XML saves you
a lot of tedious coding. In contrast, this lets you use a *more* verbose
syntax to say the same thing. I don't see the advantage. Moreover, if you
move the JavaScript code into a separate file, you actually save in clarity
and maintainability, at least IMHO.
Also, I'm not sure what you mean about ...need to understand how the
URL is constructed... in fact, all you need to be aware of is what
fields in your form you wish to be on the query string, beyond that you
have no care at all about it. I didn't get around to implementing the
simple XML generator, but the same would be true there. You are simply
naming the elements you wish to be submitted, and what key to place them
under. I would argue that anyone that knows what an HTML form is would
have no problem picking this up.
And my point is that anyone who knows what an HTML form is would wonder why
they had to use this new syntax for specifying the URL, instead of just
writing the URL in the first place.
As far as generated Javascript goes, the same holds true for using
someone else' library... What if Dojo isn't working for some reason?
Whether the script is generated on-the-fly or part of some
RE: Using checkbox value in Validator validwhen test
Yes, it is cleared in the reset method of the session-scoped bean. I'm pretty methodical about that. Is my syntax ok? Ken -Original Message- From: Michael J. [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 19, 2005 4:33 PM To: Struts Users Mailing List Subject: Re: Using checkbox value in Validator validwhen test It is a classic. Look on Ted Husted's website for tip. Basically, you need to clear checkbox value each time in the reset() method of a form bean, because cleared value is not sent to server. So you think that you cleared it, but it is still set (do you use session-scoped form bean?) Michael Jouravlev. On 4/19/05, Dornback, Ken [EMAIL PROTECTED] wrote: Problem: I don't know how to test a checkbox setting in the validwhen test var-value. I have a checkbox and a text field. I only need to validate the text field when the checkbox is checked. I cannot get this to work using validwhen (other validwhens do work that use different types of tests). It always requires the text field value be supplied regardless of the checkbox setting. The checkbox sets the options.EMailConfig.enabled property (The enabled field in the code does have a getter - isEnabled()). Here is the xml I've tried: field property=options.EMailConfig.primaryServer depends=validwhen arg0 key=AlertsOptions.EMAIL_PRIMARY/ var var-nametest/var-name var-value((options.EMailConfig.enabled == null) or (*this* != null))/var-value /var /field I've also tried !options.EMailConfig.enabled for and it also fails. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Martin Cooper wrote: * Provide a client side JavaScript library that does the grunt work of making the back-end XmlHttpRequest call, and updating the corresponding portion of your DOM. Martin likes DOJO for this; there are also a bunch of other libraries that do the same sort of thing that should be leveraged, instead of inventing something new. Not everyone likes throwing the kitchen sink into their projects to provide a relatively small amount of functionality. Where's the kitchen sink in the dojo.io.bind package? It's lean and mean and robust. It does one thing, and does it very well. I was referring to Craig's bullet point there, not specifically Dojo. I'd have to look at it more before I would say the same about it, and maybe I'd come to the same conclusion you have in the end. Huh? You can take any existing Struts app today, add in Dojo, and make Ajax-like invocations wherever you like. No other changes necessary. But it requires adding CODE. That to me is an intrusive way to go about it. If it is possible to simple add the capability to the tags that are ALREADY ON THE PAGES, backed by a little XML, that is far less intrusive in my mind than having to add a bunch of code, and if you go the Dojo route, hand-crafted code. My Huh? comment was in reference you your statement that the approach I was describing doesn't really help people with existing apps, which I take issue with. If you put the JavaScript methods in separate file, it has the exact same impact on the JSP pages as your approach does, but without needing the custom attributes. You say 'ajaxRef=button1' and I say 'onclick=doButton1()'. I disagree, at least with respect to what _I_ am talking about. ;-) See my other post. Fair enough. We have a difference of opinion here. Nothing wrong with that. If I was presenting this as the way everyone should do things, then it would be a problem, but that has never been my tact on it. I would hope you are not presenting Dojo as the way everyone should do things either Martin :) Let me think about that... ;-) ;-) -- Martin Cooper Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
html:text area
Hi, Can we restrict the length of textarea with any of the attributes? I have textarea that should not accept more than 250 characters, so I want to know if I can restrict the length with textarea attibutes. Thanks. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: AJAX: Whoa, Nellie!
What you demonstrate here I would also argue is worse for page authors, who now have to be concerned with script writing as well as layout of simple HTML tags. You can argue that a page author would know Javascript as well, and you may be right in most cases, but the idea that everyone seems to be pushing is that the page authors should really be glorified graphics artists who just do markup and worry about layout, not code. That doesn't jive, to me at least, with the example you post. +1. I agree with Frank's point of view over Martin's. Usually in a larger organization, you have to work with different groups of people with different roles i.e. page authors/UI experts. Page authors/UI experts don't have to know about scripting and just focus on page layouts or usabilities. If you are in a smaller organization where one person does it all, then that is fine. Frank's proposal adds great values in the organization I am working in. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: html:text area
On 4/19/05, Srilatha Salla [EMAIL PROTECTED] wrote: Hi, Can we restrict the length of textarea with any of the attributes? I have textarea that should not accept more than 250 characters, so I want to know if I can restrict the length with textarea attibutes. See: http://struts.apache.org/userGuide/struts-html.html#textarea There is no maxlength attribute simply because this one: http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.7 does not have it too. But I think that you can try to use client-side validator, see: http://www.manning-source.com/books/husted/husted_ch12.pdf Apparently, you would need to hook validator on onChange() or onKeyPress() event. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On 4/19/05, Shihgian Lee [EMAIL PROTECTED] wrote: What you demonstrate here I would also argue is worse for page authors, who now have to be concerned with script writing as well as layout of simple HTML tags. You can argue that a page author would know Javascript as well, and you may be right in most cases, but the idea that everyone seems to be pushing is that the page authors should really be glorified graphics artists who just do markup and worry about layout, not code. That doesn't jive, to me at least, with the example you post. +1. I agree with Frank's point of view over Martin's. Usually in a larger organization, you have to work with different groups of people with different roles i.e. page authors/UI experts. Page authors/UI experts don't have to know about scripting and just focus on page layouts or usabilities. If you are in a smaller organization where one person does it all, then that is fine. Frank's proposal adds great values in the organization I am working in. Glorified graphics artists do not do markup, they create nice mockups in Photoshop, which adore big bosses, who tell those unglofied ones to implement unearthy coolness in code. And those implementing this fancy stuff better know [at least about existence of] Javascript, XHTML, CSS, XML, DOM, XSLT, Flash and other buzzthings along with Photoshop. Those who do not know, create pages which look ok with single window and font size, at best. The separation between server-side programmers, Javascript coders and graphic artists is a wrong thing. Ok, the initial visual design is done by artist in Photoshop, but everyting else is programmed. Javascript is the same part of the toolbox, as Struts tags or JDBC. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Michael J. wrote: Glorified graphics artists do not do markup, they create nice mockups in Photoshop, which adore big bosses, who tell those unglofied ones to implement unearthy coolness in code. And those implementing this fancy stuff better know [at least about existence of] Javascript, XHTML, CSS, XML, DOM, XSLT, Flash and other buzzthings along with Photoshop. I don't argue that snowed-over bosses tend to tell those who do not get the glory yet do all the work to implement unearthly coolnes in code :) But, seriously, many environment have a high degree of separation, as Shihgian said. *I* don't happen to work in such an environment, we our a shop full of jacks of all trades, but even we are moving to the specialization end of the spectrum. In such a situation, there really is a very rigid set of requirements for each job. Page designers deal in CSS and HTML and that's it. They expect that any code that needs to go into a page will be inserted as a result of using the tags they are given. I personally can't imagine how that actually works, but I'm told it does in some places :) Those who do not know, create pages which look ok with single window and font size, at best. No question about that :) The separation between server-side programmers, Javascript coders and graphic artists is a wrong thing. Ok, the initial visual design is done by artist in Photoshop, but everyting else is programmed. Javascript is the same part of the toolbox, as Struts tags or JDBC. I don't think saying it is wrong is accurate... It is just an environment you are probably not used to. Some argue it is better that way and many say that's the way we should be moving. Not sure I agree, but some say that. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
