Re: Best practice for storing configuration data
Great, I like the idea of storing data inside the server.xml or using the admin tool... using the Environment tag... if you have access to the adminstration of the server unfortunately this doesn't work if you just have access to you context directory... From what I read on all the thread http://marc.theaimsgroup.com/?t=7687427r=1w=2 http://marc.theaimsgroup.com/?t=7687427r=1w=2 the only possibile solution is saving application data in the web.xml simone Erik Weber wrote: Related: http://www.mail-archive.com/user@struts.apache.org/msg24083.html Erik Simone - Dev wrote: Today I run into an dubt: is the way I always used to store application dependent configuration is correct? I use to store this kind of information in the we.xml file using context-param like this one context-param param-nameuploadedFilePath/param-name param-valueD:/Documenti/Progetti/jClubHouse/build/uploadedFiles//param-value descriptionThe path to save the uploadedFiles to/description /context-param and then inside actions, I retrieve it using String uploadDir=getServlet().getServletContext().getInitParameter(uploadedFilePath); is there a better practice or is this the right one? Simone - Simone Chiaretta www.piyosailing.com/S http://www.piyosailing.com/S /Any sufficiently advanced technology is indistinguishable from magic/ /Life is short, play hard/ http://www.spreadfirefox.com/?q=affiliatesid=2476t=81 - 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]
User Certificates and application managed security -- possible??
Hi, We have a customer who is introducing chip cards with client-certificates for single sign on. Because of this I have to change a web-application we provided. The application implements its own security mechanisms and uses roles (defined for every action in struts-config.xml) and roles in struts-menu to control access to offered functionalities. If I understand things correctly, to support client-certificates I need to define (beside SSL which is already supported) in my web.xml something like: login-config auth-methodCLIENT-CERT/auth-method /login-config What happens to users who DO NOT have a certificate? In my program code I would be able to present a login-page and perform a different (second) method of authentication. If I understand things right, the above tag FORCES users to present a certificate to Tomcat (or whatever server) and fails otherwise. How can this be solved? I should implement something like: Is a certificate there? If yes read it and continue in the web app. If not, open a login screen and allow a username / password authentication. Once the authentication was successful I read the roles from a database server and everything should work as it does now (without client certificates) Many thanks for your help Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: User Certificates and application managed security -- possibl e??
Hi With a newer Tomcat you might use a solution similar to what I have already seen in a WebLogic-installation: Several security-providers were created and configured. The first one to able to authenticate the user does the job. Therefor the first would be an authenticator that can handle the chipcard-certificates, afterwards you could define a standard handler that can handle a basic-authentication. This can also be done only for the developer's workstation. In your app you would then use just the J2EE-principal and roles. I think it should be possible from TC5 on upward hth Alexander -Original Message- From: Tom Bednarz [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 11:44 AM To: Struts Users Mailing List Subject: User Certificates and application managed security -- possible?? Hi, We have a customer who is introducing chip cards with client-certificates for single sign on. Because of this I have to change a web-application we provided. The application implements its own security mechanisms and uses roles (defined for every action in struts-config.xml) and roles in struts-menu to control access to offered functionalities. If I understand things correctly, to support client-certificates I need to define (beside SSL which is already supported) in my web.xml something like: login-config auth-methodCLIENT-CERT/auth-method /login-config What happens to users who DO NOT have a certificate? In my program code I would be able to present a login-page and perform a different (second) method of authentication. If I understand things right, the above tag FORCES users to present a certificate to Tomcat (or whatever server) and fails otherwise. How can this be solved? I should implement something like: Is a certificate there? If yes read it and continue in the web app. If not, open a login screen and allow a username / password authentication. Once the authentication was successful I read the roles from a database server and everything should work as it does now (without client certificates) Many thanks for your help Tom - 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]
[OT] Steps for Configuring WAS 5.0 Websphere MQ
The requirement is, I need a Message Driven Bean which will recieve messages from Websphere MQ. I am finding problems doing the configuration in WSAD as well as in WAS. Any pointers to Configuring for MDB - MQ in (1) WSAD 5.1 and (2) WAS 5.0 will be really helpful. Thanks in advance, Prasenjit Quinnox is a SEI-CMM; ISO 9001:2000 accredited Global IT Services company providing solutions in areas of E-Business, ERP, Application Management Services and EAI to customers in BFSI, Manufacturing, Retail, Telecom and Healthcare sector, powered by our Global Delivery Model. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Actions and Action Mappings instantiated once?
Hi When I create a struts-config.xml that has many nodes that call the same action class, is the action class instantietad once, or is instantiated for every node?. What happens if I have a custom action mapping class, is instantiated once or is instantiated for every node?. Regards, Néstor Boscán - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Use of frames and security softwares in browser
Hi all, I plan to use frames for a site where in the user will feel that he is one site while it will be pulling content from another site. Here my question is will any kind of security software installed in a browser will detect this and report to the user or prevent the content from being displayed ?. Does any such software exists ?. Then what will be the alternative ?. -- rgds Antony Paul http://www.geocities.com/antonypaul24/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
java.lang.IllegalArgumentException calling an Action
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(RequestProcessor.java:798) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205) 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(DelegatingMethodAccessorImpl.java:25) java.lang.reflect.Method.invoke(Method.java:324) org.apache.commons.beanutils.PropertyUtils.setSimpleProperty(PropertyUtils.java:1789) org.apache.commons.beanutils.PropertyUtils.setNestedProperty(PropertyUtils.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(RequestProcessor.java:798) org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:205) 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 ___
RE: Actions and Action Mappings instantiated once?
Hello, Nestor. I'm not sure what you mean exactly by node. Anyway, according to Struts' online doc: Write code for a multi-threaded environment - The controller servlet creates only one instance of your Action class, and uses this one instance to service all requests... Not sure if this is what you mean, though. Cheers, Freddy. -Mensaje original- De: Néstor Boscán [mailto:[EMAIL PROTECTED] Enviado el: lunes, 18 de abril de 2005 12:49 Para: 'Struts Users Mailing List' Asunto: Actions and Action Mappings instantiated once? Hi When I create a struts-config.xml that has many nodes that call the same action class, is the action class instantietad once, or is instantiated for every node?. What happens if I have a custom action mapping class, is instantiated once or is instantiated for every node?. Regards, Néstor Boscán - 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]
AJAX: Whoa, Nellie!
I have been taking another look at the AJAX stuff that Frank Zammetti has provided. This stuff is revolutionary. Someone ought to be taking a close look at integrating such solutions, so far as it makes sense, into Struts. This is not a passing fancy, in my estimation. This is a real solution to a persistent problem. Further, this moves the solution to where the problem exists, on the client. I, for one, am getting excited. I am not saying to be precipitous, so the usual mundane warnings can be kept aside. But, this is not the usual thing. This is a fundamental shift in architecture that makes clear sense. Jack -- 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!
Where do we find information about this marvellous stuff? Rodolfo __ Dakota Jack [EMAIL PROTECTED] 18/04/2005 15:02 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: AJAX: Whoa, Nellie! I have been taking another look at the AJAX stuff that Frank Zammetti has provided. This stuff is revolutionary. Someone ought to be taking a close look at integrating such solutions, so far as it makes sense, into Struts. This is not a passing fancy, in my estimation. This is a real solution to a persistent problem. Further, this moves the solution to where the problem exists, on the client. I, for one, am getting excited. I am not saying to be precipitous, so the usual mundane warnings can be kept aside. But, this is not the usual thing. This is a fundamental shift in architecture that makes clear sense. Jack -- 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: Actions and Action Mappings instantiated once?
At 6:48 AM -0400 4/18/05, Néstor Boscán wrote: Hi When I create a struts-config.xml that has many nodes that call the same action class, is the action class instantietad once, or is instantiated for every node?. What happens if I have a custom action mapping class, is instantiated once or is instantiated for every node?. Freddy pretty much answered you, but yes, by Struts original design, Action and ActionMapping classes are created once at Servlet initialization and are reused throughout. Note that if you use the wildcard action-mapping functionality added in Struts 1.2, then necessarily a new ActionMapping is created for each request, because part of the functionality is to populate values of the mapping based on the details of the match. (see http://struts.apache.org/userGuide/building_controller.html#action_mapping_wildcards) Several other MVC frameworks instantiate a controller (equivalent to a Struts Action) for each request, and in fact, the Spring Framework provides (among other ways) a way of integrating with Struts which results in a new Action class being created for each request (see http://www.springframework.org/docs/reference/webintegration.html#struts) If you didn't want to use Spring, it would still be relatively easy to extend the Struts RequestProcessor (or in Struts 1.3, extend or replace the CreateAction command) so that an Action was created for each request. 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: AJAX: Whoa, Nellie!
Dakota Jack a écrit : This is a fundamental shift in architecture that makes clear sense. I tend to agree with you, and if this were to be integrated in Struts, my life would be easier (I am using AJAX stuff in some parts of my webapp). However, I have a serious concern related to security : this is still JavaScript :-) -- Stéphane Zuckerman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Rodolfo García Esteban/CYII a écrit : Where do we find information about this marvellous stuff? Rodolfo __ Look for XMLHttpRequest and/or ActiveXObject(Microsoft.XMLHTTP) XML.com and the Apple dev center have good introductory articles about it. Basically, this is a way to make server call from JavaScript via the XMLHttpRequest (Safari/Gecko browsers) or XMLHTTP (Internet Explorer) objects. Thus it enables you to make dynamic calls to refresh some parts of a web page without reloading everything. This is used with gmail for instance. -- Stéphane Zuckerman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
http://wiki.apache.org/struts/AjaxStruts On 4/18/05, Rodolfo García Esteban/CYII [EMAIL PROTECTED] wrote: Where do we find information about this marvellous stuff? Rodolfo __ Dakota Jack [EMAIL PROTECTED] 18/04/2005 15:02 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: AJAX: Whoa, Nellie! I have been taking another look at the AJAX stuff that Frank Zammetti has provided. This stuff is revolutionary. Someone ought to be taking a close look at integrating such solutions, so far as it makes sense, into Struts. This is not a passing fancy, in my estimation. This is a real solution to a persistent problem. Further, this moves the solution to where the problem exists, on the client. I, for one, am getting excited. I am not saying to be precipitous, so the usual mundane warnings can be kept aside. But, this is not the usual thing. This is a fundamental shift in architecture that makes clear sense. Jack -- 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] -- 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!
http://wiki.apache.org/struts/AjaxStruts On 4/18/05, Stéphane Zuckerman [EMAIL PROTECTED] wrote: Rodolfo García Esteban/CYII a écrit : Where do we find information about this marvellous stuff? Rodolfo __ Look for XMLHttpRequest and/or ActiveXObject(Microsoft.XMLHTTP) XML.com and the Apple dev center have good introductory articles about it. Basically, this is a way to make server call from JavaScript via the XMLHttpRequest (Safari/Gecko browsers) or XMLHTTP (Internet Explorer) objects. Thus it enables you to make dynamic calls to refresh some parts of a web page without reloading everything. This is used with gmail for instance. -- Stéphane Zuckerman - 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!
Good overview, Stephane On 4/18/05, Stéphane Zuckerman [EMAIL PROTECTED] wrote: Rodolfo García Esteban/CYII a écrit : Where do we find information about this marvellous stuff? Rodolfo __ Look for XMLHttpRequest and/or ActiveXObject(Microsoft.XMLHTTP) XML.com and the Apple dev center have good introductory articles about it. Basically, this is a way to make server call from JavaScript via the XMLHttpRequest (Safari/Gecko browsers) or XMLHTTP (Internet Explorer) objects. Thus it enables you to make dynamic calls to refresh some parts of a web page without reloading everything. This is used with gmail for instance. -- Stéphane Zuckerman - 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!
For articles, blogs, libraries, etc, related to this technology, take a look at http://www.ajaxmatters.com/ Our own Frank wrote an article about using it on http://www.omnytex.com/articles/xhrstruts/ He also proposed integrating the technology with the Struts taglibs: http://marc.theaimsgroup.com/?t=11128162732r=3w=2 Hubert On 4/18/05, Rodolfo García Esteban/CYII [EMAIL PROTECTED] wrote: Where do we find information about this marvellous stuff? Rodolfo __ Dakota Jack [EMAIL PROTECTED] 18/04/2005 15:02 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: AJAX: Whoa, Nellie! I have been taking another look at the AJAX stuff that Frank Zammetti has provided. This stuff is revolutionary. Someone ought to be taking a close look at integrating such solutions, so far as it makes sense, into Struts. This is not a passing fancy, in my estimation. This is a real solution to a persistent problem. Further, this moves the solution to where the problem exists, on the client. I, for one, am getting excited. I am not saying to be precipitous, so the usual mundane warnings can be kept aside. But, this is not the usual thing. This is a fundamental shift in architecture that makes clear sense. Jack -- 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!
Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
eee... javascript... yuck, ptooey! ptooey!! --- Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
On 4/6 I posted the following message to the Struts dev list... I can't
seem to find the thread in the list archives, if anyone else can I would
appreciate very much you posting the link to it...
This was discussing my proposal for integrating AJAX functionality into
the existing Struts taglibs. There were some legitimate dissenting points
raised about this, and ultimately the idea was shot down. However, I
still feel the idea has significant merit.
The proposal wasn't posted to the user list, and maybe I should have done
so... if there is support for this in the user community, I would be
willing to persue it further and provide it as part of the SF Struts
project.
P.S., I've added some notes here for some things that may not be as clear
as I would have liked, especially if you aren't terribly familiar with the
Struts code base, so if you see minor difference between this and what is
in the archives, that's all it is...
Subject: RFC: Struts HTML Ajax-Aware Tags
Afternoon all,
Please reference the code at:
http://www.omnytex.com/ajaxtags.zip
This is a complete webapp demonstrating the proposal (it isn't complete,
it is just to get the ideas across).
I wanted to put something out there in front of you all and get some
feedback on it before I go that extra mile and finish it out.
This came out of some ideas I tossed at Ted a few days ago. The basic
idea is to take the existing Struts HTML taglib and make the tags
Ajax-aware.
In a nuthsell, take a simple button tag...
html:button property=button1 value=Click to do Ajax! /
...now, add a new attribute to it, ajaxRef:
html:button property=button1 value=Click to do Ajax!
ajaxRef=button1 /
When the tag is rendered, each possible type of event handler (in the
BaseTagHandler class) looks something like this now:
if (getOnclick() != null) {
handlers.append( onclick=\);
handlers.append(getOnclick());
handlers.append(\);
}
else {
prepareAjax(onclick, handlers);
}
prepareAjax() does a lookup to a new XML configuration file (well,
in-memory objects representing the XML of course!) like so:
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
If an ajaxElement with an id matching the ajaxRef attribute is found,
and if an event with a type matching the type being added to the tag
is found, then the prepareAjax() method does its thing (note that
developer-defined event handler functions will take precedent, so no
existing code would be broken by this). And what is its thing you ask?
Basically it will add an inline event handler to the tag, just like
always, that is capable of making an Ajax request (using the
XMLHttpRequest component). A quick description of the XML elements
pertaining to event should bring this in to focus:
type .. is of course the type of event handler. It can be any of the
types that the BaseHandlerTag handles.
submitType .. is the type of submission that will be made. Two types are
(will be) supported: queryString and XML.
submitItems .. is a comma-separated list of form elements and the names
they should be given. For instance, in the example above we would get a
query string in the form ?buttonValue=1textValue=2 where 1 is the
value of the button on the page and 2 is the value of the textbox on the
page.
submitTarget .. is the URL the request is submitted to. This can be a
relative path or a full URL (although full URLs will of course incur the
cross-site scripting restrictions)
returnAction .. is what will happen when the request returns. There will
be a number of built-in actions, all prefixed with std' (let's get all
the disease jokes out of the way now!). You can also name a page-level
Javascript function here to do other things.
returnTargets .. is a comma-separated list of elements on the page that
will be affected by the action. This will generally be required for the
standard actions, and is up to the developer if they want it if writing
their own function.
The code you hopefully downloaded is a sample webapp, very simple. Click
the button to retrieve the Struts web site and dump it in a span. Note
that if you are in an environment that requires a proxy for network
access, you will need to set the httpProxy and httpPort elements in
web.xml appropriately. It is by default set up assuming no proxy is
required.
The example has a number of quick-and-dirty type hacks just to
demonstrate... for one, the XML config file is NOT read in, instead the
objects are just populated manually in AjaxInit (which is a Struts plug-in
and is required to make the tags Ajax-aware). Second, the query string is
currently not actually built, it's just hard-coded. Third, only the
Re: AJAX: Whoa, Nellie!
ptooey... I've always wanted to know how to spell that :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 10:29 am, Woodchuck said: eee... javascript... yuck, ptooey! ptooey!! --- Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - 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,
You must've started typing this response a while ago. I already sent
a message on this thread linking to the dev email with your proposal.
Hubert
On 4/18/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
On 4/6 I posted the following message to the Struts dev list... I can't
seem to find the thread in the list archives, if anyone else can I would
appreciate very much you posting the link to it...
This was discussing my proposal for integrating AJAX functionality into
the existing Struts taglibs. There were some legitimate dissenting points
raised about this, and ultimately the idea was shot down. However, I
still feel the idea has significant merit.
The proposal wasn't posted to the user list, and maybe I should have done
so... if there is support for this in the user community, I would be
willing to persue it further and provide it as part of the SF Struts
project.
P.S., I've added some notes here for some things that may not be as clear
as I would have liked, especially if you aren't terribly familiar with the
Struts code base, so if you see minor difference between this and what is
in the archives, that's all it is...
Subject: RFC: Struts HTML Ajax-Aware Tags
Afternoon all,
Please reference the code at:
http://www.omnytex.com/ajaxtags.zip
This is a complete webapp demonstrating the proposal (it isn't complete,
it is just to get the ideas across).
I wanted to put something out there in front of you all and get some
feedback on it before I go that extra mile and finish it out.
This came out of some ideas I tossed at Ted a few days ago. The basic
idea is to take the existing Struts HTML taglib and make the tags
Ajax-aware.
In a nuthsell, take a simple button tag...
html:button property=button1 value=Click to do Ajax! /
...now, add a new attribute to it, ajaxRef:
html:button property=button1 value=Click to do Ajax!
ajaxRef=button1 /
When the tag is rendered, each possible type of event handler (in the
BaseTagHandler class) looks something like this now:
if (getOnclick() != null) {
handlers.append( onclick=\);
handlers.append(getOnclick());
handlers.append(\);
}
else {
prepareAjax(onclick, handlers);
}
prepareAjax() does a lookup to a new XML configuration file (well,
in-memory objects representing the XML of course!) like so:
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
If an ajaxElement with an id matching the ajaxRef attribute is found,
and if an event with a type matching the type being added to the tag
is found, then the prepareAjax() method does its thing (note that
developer-defined event handler functions will take precedent, so no
existing code would be broken by this). And what is its thing you ask?
Basically it will add an inline event handler to the tag, just like
always, that is capable of making an Ajax request (using the
XMLHttpRequest component). A quick description of the XML elements
pertaining to event should bring this in to focus:
type .. is of course the type of event handler. It can be any of the
types that the BaseHandlerTag handles.
submitType .. is the type of submission that will be made. Two types are
(will be) supported: queryString and XML.
submitItems .. is a comma-separated list of form elements and the names
they should be given. For instance, in the example above we would get a
query string in the form ?buttonValue=1textValue=2 where 1 is the
value of the button on the page and 2 is the value of the textbox on the
page.
submitTarget .. is the URL the request is submitted to. This can be a
relative path or a full URL (although full URLs will of course incur the
cross-site scripting restrictions)
returnAction .. is what will happen when the request returns. There will
be a number of built-in actions, all prefixed with std' (let's get all
the disease jokes out of the way now!). You can also name a page-level
Javascript function here to do other things.
returnTargets .. is a comma-separated list of elements on the page that
will be affected by the action. This will generally be required for the
standard actions, and is up to the developer if they want it if writing
their own function.
The code you hopefully downloaded is a sample webapp, very simple. Click
the button to retrieve the Struts web site and dump it in a span. Note
that if you are in an environment that requires a proxy for network
access, you will need to set the httpProxy and httpPort elements in
web.xml appropriately. It is by default set up assuming no proxy is
required.
The example has a number of
Re: AJAX: Whoa, Nellie!
Yep, sorry about that... I had it in my drafts folder because I got called
away in the middle of it, and I didn't check all the replies to the
current thread before sending it so I didn't see your link until
afterwards. My bad :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, April 18, 2005 10:41 am, Hubert Rabago said:
Frank,
You must've started typing this response a while ago. I already sent
a message on this thread linking to the dev email with your proposal.
Hubert
On 4/18/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
On 4/6 I posted the following message to the Struts dev list... I can't
seem to find the thread in the list archives, if anyone else can I would
appreciate very much you posting the link to it...
This was discussing my proposal for integrating AJAX functionality into
the existing Struts taglibs. There were some legitimate dissenting
points
raised about this, and ultimately the idea was shot down. However, I
still feel the idea has significant merit.
The proposal wasn't posted to the user list, and maybe I should have
done
so... if there is support for this in the user community, I would be
willing to persue it further and provide it as part of the SF Struts
project.
P.S., I've added some notes here for some things that may not be as
clear
as I would have liked, especially if you aren't terribly familiar with
the
Struts code base, so if you see minor difference between this and what
is
in the archives, that's all it is...
Subject: RFC: Struts HTML Ajax-Aware Tags
Afternoon all,
Please reference the code at:
http://www.omnytex.com/ajaxtags.zip
This is a complete webapp demonstrating the proposal (it isn't complete,
it is just to get the ideas across).
I wanted to put something out there in front of you all and get some
feedback on it before I go that extra mile and finish it out.
This came out of some ideas I tossed at Ted a few days ago. The basic
idea is to take the existing Struts HTML taglib and make the tags
Ajax-aware.
In a nuthsell, take a simple button tag...
html:button property=button1 value=Click to do Ajax! /
...now, add a new attribute to it, ajaxRef:
html:button property=button1 value=Click to do Ajax!
ajaxRef=button1 /
When the tag is rendered, each possible type of event handler (in the
BaseTagHandler class) looks something like this now:
if (getOnclick() != null) {
handlers.append( onclick=\);
handlers.append(getOnclick());
handlers.append(\);
}
else {
prepareAjax(onclick, handlers);
}
prepareAjax() does a lookup to a new XML configuration file (well,
in-memory objects representing the XML of course!) like so:
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
If an ajaxElement with an id matching the ajaxRef attribute is
found,
and if an event with a type matching the type being added to the tag
is found, then the prepareAjax() method does its thing (note that
developer-defined event handler functions will take precedent, so no
existing code would be broken by this). And what is its thing you
ask?
Basically it will add an inline event handler to the tag, just like
always, that is capable of making an Ajax request (using the
XMLHttpRequest component). A quick description of the XML elements
pertaining to event should bring this in to focus:
type .. is of course the type of event handler. It can be any of the
types that the BaseHandlerTag handles.
submitType .. is the type of submission that will be made. Two types
are
(will be) supported: queryString and XML.
submitItems .. is a comma-separated list of form elements and the names
they should be given. For instance, in the example above we would get a
query string in the form ?buttonValue=1textValue=2 where 1 is the
value of the button on the page and 2 is the value of the textbox on
the
page.
submitTarget .. is the URL the request is submitted to. This can be a
relative path or a full URL (although full URLs will of course incur the
cross-site scripting restrictions)
returnAction .. is what will happen when the request returns. There
will
be a number of built-in actions, all prefixed with std' (let's get all
the disease jokes out of the way now!). You can also name a page-level
Javascript function here to do other things.
returnTargets .. is a comma-separated list of elements on the page that
will be affected by the action. This will generally be required for the
standard actions, and is up to the developer if they want it if writing
their own function.
The code you
Re: AJAX: Whoa, Nellie!
JavaScript provides a client side rather developed engine in JavaScript as well as Flash, etc. This is merely a resource. The yuck, ptooey! ptooey response to these ideas, especially ones in production and successful for quite a while, strikes me as rather less than professional. I think it is interesting that JavaScript, which I have avoided like the plague, has kept building a market despite a lot of prejudice from people like myself, not to mention Woodchuck. ///;-) On 4/18/05, Woodchuck [EMAIL PROTECTED] wrote: eee... javascript... yuck, ptooey! ptooey!! --- Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - 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!
Let me first say that IMHO, introducing AJAX capabilities into the html taglib is an awesome idea. Frank W. Zammetti wrote: So, the question is, does anyone see this as something interesting? Very. I was also thinking about working on AJAX taglibs using Sarissa [1] (introductory article at [2]), but i was aiming for more than XMLHttpRequest, for example to allow XSLT transformations to be applied on the XML either the server or client, depending on what the browser supports. Is anyone interested in seeing this actually finished up? If so I can do that, probably by the weekend if things go well, and I suppose open a ticket for it at that point. I would happily help (although i have little time) and even donate the JS code under the ASL if wanted. Questions? Comments? Whatever? Thanks all! 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. [1] http://sarissa.sf.net/ [2] http://www.xml.com/pub/a/2005/02/23/sarissa.html Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
sorry, i couldn't resist . actually, why don't we address this problem at the source rather than using this javascript patch solution? (at least this is how i see it) why don't the browser makers build internal mechanisms to allow posting of forms without the need to refresh the html page? why don't we re-architect the browswer and address this problem (and others) at that fundamental level? is this not conceivable? woodchuck --- Dakota Jack [EMAIL PROTECTED] wrote: JavaScript provides a client side rather developed engine in JavaScript as well as Flash, etc. This is merely a resource. The yuck, ptooey! ptooey response to these ideas, especially ones in production and successful for quite a while, strikes me as rather less than professional. I think it is interesting that JavaScript, which I have avoided like the plague, has kept building a market despite a lot of prejudice from people like myself, not to mention Woodchuck. ///;-) On 4/18/05, Woodchuck [EMAIL PROTECTED] wrote: eee... javascript... yuck, ptooey! ptooey!! --- Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - 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] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
html:link and html:cancel
Hi all,
Is there a way to use html:link in a way that it acts like html:cancel, in
other words automatically skip validation?
This seems to work but I wonder if there is a better way?
jsp:useBean id=paramMap class=java.util.HashMap /
c:set target=${paramMap} property=org.apache.struts.taglib.html.CANCEL
value=cancel/
html-el:link action=${actionName} name=paramMap
Cancel
/html-el:link
Thanks,
Abdullah
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
Frank, will Ajax support be tied into reporting form errors? It would be interesting to break down the validator into individual validations, so errors can be reported to the user as he types. -Original Message- From: Emmanouil Batsis [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 11:12 AM To: Struts Users Mailing List; Dakota Jack Subject: Re: AJAX: Whoa, Nellie! Let me first say that IMHO, introducing AJAX capabilities into the html taglib is an awesome idea. Frank W. Zammetti wrote: So, the question is, does anyone see this as something interesting? Very. I was also thinking about working on AJAX taglibs using Sarissa [1] (introductory article at [2]), but i was aiming for more than XMLHttpRequest, for example to allow XSLT transformations to be applied on the XML either the server or client, depending on what the browser supports. Is anyone interested in seeing this actually finished up? If so I can do that, probably by the weekend if things go well, and I suppose open a ticket for it at that point. I would happily help (although i have little time) and even donate the JS code under the ASL if wanted. Questions? Comments? Whatever? Thanks all! 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. [1] http://sarissa.sf.net/ [2] http://www.xml.com/pub/a/2005/02/23/sarissa.html Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Not sure what to say, Woodchuck, about your suggestion that a request be sent that does not want a response and does not affect the HTML page. What would happen next? And, how? This is perfectly conceivable. Heck, I think that it might be possible as is. But, I don't see this as even addressing the problem that AJAX is so neato, keen on. Jack On 4/18/05, Woodchuck [EMAIL PROTECTED] wrote: sorry, i couldn't resist . actually, why don't we address this problem at the source rather than using this javascript patch solution? (at least this is how i see it) why don't the browser makers build internal mechanisms to allow posting of forms without the need to refresh the html page? why don't we re-architect the browswer and address this problem (and others) at that fundamental level? is this not conceivable? woodchuck --- Dakota Jack [EMAIL PROTECTED] wrote: JavaScript provides a client side rather developed engine in JavaScript as well as Flash, etc. This is merely a resource. The yuck, ptooey! ptooey response to these ideas, especially ones in production and successful for quite a while, strikes me as rather less than professional. I think it is interesting that JavaScript, which I have avoided like the plague, has kept building a market despite a lot of prejudice from people like myself, not to mention Woodchuck. ///;-) On 4/18/05, Woodchuck [EMAIL PROTECTED] wrote: eee... javascript... yuck, ptooey! ptooey!! --- Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - 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] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide -- 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!
No problemo. As far as the extension itself is concerned, I'd still
be interested in it, but like I mentioned earlier, only as a plugin
that doesn't change the base tags. The reasons are many and they are
mentioned in the dev thread you started. My main concern is
implementation lock-in. Another message in this thread already
illustrates that there could be several approaches to adding this
functionality. I wouldn't want to limit how everyone else applies the
technology. As Martin said, if an implementation is built into
Struts, it should support whatever client-side library the developer
would want to use (
http://marc.theaimsgroup.com/?l=struts-devm=111284722931074w=2 ). A
separate plugin wouldn't have to have that burden.
A separated plugin would result in code duplication, true, but in my
view it's worth it. In some aspects, the ajax-aware tags you propose
are in a better position than the EL tags. You only need to override
some methods, whose implementation can be moved to a util-type class.
EL had to add duplicate fields, getters, and setters. Just take a
look at the source of some of those tags, like ELCheckboxTag and
ELRadioTag.
Hubert
On 4/18/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Yep, sorry about that... I had it in my drafts folder because I got called
away in the middle of it, and I didn't check all the replies to the
current thread before sending it so I didn't see your link until
afterwards. My bad :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, April 18, 2005 10:41 am, Hubert Rabago said:
Frank,
You must've started typing this response a while ago. I already sent
a message on this thread linking to the dev email with your proposal.
Hubert
On 4/18/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
On 4/6 I posted the following message to the Struts dev list... I can't
seem to find the thread in the list archives, if anyone else can I would
appreciate very much you posting the link to it...
This was discussing my proposal for integrating AJAX functionality into
the existing Struts taglibs. There were some legitimate dissenting
points
raised about this, and ultimately the idea was shot down. However, I
still feel the idea has significant merit.
The proposal wasn't posted to the user list, and maybe I should have
done
so... if there is support for this in the user community, I would be
willing to persue it further and provide it as part of the SF Struts
project.
P.S., I've added some notes here for some things that may not be as
clear
as I would have liked, especially if you aren't terribly familiar with
the
Struts code base, so if you see minor difference between this and what
is
in the archives, that's all it is...
Subject: RFC: Struts HTML Ajax-Aware Tags
Afternoon all,
Please reference the code at:
http://www.omnytex.com/ajaxtags.zip
This is a complete webapp demonstrating the proposal (it isn't complete,
it is just to get the ideas across).
I wanted to put something out there in front of you all and get some
feedback on it before I go that extra mile and finish it out.
This came out of some ideas I tossed at Ted a few days ago. The basic
idea is to take the existing Struts HTML taglib and make the tags
Ajax-aware.
In a nuthsell, take a simple button tag...
html:button property=button1 value=Click to do Ajax! /
...now, add a new attribute to it, ajaxRef:
html:button property=button1 value=Click to do Ajax!
ajaxRef=button1 /
When the tag is rendered, each possible type of event handler (in the
BaseTagHandler class) looks something like this now:
if (getOnclick() != null) {
handlers.append( onclick=\);
handlers.append(getOnclick());
handlers.append(\);
}
else {
prepareAjax(onclick, handlers);
}
prepareAjax() does a lookup to a new XML configuration file (well,
in-memory objects representing the XML of course!) like so:
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
If an ajaxElement with an id matching the ajaxRef attribute is
found,
and if an event with a type matching the type being added to the tag
is found, then the prepareAjax() method does its thing (note that
developer-defined event handler functions will take precedent, so no
existing code would be broken by this). And what is its thing you
ask?
Basically it will add an inline event handler to the tag, just like
always, that is capable of making an Ajax request (using the
XMLHttpRequest
RE: [OT] For Struts or Sports Lovers
Might have helped to have a guest login guest/guest123 -- Peter Pilgrim Operations/IT - Credit Suisse First Boston, Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom Tel: +44-(0)207-883-4497 -Original Message- From: t t [mailto:[EMAIL PROTECTED] Sent: 15 April 2005 17:21 To: user@struts.apache.org Subject: [OT] For Struts or Sports Lovers If you are a struts or sports lover or both, you're welcome to take a look at www.sportslovers.net which is a yellow page of sports lovers and built based on Struts. Sorry if this post bothers you. T.T. - Do you Yahoo!? Yahoo! Small Business - Try our new resources site! == 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!
SNIP On 4/18/05, Dave Newton [EMAIL PROTECTED] wrote: Or we could just use ActiveX controls. *psych!* /SNIP Or JavaScript, or Applets, or Flash, or .. but, most importantly, in this thread, AJAX with STRUTS. Jack -- 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: Dispatch Action Strangeness
Any further insights on this? It seems I'm missing something simple here...
I dont want ot have to manually call methods on my action...
help? :)
Is there something beyond the
html:hidden property=dispatch value=error/
that I need (and the hidden field named dispatch)
and of course to have my Action inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from it... that wouldnt make a diffference though correct?
On 4/15/05, David Johnson [EMAIL PROTECTED] wrote:
in my HTML I have
html:hidden property=dispatch value=error/
in my struts config (for the appropriate action) I have
parameter=dispatch
Is there something else I need?
On 4/15/05, Rick Reumann [EMAIL PROTECTED] wrote:
David Johnson wrote the following on 4/15/2005 3:21 PM:
I saw that after I sent it. I have changed it to inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from DispatchAction) but the methods still arent being
called.
You sure you have the parameter property in your action mapping in your
struts config?
set('graph'); I'm assuming is setting a hidden parameter (your dispatch
parameter)... whatever that parameter is, is the one you need also
defined in your action mapping.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-Dave
[EMAIL PROTECTED]
--
-Dave
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
example using validations with nested tags
Does anyone know of any examples using the struts validation framework with the nested tags. Thanks in advance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
html:multibox
hi reading from past postings this subject has been much talked about. but not finding a solution to my liking i post this question. i want a user a see a set of checkboxes some selected some not. the user is allowed to check uncheck anyone of them. upon form submission, i want the value of the checkbox which can be any value of type int to be submitted as an array to form. ie the value can be (1,2,3 ... 1000,1001,10...). also, is it possible to check a checkbox for any of these vales? my form : DynaActinForm has fields id:integer // not given here selected:integer[] all:integer[] ok: now am trouble in jsp ;( also, for form prepopulation, is it possible to set the selected,all array types with form.set(propname, index, ValueObject); does the form take care of the increasing index ?? thanx riyaz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
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? I think doing it at the individual form element level allows for more flexibility, although I see your point about what seems semantically correct. I'm open to suggestions either way. -- 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: AJAX: Whoa, Nellie!
Interesting... honestly, I hadn't thought about it! I think you kind of touch on one of the points made in the dev list thread (by Martin I believe) that was cited as a reason not to go with my proposal: is it flexible enough? Certainly it would be next to impossible to cover ever usage pattern, and it might be folly to try. This might be along those lines... if we tried to tie in to the form errors, we would necasserily have to choose one implementation or another, and then you've tied everyone to that. It's a fair point I think. My argument was that providing at least a simple implementation, assuming it could be extended later, made sense. That was actully my argument for the whole proposal... I don't think it would have been the One True Solution to bind us all, but for those that are just coming into the AJAX mindset, it gives them an easy way into it, and then later on when they need more power and flexibility they can move on to something better. Of course, there are rather reasonable arguments against even THAT :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 11:15 am, Benedict, Paul C said: Frank, will Ajax support be tied into reporting form errors? It would be interesting to break down the validator into individual validations, so errors can be reported to the user as he types. -Original Message- From: Emmanouil Batsis [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 11:12 AM To: Struts Users Mailing List; Dakota Jack Subject: Re: AJAX: Whoa, Nellie! Let me first say that IMHO, introducing AJAX capabilities into the html taglib is an awesome idea. Frank W. Zammetti wrote: So, the question is, does anyone see this as something interesting? Very. I was also thinking about working on AJAX taglibs using Sarissa [1] (introductory article at [2]), but i was aiming for more than XMLHttpRequest, for example to allow XSLT transformations to be applied on the XML either the server or client, depending on what the browser supports. Is anyone interested in seeing this actually finished up? If so I can do that, probably by the weekend if things go well, and I suppose open a ticket for it at that point. I would happily help (although i have little time) and even donate the JS code under the ASL if wanted. Questions? Comments? Whatever? Thanks all! 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. [1] http://sarissa.sf.net/ [2] http://www.xml.com/pub/a/2005/02/23/sarissa.html Manos - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- - 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 Mon, April 18, 2005 11:33 am, Hubert Rabago said: No problemo. As far as the extension itself is concerned, I'd still be interested in it, but like I mentioned earlier, only as a plugin that doesn't change the base tags. I thought that was a fair point at the time, and still do. I haven't had time to look into it yet, but I wouldn't mind re-implementing what I've done as the EL tags are, as you pointed out, just an extension. I have some questions on how to actually do it, but the idea I think is sound. The reasons are many and they are mentioned in the dev thread you started. My main concern is implementation lock-in. Another message in this thread already illustrates that there could be several approaches to adding this functionality. I wouldn't want to limit how everyone else applies the technology. Absolutely. I was trying to provide an easy way for people to get started with AJAX techniques while still using the tags they are already familiar with, that was my underlying thought. But the objections raised where perfectly valid. I do think the extension approach addresses those concerns, and hopefully I'll have some time to go that route. As Martin said, if an implementation is built into Struts, it should support whatever client-side library the developer would want to use ( http://marc.theaimsgroup.com/?l=struts-devm=111284722931074w=2 ). A separate plugin wouldn't have to have that burden. I was actually a bit perplexed by Martin's reply... I still am I guess... when we talk about supporting whatever client-side library the developer wants to use, what are we really talking about? I've always thought that if you use the Struts tags, you have in effect choosen what client-side library you are using. If you were to use JSF or whatever else you could name, wouldn't you be using a whole different set of tags, that may or may not have AJAX functionality? I guess I'd like to hear that point clarified... what does everyone think it actually means to support a client-side library? Perhaps starting with really defining what a client-side library is would be a good starting point :) A separated plugin would result in code duplication, true, but in my view it's worth it. In some aspects, the ajax-aware tags you propose are in a better position than the EL tags. You only need to override some methods, whose implementation can be moved to a util-type class. EL had to add duplicate fields, getters, and setters. Just take a look at the source of some of those tags, like ELCheckboxTag and ELRadioTag. I do agree, for my initial simple pass, that is a better way to go. I didn't do that mainly because of what you say: code duplication. But, that probably is ultimately a better answer. Like I said, there are some questions in my mind how you mechanically go about it, but the idea is sound I think. -- 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: AJAX: Whoa, Nellie!
Woodchuck wrote: As soon as IE becomes open source we can start that. Until then, or until IE's market share drops into single digits we're forced to deal with browsers as a given. Besides, much of the visceral dislike for javascript is based on older browsers that were not at all consistend. Trying to write cross-browser IE4-NS4 javascript is often an exercise in frustration. In the IE6 - Moz 1.7 Firefox 1.0x (sorry I'm not a Mac guy so I don't know the current ver for its browser) most problems can be avoided by using DOM compliant code rather than IE specific code. This ain't yer daddy's DHTML. sorry, i couldn't resist . actually, why don't we address this problem at the source rather than using this javascript patch solution? (at least this is how i see it) why don't the browser makers build internal mechanisms to allow posting of forms without the need to refresh the html page? why don't we re-architect the browswer and address this problem (and others) at that fundamental level? is this not conceivable? woodchuck --- Dakota Jack [EMAIL PROTECTED] wrote: JavaScript provides a client side rather developed engine in JavaScript as well as Flash, etc. This is merely a resource. The yuck, ptooey! ptooey response to these ideas, especially ones in production and successful for quite a while, strikes me as rather less than professional. I think it is interesting that JavaScript, which I have avoided like the plague, has kept building a market despite a lot of prejudice from people like myself, not to mention Woodchuck. ///;-) On 4/18/05, Woodchuck [EMAIL PROTECTED] wrote: eee... javascript... yuck, ptooey! ptooey!! --- Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - 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] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
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! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 1:06 pm, Fogleson, Allen said: Although I will admit the usefulness overall of javascript and in specific AJAX's use thereof I still have an uneasy feeling whenever you are using JS. Users, in general, have become smarter security wise and many are turning off JS altogether. Unfortunately there is no other client side secure technology to replace js so I guess we are stuck with it :) Al -Original Message- From: Jason King [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 11:56 AM To: Struts Users Mailing List Subject: Re: AJAX: Whoa, Nellie! As soon as IE becomes open source we can start that. Until then, or until IE's market share drops into single digits we're forced to deal with browsers as a given. Besides, much of the visceral dislike for javascript is based on older browsers that were not at all consistend. Trying to write cross-browser IE4-NS4 javascript is often an exercise in frustration. In the IE6 - Moz 1.7 Firefox 1.0x (sorry I'm not a Mac guy so I don't know the current ver for its browser) most problems can be avoided by using DOM compliant code rather than IE specific code. This ain't yer daddy's DHTML. - 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!
Javascript hasn't been a problem as far as cross-browser development goes for some time, in my experience anyway. I can't remember the last time I wrote code that worked on one browser and not another. Oh wait, I take that back... I remember something about IE's substring method not working like Netscapes. But, as Jason said, if you are using modern versions, or even relatively recent ones, you probably won't have any problems as far as the scripting goes. The DOM models still have a fair degree of different, that's where you can sometimes run in to problems. Yes, coding to standard DOM will cut that down a bit, but even still you'll have to think lowest common denominator sometimes. The days of huge code branches and/or whole different code bases are, thankfully, gone (well, largely gone anyway). Some minor branching here or there, while annoying, are far from the problems we used to have in any case. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 12:55 pm, Jason King said: Woodchuck wrote: As soon as IE becomes open source we can start that. Until then, or until IE's market share drops into single digits we're forced to deal with browsers as a given. Besides, much of the visceral dislike for javascript is based on older browsers that were not at all consistend. Trying to write cross-browser IE4-NS4 javascript is often an exercise in frustration. In the IE6 - Moz 1.7 Firefox 1.0x (sorry I'm not a Mac guy so I don't know the current ver for its browser) most problems can be avoided by using DOM compliant code rather than IE specific code. This ain't yer daddy's DHTML. sorry, i couldn't resist . actually, why don't we address this problem at the source rather than using this javascript patch solution? (at least this is how i see it) why don't the browser makers build internal mechanisms to allow posting of forms without the need to refresh the html page? why don't we re-architect the browswer and address this problem (and others) at that fundamental level? is this not conceivable? woodchuck --- Dakota Jack [EMAIL PROTECTED] wrote: JavaScript provides a client side rather developed engine in JavaScript as well as Flash, etc. This is merely a resource. The yuck, ptooey! ptooey response to these ideas, especially ones in production and successful for quite a while, strikes me as rather less than professional. I think it is interesting that JavaScript, which I have avoided like the plague, has kept building a market despite a lot of prejudice from people like myself, not to mention Woodchuck. ///;-) On 4/18/05, Woodchuck [EMAIL PROTECTED] wrote: eee... javascript... yuck, ptooey! ptooey!! --- Vic Cekvenich (netsql) [EMAIL PROTECTED] wrote: Stéphane Zuckerman wrote: if this were to be integrated in Struts, my life would be easier. I too will now check it out. .V - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - 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] __ Do you Yahoo!? Plan great trips with Yahoo! Travel: Now over 17,000 guides! http://travel.yahoo.com/p-travelguide - 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!
To Frank's point, I am sometimes one of those users who turn off JavaScript ;-) But, it's a moot point, because, as I see it, no one's website should depend on JavaScript for it to be fully functional anymore than it should wholly rely on CSS. These are technologies that enable powerful usability, but websites should gracefully degrade when they are not available. So Ajax should add nice to have's, but not must have's. -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 1:14 PM To: Struts Users Mailing List Cc: Struts Users Mailing List Subject: RE: AJAX: Whoa, Nellie! 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! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 1:06 pm, Fogleson, Allen said: Although I will admit the usefulness overall of javascript and in specific AJAX's use thereof I still have an uneasy feeling whenever you are using JS. Users, in general, have become smarter security wise and many are turning off JS altogether. Unfortunately there is no other client side secure technology to replace js so I guess we are stuck with it :) Al -Original Message- From: Jason King [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 11:56 AM To: Struts Users Mailing List Subject: Re: AJAX: Whoa, Nellie! As soon as IE becomes open source we can start that. Until then, or until IE's market share drops into single digits we're forced to deal with browsers as a given. Besides, much of the visceral dislike for javascript is based on older browsers that were not at all consistend. Trying to write cross-browser IE4-NS4 javascript is often an exercise in frustration. In the IE6 - Moz 1.7 Firefox 1.0x (sorry I'm not a Mac guy so I don't know the current ver for its browser) most problems can be avoided by using DOM compliant code rather than IE specific code. This ain't yer daddy's DHTML. - 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] -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
But windows (at least in it's newest form - XP) doesn't ship with fdisk anymore :) (Heck the way windows is going pretty soon you wont be able to format either except at install time) Al -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 12:14 PM To: Struts Users Mailing List Cc: Struts Users Mailing List Subject: RE: AJAX: Whoa, Nellie! 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! -- 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: Dispatch Action Strangeness
Are you overriding execute() in either your Action or BaseAction? On 4/18/05, David Johnson [EMAIL PROTECTED] wrote: Any further insights on this? It seems I'm missing something simple here... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
But, it's a moot point, because, as I see it, no one's website should depend on JavaScript for it to be fully functional anymore than it should wholly rely on CSS. I would have to respectfully disagree Paul. While I think it's right to say that not EVERYONE'S web site should require these things, it is equally right to say that some should. The point of divergance I think is the differentiation between web SITE and web APPLICATION. The former I would certainly agree should strive to avoid requiring those things, but the later in many instances almost requires requiring them :) Those has been for a long time two schools of thought on web development... one believes in what I call the classical model... they feel that as little as possible should be done on the client. They are generally against (or shy away from) scripting and DHTML solutions. They can quote numerous reasons, most very valid, for their point of view: security, ease of development and debugging, centralized code, etc. One of the characteristics of the things developed by this camp is that they tend to not be especially user-friendly and usually at the opposite end of the spectrum from the old fat-clients. There are of course exceptions, and everyone can name them, but as a generality that is true. The other school of thought feels that you have immensely powerful client machines accessing your site, so why not use them? They believe that web applications don't have to look like pages of static text with boring HTML forms all over the place. There are equally valid reasons for their point of view: performance, richer user experiences and lower server utilization (and thereby costs), etc. They generally develop things that look, feel and work more like fat-clients, however, they tend to be more complex, requiring a higher degree of expertise to develop and maintain. Both sides have valid points. I personally fall in the later group, but I swing to the other side sometimes (man, taken out of context my wife is gonna KILL me!). In any case, when you are talking about a web SITE, I think there is more to be said for the classical camp, and just the opposite is true when talking about a web APPLICATION. What determines which something is? There are no hard and fast rules, but generally, if you are developing something that you can't control or even know who will be accessing it, you are developing a web SITE and you should think a different way than someone developing something that will be accessed by a known audience. Note that having a known audience does NOT imply it is an internal application, although that is true much of the time. You can have an web application that is outward-facing... a bank's web site is usually given as an example of this (although some argue they wouldn't use a bank that required then to use Javascript)... depending on what functionality that banks' site provides, requiring Javascript might be justifiable. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 1:19 pm, Benedict, Paul C said: To Frank's point, I am sometimes one of those users who turn off JavaScript ;-) But, it's a moot point, because, as I see it, no one's website should depend on JavaScript for it to be fully functional anymore than it should wholly rely on CSS. These are technologies that enable powerful usability, but websites should gracefully degrade when they are not available. So Ajax should add nice to have's, but not must have's. -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 1:14 PM To: Struts Users Mailing List Cc: Struts Users Mailing List Subject: RE: AJAX: Whoa, Nellie! 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! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 1:06 pm, Fogleson, Allen said: Although I will admit the usefulness overall of javascript and in specific AJAX's use thereof I still have an uneasy feeling whenever you are using JS. Users, in general, have become smarter security wise and many are turning off JS altogether. Unfortunately there is no other client side secure technology to replace js so I guess we are stuck with it :) Al -Original Message- From: Jason King [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 11:56 AM To: Struts Users Mailing List Subject: Re: AJAX: Whoa, Nellie!
RE: AJAX: Whoa, Nellie!
At 11:15 AM -0400 4/18/05, Benedict, Paul C wrote: Frank, will Ajax support be tied into reporting form errors? It would be interesting to break down the validator into individual validations, so errors can be reported to the user as he types. Independent of Ajax, Niall Pemberton has done a substantial overhaul of commons-validator which will support per-field validation instead of only onsubmit. http://www.niallp.pwp.blueyonder.co.uk/validatorjs.html It's really quite impressive, and I think it's only pending Niall having enough time to really give it a good run-through, since it's a pretty big change. Otherwise, Paul, I'm not sure what you mean... is your idea that an XMLHttpRequest call would be made to do server-side validation for each form update? The overhead is likely to make that an impractical solution. Or are you wondering how errors would be reported back to the page as a response from an XMLHttpRequest? I don't think this is part of Frank's kit (sorry if it is and I missed it) but it makes sense from a framework standpoint to have standard XML representations of Struts concepts (like ActionMessages) paired with a JavaScript library that can convert those into a standardized JavaScript object model. I haven't tried yet to solve any problems with Ajax where this would be useful, but it's definitely the kind of thing you wouldn't want to leave each person to have to rewrite him- or herself. 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: AJAX: Whoa, Nellie!
Frank, Thanks for your respectful rebuttal. My statement was pretty general and a wide-range of exceptions exist for it, but I think we actually agree at the end of the day when the whole picture painted. You're right to draw the distinction between a SITE and APPLICATION, and sometimes JavaScript is a mandatory requirement for applications. -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 1:41 PM To: Struts Users Mailing List Cc: 'Struts Users Mailing List' Subject: RE: AJAX: Whoa, Nellie! But, it's a moot point, because, as I see it, no one's website should depend on JavaScript for it to be fully functional anymore than it should wholly rely on CSS. I would have to respectfully disagree Paul. While I think it's right to say that not EVERYONE'S web site should require these things, it is equally right to say that some should. The point of divergance I think is the differentiation between web SITE and web APPLICATION. The former I would certainly agree should strive to avoid requiring those things, but the later in many instances almost requires requiring them :) Those has been for a long time two schools of thought on web development... one believes in what I call the classical model... they feel that as little as possible should be done on the client. They are generally against (or shy away from) scripting and DHTML solutions. They can quote numerous reasons, most very valid, for their point of view: security, ease of development and debugging, centralized code, etc. One of the characteristics of the things developed by this camp is that they tend to not be especially user-friendly and usually at the opposite end of the spectrum from the old fat-clients. There are of course exceptions, and everyone can name them, but as a generality that is true. The other school of thought feels that you have immensely powerful client machines accessing your site, so why not use them? They believe that web applications don't have to look like pages of static text with boring HTML forms all over the place. There are equally valid reasons for their point of view: performance, richer user experiences and lower server utilization (and thereby costs), etc. They generally develop things that look, feel and work more like fat-clients, however, they tend to be more complex, requiring a higher degree of expertise to develop and maintain. Both sides have valid points. I personally fall in the later group, but I swing to the other side sometimes (man, taken out of context my wife is gonna KILL me!). In any case, when you are talking about a web SITE, I think there is more to be said for the classical camp, and just the opposite is true when talking about a web APPLICATION. What determines which something is? There are no hard and fast rules, but generally, if you are developing something that you can't control or even know who will be accessing it, you are developing a web SITE and you should think a different way than someone developing something that will be accessed by a known audience. Note that having a known audience does NOT imply it is an internal application, although that is true much of the time. You can have an web application that is outward-facing... a bank's web site is usually given as an example of this (although some argue they wouldn't use a bank that required then to use Javascript)... depending on what functionality that banks' site provides, requiring Javascript might be justifiable. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 1:19 pm, Benedict, Paul C said: To Frank's point, I am sometimes one of those users who turn off JavaScript ;-) But, it's a moot point, because, as I see it, no one's website should depend on JavaScript for it to be fully functional anymore than it should wholly rely on CSS. These are technologies that enable powerful usability, but websites should gracefully degrade when they are not available. So Ajax should add nice to have's, but not must have's. -Original Message- From: Frank W. Zammetti [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 1:14 PM To: Struts Users Mailing List Cc: Struts Users Mailing List Subject: RE: AJAX: Whoa, Nellie! 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! -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 1:06 pm,
RE: AJAX: Whoa, Nellie!
Joe writes: Otherwise, Paul, I'm not sure what you mean... is your idea that an XMLHttpRequest call would be made to do server-side validation for each form update? The overhead is likely to make that an impractical solution. Or are you wondering how errors would be reported back to the page as a response from an XMLHttpRequest? I am not quite sure why the overhead makes it impractical, unless there is a physical barrier such as bandwidth restraint -- but that sounds like a case-by-case decision is required. But I've seen some forms, which I think AJAX runs behind the scenes to do validation. (If I can re-find a link I will send it.) When a non-date field is entered into a date field, for instance, an error message is shown to its side. This client-side reporting is akin to the errorStyles, which were added to the Struts 1.2.5 tags to allow per-field reporting on the server-side. -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 1:38 PM To: 'Struts Users Mailing List' Subject: RE: AJAX: Whoa, Nellie! At 11:15 AM -0400 4/18/05, Benedict, Paul C wrote: Frank, will Ajax support be tied into reporting form errors? It would be interesting to break down the validator into individual validations, so errors can be reported to the user as he types. Independent of Ajax, Niall Pemberton has done a substantial overhaul of commons-validator which will support per-field validation instead of only onsubmit. http://www.niallp.pwp.blueyonder.co.uk/validatorjs.html It's really quite impressive, and I think it's only pending Niall having enough time to really give it a good run-through, since it's a pretty big change. Otherwise, Paul, I'm not sure what you mean... is your idea that an XMLHttpRequest call would be made to do server-side validation for each form update? The overhead is likely to make that an impractical solution. Or are you wondering how errors would be reported back to the page as a response from an XMLHttpRequest? I don't think this is part of Frank's kit (sorry if it is and I missed it) but it makes sense from a framework standpoint to have standard XML representations of Struts concepts (like ActionMessages) paired with a JavaScript library that can convert those into a standardized JavaScript object model. I haven't tried yet to solve any problems with Ajax where this would be useful, but it's definitely the kind of thing you wouldn't want to leave each person to have to rewrite him- or herself. 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] -- Notice: This e-mail message, together with any attachments, contains information of Merck Co., Inc. (One Merck Drive, Whitehouse Station, New Jersey, USA 08889), and/or its affiliates (which may be known outside the United States as Merck Frosst, Merck Sharp Dohme or MSD and in Japan, as Banyu) that may be confidential, proprietary copyrighted and/or legally privileged. It is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please notify us immediately by reply e-mail and then delete it from your system. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
You are correct Joe, I made no attempt whatsoever to solve that situation. In short (relatively!), for anyone trying to get a grasp on it, my proposal boils down to this: We have these Struts tags that everyone (except ironically me, most of the time!) uses. These tags have various event handlers attached to them. These event handlers are client-side Javascript functions that do whatever it is they do. We also have this AJAX thingamajig, whereby a client calls on a server, gets a response, and, usually, updates just a part of a web page. Rather than develop a whole new taglib with AJAX at its center (which isn't a bad idea as an aside), why not just modify the existing Struts tags to have some at least minimal AJAX functionality? But what does that really mean? Simply put, instead of calling some Javascript function on the client in response to, say, the onClick event of a button, we instead call a server-side process, get a response back and update some part of the page. The point here is that you continue to use the existing tags that you know and, presumably!, love... your existing pages don't get broken, you don't have to rewrite anything, but you can now introduce this AJAX stuff as needed without having to write all the details yourself. Further, what if what was provided included a number of standard functions that would cover maybe 90% of the situations you might want to use AJAX, like updating the innerHTML of a span? What if you could send and received XML, or not, at your discretion? What if the extra cost of all this was an updated JAR, a Struts plug-in, a single new XML configuration file, and an ID added to any form tag you wanted to have this AJAX capability? That, in a nutshell, is my proposal. I was not seeking to recreate the world in an AJAX image, and I was not trying to cover every possible scenario that could arise. My goal was to expand what exists and what people use, giving them some extra functionality they didn't have before. Those that needed more flexibility and power would likely know to look elsewhere, those that had minimal requirements or otherwise didn't have the requisite expertise just yet could stay play with AJAX. I wasn't trying to create a Lexus, just a Yugo :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 1:38 pm, Joe Germuska said: At 11:15 AM -0400 4/18/05, Benedict, Paul C wrote: Frank, will Ajax support be tied into reporting form errors? It would be interesting to break down the validator into individual validations, so errors can be reported to the user as he types. Independent of Ajax, Niall Pemberton has done a substantial overhaul of commons-validator which will support per-field validation instead of only onsubmit. http://www.niallp.pwp.blueyonder.co.uk/validatorjs.html It's really quite impressive, and I think it's only pending Niall having enough time to really give it a good run-through, since it's a pretty big change. Otherwise, Paul, I'm not sure what you mean... is your idea that an XMLHttpRequest call would be made to do server-side validation for each form update? The overhead is likely to make that an impractical solution. Or are you wondering how errors would be reported back to the page as a response from an XMLHttpRequest? I don't think this is part of Frank's kit (sorry if it is and I missed it) but it makes sense from a framework standpoint to have standard XML representations of Struts concepts (like ActionMessages) paired with a JavaScript library that can convert those into a standardized JavaScript object model. I haven't tried yet to solve any problems with Ajax where this would be useful, but it's definitely the kind of thing you wouldn't want to leave each person to have to rewrite him- or herself. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
At 1:59 PM -0400 4/18/05, Benedict, Paul C wrote: Joe writes: Otherwise, Paul, I'm not sure what you mean... is your idea that an XMLHttpRequest call would be made to do server-side validation for each form update? The overhead is likely to make that an impractical solution. Or are you wondering how errors would be reported back to the page as a response from an XMLHttpRequest? I am not quite sure why the overhead makes it impractical, unless there is a physical barrier such as bandwidth restraint -- but that sounds like a case-by-case decision is required. Well, by definition, an XMLHttpRequest involves a request/response. I suppose it's true that a blanket statement against is in appropriate, considering that things like Google Maps do lots of XML R/R every time you drag the map around. But I've seen some forms, which I think AJAX runs behind the scenes to do validation. (If I can re-find a link I will send it.) When a non-date field is entered into a date field, for instance, an error message is shown to its side. This client-side reporting is akin to the errorStyles, which were added to the Struts 1.2.5 tags to allow per-field reporting on the server-side. It seems like validating a date is particularly a case where JavaScript should be able to do it fine without a network call -- unless you want to have some kind of scheduler app which checks to see if a date is available or something. Now, you raise a good point as to how the Javascript could capitalize on the presence of the errorStyle attribute, which normally is only interpreted on page load. That is, if you did any client side validation, you'd probably like to be able to switch the style of the invalid field to whatever was specified in errorStyle even if there was no error when the page loaded. This is valuable outside of the specifics of an Ajax situation and would also apply to any client-side validation. Unfortunately, I'm having trouble seeing a particularly clean way to do it which wouldn't involve loading down the base tags (because of single inheritance) and even then, I think you'd have a pretty contentious time getting people to agree on what the base tags should output. I guess maybe you could have some Application scoped input tag decorator which could be invoked by the tag if present while still leaving things open for customization... 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: AJAX: Whoa, Nellie!
On Mon, April 18, 2005 2:13 pm, Joe Germuska said: I am not quite sure why the overhead makes it impractical, unless there is a physical barrier such as bandwidth restraint -- but that sounds like a case-by-case decision is required. Well, by definition, an XMLHttpRequest involves a request/response. I suppose it's true that a blanket statement against is in appropriate, considering that things like Google Maps do lots of XML R/R every time you drag the map around. And the one thing that people tend to forget when thinking about AJAX is that there is nothing that says you have to use XML at all (well, aside from the ACRONYM of course!). It works just as well if you do nothing but query string to the server and simple CSV values back (depending on what your doing naturally). In fact, I don't think any of the examples in my article used XML, at least not submitted to the server. The point is that while you are dead-on Joe, much of that overhead can be alleviated by not using XML at all, seemingly in defiance of the technique in use :) It seems like validating a date is particularly a case where JavaScript should be able to do it fine without a network call -- unless you want to have some kind of scheduler app which checks to see if a date is available or something. No doubt. There are some things that I think people are just plain NUTS for not doing client-side. The format of a date entry is a good example. Now, you raise a good point as to how the Javascript could capitalize on the presence of the errorStyle attribute, which normally is only interpreted on page load. That is, if you did any client side validation, you'd probably like to be able to switch the style of the invalid field to whatever was specified in errorStyle even if there was no error when the page loaded. This is valuable outside of the specifics of an Ajax situation and would also apply to any client-side validation. Unfortunately, I'm having trouble seeing a particularly clean way to do it which wouldn't involve loading down the base tags (because of single inheritance) and even then, I think you'd have a pretty contentious time getting people to agree on what the base tags should output. I guess maybe you could have some Application scoped input tag decorator which could be invoked by the tag if present while still leaving things open for customization... I actually have some ideas about this Joe, but they aren't completely formed in my brain yet... I'm also not sure any of them will be any good once they are, but if I belive they are I'll post them. What I'm thinking about is the kind of stuff I've done in some of my apps which sound oh so close to what your talking about here... if I can generalize the code I use to do it, then it could wind up being useful to solve this problem. Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
This is all great, and ajax definetely rules, but is it OK to use other's pictures without giving credit to their author, who by the way, came up with this name: http://www.adaptivepath.com/publications/essays/archives/000385.php - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Your right, and I suggest we stop using the AJAX name lest someone get sued... Might I suggest WOINA? (W)hat's (O)ld (I)s (N)ew (A)gain. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 2:29 pm, Michael J. said: This is all great, and ajax definetely rules, but is it OK to use other's pictures without giving credit to their author, who by the way, came up with this name: http://www.adaptivepath.com/publications/essays/archives/000385.php - 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!
What? Michael J. [EMAIL PROTECTED] 04/18/2005 02:29 PM Please respond to Struts Users Mailing List user@struts.apache.org To Struts Users Mailing List user@struts.apache.org cc Subject Re: AJAX: Whoa, Nellie! This is all great, and ajax definetely rules, but is it OK to use other's pictures without giving credit to their author, who by the way, came up with this name: http://www.adaptivepath.com/publications/essays/archives/000385.php - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Now, you raise a good point as to how the Javascript could capitalize on the presence of the errorStyle attribute, which normally is only interpreted on page load. That is, if you did any client side validation, you'd probably like to be able to switch the style of the invalid field to whatever was specified in errorStyle even if there was no error when the page loaded. This is valuable outside of the specifics of an Ajax situation and would also apply to any client-side validation. Unfortunately, I'm having trouble seeing a particularly clean way to do it which wouldn't involve loading down the base tags (because of single inheritance) and even then, I think you'd have a pretty contentious time getting people to agree on what the base tags should output. I guess maybe you could have some Application scoped input tag decorator which could be invoked by the tag if present while still leaving things open for customization... Joe This one is simple. HTML ignores attributes it doesn't understand. That means all your input boxes etc. could have an errorStyle attribute defined (and probably a normalStyle as well) and then when the js validation code runs it could look to see if such attributes are defined and then copy the value of errorStyle or normalStyle as appropriate to style when validating. In other words your emitted HTML would look like input type=text name=lastname style=basicstyle errorStyle=itsucks normalStyle=basicstyle value=King onChange=some_js_function(this) The element renders correctly, validators that don't flip styles ignore the extra attributes validators that use them have them. I know its bizarre, adding atttributes to objects at run-time, but that's the world of the DOM. Its' been a while since I tested this, I believe if I have a text input object in the variable oTxt to find out its errorStyle attribute I have to use js like: var es = oTxt.getAttribute(errorStyle); // returns null if no such attribute exists. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dispatch Action Strangeness
IIRC you wanted the graph method to be called because you had
set('graph') in an onclick handler. What does the set('graph')
method do? Does it modify the dispatch form field?
On 4/18/05, David Johnson [EMAIL PROTECTED] wrote:
Any further insights on this? It seems I'm missing something simple here...
I dont want ot have to manually call methods on my action...
help? :)
Is there something beyond the
html:hidden property=dispatch value=error/
that I need (and the hidden field named dispatch)
and of course to have my Action inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from it... that wouldnt make a diffference though correct?
On 4/15/05, David Johnson [EMAIL PROTECTED] wrote:
in my HTML I have
html:hidden property=dispatch value=error/
in my struts config (for the appropriate action) I have
parameter=dispatch
Is there something else I need?
On 4/15/05, Rick Reumann [EMAIL PROTECTED] wrote:
David Johnson wrote the following on 4/15/2005 3:21 PM:
I saw that after I sent it. I have changed it to inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from DispatchAction) but the methods still arent being
called.
You sure you have the parameter property in your action mapping in your
struts config?
set('graph'); I'm assuming is setting a hidden parameter (your dispatch
parameter)... whatever that parameter is, is the one you need also
defined in your action mapping.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Frank, What do we need extra tags for? We already have hooks to call javascript functions, whether those functions run 100% client-side or interact through an xmlhttp object or even through a 1x1 pixel iframe should be totally unknown to the individual input elements. Frank W. Zammetti wrote: You are correct Joe, I made no attempt whatsoever to solve that situation. In short (relatively!), for anyone trying to get a grasp on it, my proposal boils down to this: We have these Struts tags that everyone (except ironically me, most of the time!) uses. These tags have various event handlers attached to them. These event handlers are client-side Javascript functions that do whatever it is they do. We also have this AJAX thingamajig, whereby a client calls on a server, gets a response, and, usually, updates just a part of a web page. Rather than develop a whole new taglib with AJAX at its center (which isn't a bad idea as an aside), why not just modify the existing Struts tags to have some at least minimal AJAX functionality? But what does that really mean? Simply put, instead of calling some Javascript function on the client in response to, say, the onClick event of a button, we instead call a server-side process, get a response back and update some part of the page. The point here is that you continue to use the existing tags that you know and, presumably!, love... your existing pages don't get broken, you don't have to rewrite anything, but you can now introduce this AJAX stuff as needed without having to write all the details yourself. Further, what if what was provided included a number of standard functions that would cover maybe 90% of the situations you might want to use AJAX, like updating the innerHTML of a span? What if you could send and received XML, or not, at your discretion? What if the extra cost of all this was an updated JAR, a Struts plug-in, a single new XML configuration file, and an ID added to any form tag you wanted to have this AJAX capability? That, in a nutshell, is my proposal. I was not seeking to recreate the world in an AJAX image, and I was not trying to cover every possible scenario that could arise. My goal was to expand what exists and what people use, giving them some extra functionality they didn't have before. Those that needed more flexibility and power would likely know to look elsewhere, those that had minimal requirements or otherwise didn't have the requisite expertise just yet could stay play with AJAX. I wasn't trying to create a Lexus, just a Yugo :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: AJAX: Whoa, Nellie!
hi, after all the mail about the philosophical aspects of AJAX (javascript yes/no, etc.) i want to contribute that THIS IS THE SOLUTION i've been looking for for one of my current projects. so, do i want to have that in struts? YES, I WANT! where can i sign? frank, if i would pray my next prayer would be for you, but be sure that my next beer is for you! kr, guenther -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 3:02 PM To: Struts Users Mailing List Subject: AJAX: Whoa, Nellie! I have been taking another look at the AJAX stuff that Frank Zammetti has provided. This stuff is revolutionary. Someone ought to be taking a close look at integrating such solutions, so far as it makes sense, into Struts. This is not a passing fancy, in my estimation. This is a real solution to a persistent problem. Further, this moves the solution to where the problem exists, on the client. I, for one, am getting excited. I am not saying to be precipitous, so the usual mundane warnings can be kept aside. But, this is not the usual thing. This is a fundamental shift in architecture that makes clear sense. Jack -- 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!
Yes. I agree with this wholeheartedly. I wish we would do something
similar with the application specific code that is now in Struts.
Plugins would not be the solution, but something akin to that.
On 4/18/05, Hubert Rabago [EMAIL PROTECTED] wrote:
No problemo. As far as the extension itself is concerned, I'd still
be interested in it, but like I mentioned earlier, only as a plugin
that doesn't change the base tags. The reasons are many and they are
mentioned in the dev thread you started. My main concern is
implementation lock-in. Another message in this thread already
illustrates that there could be several approaches to adding this
functionality. I wouldn't want to limit how everyone else applies the
technology. As Martin said, if an implementation is built into
Struts, it should support whatever client-side library the developer
would want to use (
http://marc.theaimsgroup.com/?l=struts-devm=111284722931074w=2 ). A
separate plugin wouldn't have to have that burden.
A separated plugin would result in code duplication, true, but in my
view it's worth it. In some aspects, the ajax-aware tags you propose
are in a better position than the EL tags. You only need to override
some methods, whose implementation can be moved to a util-type class.
EL had to add duplicate fields, getters, and setters. Just take a
look at the source of some of those tags, like ELCheckboxTag and
ELRadioTag.
Hubert
On 4/18/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Yep, sorry about that... I had it in my drafts folder because I got called
away in the middle of it, and I didn't check all the replies to the
current thread before sending it so I didn't see your link until
afterwards. My bad :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, April 18, 2005 10:41 am, Hubert Rabago said:
Frank,
You must've started typing this response a while ago. I already sent
a message on this thread linking to the dev email with your proposal.
Hubert
On 4/18/05, Frank W. Zammetti [EMAIL PROTECTED] wrote:
On 4/6 I posted the following message to the Struts dev list... I can't
seem to find the thread in the list archives, if anyone else can I would
appreciate very much you posting the link to it...
This was discussing my proposal for integrating AJAX functionality into
the existing Struts taglibs. There were some legitimate dissenting
points
raised about this, and ultimately the idea was shot down. However, I
still feel the idea has significant merit.
The proposal wasn't posted to the user list, and maybe I should have
done
so... if there is support for this in the user community, I would be
willing to persue it further and provide it as part of the SF Struts
project.
P.S., I've added some notes here for some things that may not be as
clear
as I would have liked, especially if you aren't terribly familiar with
the
Struts code base, so if you see minor difference between this and what
is
in the archives, that's all it is...
Subject: RFC: Struts HTML Ajax-Aware Tags
Afternoon all,
Please reference the code at:
http://www.omnytex.com/ajaxtags.zip
This is a complete webapp demonstrating the proposal (it isn't complete,
it is just to get the ideas across).
I wanted to put something out there in front of you all and get some
feedback on it before I go that extra mile and finish it out.
This came out of some ideas I tossed at Ted a few days ago. The basic
idea is to take the existing Struts HTML taglib and make the tags
Ajax-aware.
In a nuthsell, take a simple button tag...
html:button property=button1 value=Click to do Ajax! /
...now, add a new attribute to it, ajaxRef:
html:button property=button1 value=Click to do Ajax!
ajaxRef=button1 /
When the tag is rendered, each possible type of event handler (in the
BaseTagHandler class) looks something like this now:
if (getOnclick() != null) {
handlers.append( onclick=\);
handlers.append(getOnclick());
handlers.append(\);
}
else {
prepareAjax(onclick, handlers);
}
prepareAjax() does a lookup to a new XML configuration file (well,
in-memory objects representing the XML of course!) like so:
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
If an ajaxElement with an id matching the ajaxRef attribute is
found,
and if an event with a type matching the type being added to the
RE: AJAX: Whoa, Nellie!
...and some very simple questions, i hope i didn't pass the answers in all the mails about ajax: - where can i get it (especially the struts extension, or was it just a proposal)? - if it is under development, is there a chance to get a snapshot and to contribute to the development? kr, guenther -Original Message- From: Günther Wieser [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 8:55 PM To: 'Struts Users Mailing List'; 'Dakota Jack' Subject: RE: AJAX: Whoa, Nellie! hi, after all the mail about the philosophical aspects of AJAX (javascript yes/no, etc.) i want to contribute that THIS IS THE SOLUTION i've been looking for for one of my current projects. so, do i want to have that in struts? YES, I WANT! where can i sign? frank, if i would pray my next prayer would be for you, but be sure that my next beer is for you! kr, guenther -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 3:02 PM To: Struts Users Mailing List Subject: AJAX: Whoa, Nellie! I have been taking another look at the AJAX stuff that Frank Zammetti has provided. This stuff is revolutionary. Someone ought to be taking a close look at integrating such solutions, so far as it makes sense, into Struts. This is not a passing fancy, in my estimation. This is a real solution to a persistent problem. Further, this moves the solution to where the problem exists, on the client. I, for one, am getting excited. I am not saying to be precipitous, so the usual mundane warnings can be kept aside. But, this is not the usual thing. This is a fundamental shift in architecture that makes clear sense. Jack -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Forget whatever I was thinking, I think Jason is on the right track!
Ironically, I add custom attributes all the time in numerous situations,
but it frankly escaped me as a possible solution here.
All you really need beyond this is probably a new tag that renders a JS
function that you can pass an object reference and it will do the setting
of the style for you. So, you get:
html
head
html:styleSwitcher /
/head
body
html:form
html:button errorStyle=itsucks normalStyle=basicstyle /
/html:form
/body/html
Which emits:
html
head
script
function styleSwitcher(obj, error) {
if (error) {
obj.style = obj.errorStyle;
} else {
obj.style = obj.normalStyle;
}
}
/script
/head
body
html:form
html:button errorStyle=itsucks normalStyle=basicstyle /
/html:form
/body/html
... or similar such thing (I'm just dumping off the top of my head here).
The developer has simply to call styleSwitcher(form.element, true); in the
validation code to switch the style to the error style or
styleSwitcher(form.element, false); to switch it back to normal.
Thanks Jason, even if it doesn't go this way I can very much see this
being helpful in my own work. Great call!
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Mon, April 18, 2005 2:41 pm, Jason King said:
Now, you raise a good point as to how the Javascript could capitalize
on the presence of the errorStyle attribute, which normally is only
interpreted on page load. That is, if you did any client side
validation, you'd probably like to be able to switch the style of the
invalid field to whatever was specified in errorStyle even if there
was no error when the page loaded. This is valuable outside of the
specifics of an Ajax situation and would also apply to any client-side
validation. Unfortunately, I'm having trouble seeing a particularly
clean way to do it which wouldn't involve loading down the base tags
(because of single inheritance) and even then, I think you'd have a
pretty contentious time getting people to agree on what the base tags
should output. I guess maybe you could have some Application scoped
input tag decorator which could be invoked by the tag if present
while still leaving things open for customization...
Joe
This one is simple. HTML ignores attributes it doesn't understand.
That means all your input boxes etc. could have an errorStyle attribute
defined (and probably a normalStyle as well) and then when the js
validation code runs it could look to see if such attributes are defined
and then copy the value of errorStyle or normalStyle as appropriate to
style when validating. In other words your emitted HTML would look like
input type=text name=lastname style=basicstyle
errorStyle=itsucks normalStyle=basicstyle value=King
onChange=some_js_function(this)
The element renders correctly, validators that don't flip styles ignore
the extra attributes validators that use them have them. I know its
bizarre, adding atttributes to objects at run-time, but that's the world
of the DOM.
Its' been a while since I tested this, I believe if I have a text input
object in the variable oTxt to find out its errorStyle attribute I
have to use js like:
var es = oTxt.getAttribute(errorStyle); // returns null if no such
attribute exists.
-
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!
http://www.omnytex.com/ajaxtags.zip is everything I have. It is, I'd say, partially real... There are some things I didn't do (most importantly the reading in of the configuration file), but it is a real, working thing there, mostly. It certainly needs to be completed, but ultimately in simplest form it isn't all that far off. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 3:03 pm, Günther Wieser said: ...and some very simple questions, i hope i didn't pass the answers in all the mails about ajax: - where can i get it (especially the struts extension, or was it just a proposal)? - if it is under development, is there a chance to get a snapshot and to contribute to the development? kr, guenther -Original Message- From: Günther Wieser [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 8:55 PM To: 'Struts Users Mailing List'; 'Dakota Jack' Subject: RE: AJAX: Whoa, Nellie! hi, after all the mail about the philosophical aspects of AJAX (javascript yes/no, etc.) i want to contribute that THIS IS THE SOLUTION i've been looking for for one of my current projects. so, do i want to have that in struts? YES, I WANT! where can i sign? frank, if i would pray my next prayer would be for you, but be sure that my next beer is for you! kr, guenther -Original Message- From: Dakota Jack [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 3:02 PM To: Struts Users Mailing List Subject: AJAX: Whoa, Nellie! I have been taking another look at the AJAX stuff that Frank Zammetti has provided. This stuff is revolutionary. Someone ought to be taking a close look at integrating such solutions, so far as it makes sense, into Struts. This is not a passing fancy, in my estimation. This is a real solution to a persistent problem. Further, this moves the solution to where the problem exists, on the client. I, for one, am getting excited. I am not saying to be precipitous, so the usual mundane warnings can be kept aside. But, this is not the usual thing. This is a fundamental shift in architecture that makes clear sense. Jack -- 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] - 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!
You lost me Jason... what extra tags are you referring to? My proposal specifically didn't require any new tags, only additions to the existing ones. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 2:43 pm, Jason King said: Frank, What do we need extra tags for? We already have hooks to call javascript functions, whether those functions run 100% client-side or interact through an xmlhttp object or even through a 1x1 pixel iframe should be totally unknown to the individual input elements. Frank W. Zammetti wrote: You are correct Joe, I made no attempt whatsoever to solve that situation. In short (relatively!), for anyone trying to get a grasp on it, my proposal boils down to this: We have these Struts tags that everyone (except ironically me, most of the time!) uses. These tags have various event handlers attached to them. These event handlers are client-side Javascript functions that do whatever it is they do. We also have this AJAX thingamajig, whereby a client calls on a server, gets a response, and, usually, updates just a part of a web page. Rather than develop a whole new taglib with AJAX at its center (which isn't a bad idea as an aside), why not just modify the existing Struts tags to have some at least minimal AJAX functionality? But what does that really mean? Simply put, instead of calling some Javascript function on the client in response to, say, the onClick event of a button, we instead call a server-side process, get a response back and update some part of the page. The point here is that you continue to use the existing tags that you know and, presumably!, love... your existing pages don't get broken, you don't have to rewrite anything, but you can now introduce this AJAX stuff as needed without having to write all the details yourself. Further, what if what was provided included a number of standard functions that would cover maybe 90% of the situations you might want to use AJAX, like updating the innerHTML of a span? What if you could send and received XML, or not, at your discretion? What if the extra cost of all this was an updated JAR, a Struts plug-in, a single new XML configuration file, and an ID added to any form tag you wanted to have this AJAX capability? That, in a nutshell, is my proposal. I was not seeking to recreate the world in an AJAX image, and I was not trying to cover every possible scenario that could arise. My goal was to expand what exists and what people use, giving them some extra functionality they didn't have before. Those that needed more flexibility and power would likely know to look elsewhere, those that had minimal requirements or otherwise didn't have the requisite expertise just yet could stay play with AJAX. I wasn't trying to create a Lexus, just a Yugo :) - 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!
Thanks tor this note. Attribution supplied. You might have done that yourself. On 4/18/05, Michael J. [EMAIL PROTECTED] wrote: This is all great, and ajax definetely rules, but is it OK to use other's pictures without giving credit to their author, who by the way, came up with this name: http://www.adaptivepath.com/publications/essays/archives/000385.php - 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!
There is no problem using the name. That is the name the people at Adaptive Path want used. It is not the name for a product. It is the name for a technology and there is no problem with being sued. You can just AJAX all you want. The name is clean, but not cleanser. ///;-) Jack On 4/18/05, Frank W. Zammetti [EMAIL PROTECTED] wrote: Your right, and I suggest we stop using the AJAX name lest someone get sued... Might I suggest WOINA? (W)hat's (O)ld (I)s (N)ew (A)gain. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 2:29 pm, Michael J. said: This is all great, and ajax definetely rules, but is it OK to use other's pictures without giving credit to their author, who by the way, came up with this name: http://www.adaptivepath.com/publications/essays/archives/000385.php - 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] -- 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!
From wiki: No one should be under the impression that you have to deal in XML or that you have to use the XMLHttpRequest object at all, contrary to the meaning of the AJAX moniker. Not that I really care about the name, but for me you do not use Ajax if you do not use async HTTP calls, either with XMLHttpRequest or with hidden iframe. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dispatch Action Strangeness
yes, exactly. If changed the value of the hidden field to graph
That part is working too. If I do a log.debug
(dispatch=+theForm.getDispatch());
it puts out the right value (graph or whatever I clicked in the form)
On 4/18/05, Hubert Rabago [EMAIL PROTECTED] wrote:
IIRC you wanted the graph method to be called because you had
set('graph') in an onclick handler. What does the set('graph')
method do? Does it modify the dispatch form field?
On 4/18/05, David Johnson [EMAIL PROTECTED] wrote:
Any further insights on this? It seems I'm missing something simple here...
I dont want ot have to manually call methods on my action...
help? :)
Is there something beyond the
html:hidden property=dispatch value=error/
that I need (and the hidden field named dispatch)
and of course to have my Action inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from it... that wouldnt make a diffference though correct?
On 4/15/05, David Johnson [EMAIL PROTECTED] wrote:
in my HTML I have
html:hidden property=dispatch value=error/
in my struts config (for the appropriate action) I have
parameter=dispatch
Is there something else I need?
On 4/15/05, Rick Reumann [EMAIL PROTECTED] wrote:
David Johnson wrote the following on 4/15/2005 3:21 PM:
I saw that after I sent it. I have changed it to inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from DispatchAction) but the methods still arent being
called.
You sure you have the parameter property in your action mapping in your
struts config?
set('graph'); I'm assuming is setting a hidden parameter (your dispatch
parameter)... whatever that parameter is, is the one you need also
defined in your action mapping.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-Dave
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Frank W. Zammetti wrote: You lost me Jason... what extra tags are you referring to? My proposal specifically didn't require any new tags, only additions to the existing ones. You previously said: why not just modify the existing Struts tags to have some at least minimal AJAX functionality? But what does that really mean? Simply put, instead of calling some Javascript function on the client in response to, say, the onClick event of a button, we instead call a server-side process, get a response back and update some part of the page. My thought is you'd call normal js events anyway. The js events would call xmlhttprequest. That way we continue to use the same taglibs without any changes necessary. My though is that an HTML input tag doesn't need to know whether its being validated by pure javascript or javascript + xmlhttprequest or fill_in_the_blank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
I think you might be misunderstanding this point. And, I would invite Frank, when he gets time to explain it to you. Jack On 4/18/05, Michael J. [EMAIL PROTECTED] wrote: From wiki: No one should be under the impression that you have to deal in XML or that you have to use the XMLHttpRequest object at all, contrary to the meaning of the AJAX moniker. Not that I really care about the name, but for me you do not use Ajax if you do not use async HTTP calls, either with XMLHttpRequest or with hidden iframe. - 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!
Oh, *that* part of it I agree has to be there or we're talking about something completely different. It was the usage of XML that isn't required, that was my point in writing that. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 3:28 pm, Michael J. said: From wiki: No one should be under the impression that you have to deal in XML or that you have to use the XMLHttpRequest object at all, contrary to the meaning of the AJAX moniker. Not that I really care about the name, but for me you do not use Ajax if you do not use async HTTP calls, either with XMLHttpRequest or with hidden iframe. - 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: Dispatch Action Strangeness
You've confirm that you've changed the action-mapping so that it is now
using your new dispatch action? If that's correct, then I'd say you need
to break at DispatchAction.execute() and step through it to see what's
going on.
Dennis
David Johnson [EMAIL PROTECTED]
04/18/2005 03:28 PM
Please respond to
Struts Users Mailing List user@struts.apache.org
To
Struts Users Mailing List user@struts.apache.org, Hubert Rabago
[EMAIL PROTECTED]
cc
Subject
Re: Dispatch Action Strangeness
yes, exactly. If changed the value of the hidden field to graph
That part is working too. If I do a log.debug
(dispatch=+theForm.getDispatch());
it puts out the right value (graph or whatever I clicked in the form)
On 4/18/05, Hubert Rabago [EMAIL PROTECTED] wrote:
IIRC you wanted the graph method to be called because you had
set('graph') in an onclick handler. What does the set('graph')
method do? Does it modify the dispatch form field?
On 4/18/05, David Johnson [EMAIL PROTECTED] wrote:
Any further insights on this? It seems I'm missing something simple
here...
I dont want ot have to manually call methods on my action...
help? :)
Is there something beyond the
html:hidden property=dispatch value=error/
that I need (and the hidden field named dispatch)
and of course to have my Action inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from it... that wouldnt make a diffference though correct?
On 4/15/05, David Johnson [EMAIL PROTECTED] wrote:
in my HTML I have
html:hidden property=dispatch value=error/
in my struts config (for the appropriate action) I have
parameter=dispatch
Is there something else I need?
On 4/15/05, Rick Reumann [EMAIL PROTECTED] wrote:
David Johnson wrote the following on 4/15/2005 3:21 PM:
I saw that after I sent it. I have changed it to inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from DispatchAction) but the methods still arent being
called.
You sure you have the parameter property in your action mapping in
your
struts config?
set('graph'); I'm assuming is setting a hidden parameter (your
dispatch
parameter)... whatever that parameter is, is the one you need also
defined in your action mapping.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-Dave
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX: Whoa, Nellie!
Ah, I see. In any case this doesn't require new tags. Part of this is I'm not just talking about validation. In fact I think that's about the most pedestrian use of AJAX around! It's the cooler kind of things you can get away with like table sorting, like the example in my article. Not that there aren't 100 ways to do that ;) Your right, the usual JS event handlers fire, but what you do then can get interesting... for instance, do you need to call a function to construct an XML document and send that? Or construct a query string? Or maybe just call a URL with no parameters? And then what happens when the request comes back? There is obviously a JS function to handle it, but what does it do? My proposal and the accompanying example seeks to answer those questions with the typical whatever is in this XML config file answer. There is no way in the world I can account for every possible scenario, but I was trying to put together a generic enough solution so that I could provide many, if not most, of the most common usages and allow them to be used just by playing with the config file. Validation was actually one thing I was NOT specifically going to deal with. Maybe I should though. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 3:37 pm, Jason King said: Frank W. Zammetti wrote: You lost me Jason... what extra tags are you referring to? My proposal specifically didn't require any new tags, only additions to the existing ones. You previously said: why not just modify the existing Struts tags to have some at least minimal AJAX functionality? But what does that really mean? Simply put, instead of calling some Javascript function on the client in response to, say, the onClick event of a button, we instead call a server-side process, get a response back and update some part of the page. My thought is you'd call normal js events anyway. The js events would call xmlhttprequest. That way we continue to use the same taglibs without any changes necessary. My though is that an HTML input tag doesn't need to know whether its being validated by pure javascript or javascript + xmlhttprequest or fill_in_the_blank - 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: Dispatch Action Strangeness
One part I missed was when you said your base action is extending
DispatchAction. What is it that your base action is doing? It could
be conflicting with the dispatch logic.
Hubert
On 4/18/05, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
You've confirm that you've changed the action-mapping so that it is now
using your new dispatch action? If that's correct, then I'd say you need
to break at DispatchAction.execute() and step through it to see what's
going on.
Dennis
David Johnson [EMAIL PROTECTED]
04/18/2005 03:28 PM
Please respond to
Struts Users Mailing List user@struts.apache.org
To
Struts Users Mailing List user@struts.apache.org, Hubert Rabago
[EMAIL PROTECTED]
cc
Subject
Re: Dispatch Action Strangeness
yes, exactly. If changed the value of the hidden field to graph
That part is working too. If I do a log.debug
(dispatch=+theForm.getDispatch());
it puts out the right value (graph or whatever I clicked in the form)
On 4/18/05, Hubert Rabago [EMAIL PROTECTED] wrote:
IIRC you wanted the graph method to be called because you had
set('graph') in an onclick handler. What does the set('graph')
method do? Does it modify the dispatch form field?
On 4/18/05, David Johnson [EMAIL PROTECTED] wrote:
Any further insights on this? It seems I'm missing something simple
here...
I dont want ot have to manually call methods on my action...
help? :)
Is there something beyond the
html:hidden property=dispatch value=error/
that I need (and the hidden field named dispatch)
and of course to have my Action inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from it... that wouldnt make a diffference though correct?
On 4/15/05, David Johnson [EMAIL PROTECTED] wrote:
in my HTML I have
html:hidden property=dispatch value=error/
in my struts config (for the appropriate action) I have
parameter=dispatch
Is there something else I need?
On 4/15/05, Rick Reumann [EMAIL PROTECTED] wrote:
David Johnson wrote the following on 4/15/2005 3:21 PM:
I saw that after I sent it. I have changed it to inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from DispatchAction) but the methods still arent being
called.
You sure you have the parameter property in your action mapping in
your
struts config?
set('graph'); I'm assuming is setting a hidden parameter (your
dispatch
parameter)... whatever that parameter is, is the one you need also
defined in your action mapping.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-Dave
[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!
I should probably post this on the Wiki, but... AJAX is just a new buzzword for an old concept: updating only portions of a web page instead of everything at once. Speaking for myself, I was doing what would now be called AJAX at least five years ago, and I'm talking about in a production app. I didn't use XML, nor did I use XMLHttpRequest at all. I used a hidden frame, as Michael mentions, and some scripting. I can remember (and probably still have!) a proof-of-concept, from around '99 I'd bet, of sending and receving XML and playing with it, both using XMLHttpRequest and not using it. Michael is correct to point out the asynchronous nature of AJAX, because that's what it's all about, whether your talking XML or not, whether you use XMLHttpRequest or not. In case there is any question in anyones' mind, asychronous in this case simply means calls back to the server aside from the usual form submissions. Of course a form submission itself is technically asynchronous, but it has a slightly different meaning when discussing AJAX... instead of being asynchronous relative to some normal passage of time, it is relative to the typical form submissions of a webapp. The key point though is the updating of only portions of a page, or perhaps not even updating anything visible in some cases... maybe for instance you want to every 10 seconds download a list of stock prices and use them when the user tries to submit a trade. Ironically, that's probably a great example of when you SHOULD NOT use AJAX, but I'm trying to illustrate that there is no requirement that anything visual happen. There probably does need to be a more generic term though because AJAX is specifically dealing with asynchronus calls utilizing Javascript and XML... so what if I constuct a simple comma-separated list and use VBScript instead (assuming IE)? It's *technically* not AJAX any more, but the underlying concept is identical. What is it then, AVAC?? :) -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Mon, April 18, 2005 3:38 pm, Dakota Jack said: I think you might be misunderstanding this point. And, I would invite Frank, when he gets time to explain it to you. Jack On 4/18/05, Michael J. [EMAIL PROTECTED] wrote: From wiki: No one should be under the impression that you have to deal in XML or that you have to use the XMLHttpRequest object at all, contrary to the meaning of the AJAX moniker. Not that I really care about the name, but for me you do not use Ajax if you do not use async HTTP calls, either with XMLHttpRequest or with hidden iframe. - 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: Dispatch Action Strangeness
David Johnson wrote: yes, exactly. If changed the value of the hidden field to graph That part is working too. If I do a log.debug (dispatch=+theForm.getDispatch()); it puts out the right value (graph or whatever I clicked in the form) What does the code for your base action (that subclasses DispatchAction) look like? I've never had any issues with DispatchAction or its subclasses, so I'm a little confused as to why it wouldn't work. You probably already posted all of it, but the relevent snippets from struts-config, the JSP, the base action, and the action might be handy again :) Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dispatch Action Strangeness
yeah. this is my Action mapping action path=/PortfolioSummaryAction name=portfolioSummaryForm scope=request input=page.portfolioSummary type=com.foo.struts.PortfolioSummaryAction parameter=dispatch forward name=success path=page.portfolio.summary redirect=true/ forward name=invalidSession path=page.invalidSession redirect=true/ forward name=combineFailed path=page.portfolio.summary redirect=true/ forward name=noDispatch path=page.portfolio.summary redirect=true/!-- FIXME go to real error page-- /action On 4/18/05, Dave Newton [EMAIL PROTECTED] wrote: David Johnson wrote: yes, exactly. If changed the value of the hidden field to graph That part is working too. If I do a log.debug (dispatch=+theForm.getDispatch()); it puts out the right value (graph or whatever I clicked in the form) What does the code for your base action (that subclasses DispatchAction) look like? I've never had any issues with DispatchAction or its subclasses, so I'm a little confused as to why it wouldn't work. You probably already posted all of it, but the relevent snippets from struts-config, the JSP, the base action, and the action might be handy again :) Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Dave [EMAIL PROTECTED]
Re: Dispatch Action Strangeness
the BaseAction has
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
private Log log;
and a constructor that initialized the log object so I can perform
logging in all my actions.
In addition it has a checkAuth() method that makes sure the user is
logged in properly.
On 4/18/05, Hubert Rabago [EMAIL PROTECTED] wrote:
One part I missed was when you said your base action is extending
DispatchAction. What is it that your base action is doing? It could
be conflicting with the dispatch logic.
Hubert
On 4/18/05, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
You've confirm that you've changed the action-mapping so that it is now
using your new dispatch action? If that's correct, then I'd say you need
to break at DispatchAction.execute() and step through it to see what's
going on.
Dennis
David Johnson [EMAIL PROTECTED]
04/18/2005 03:28 PM
Please respond to
Struts Users Mailing List user@struts.apache.org
To
Struts Users Mailing List user@struts.apache.org, Hubert Rabago
[EMAIL PROTECTED]
cc
Subject
Re: Dispatch Action Strangeness
yes, exactly. If changed the value of the hidden field to graph
That part is working too. If I do a log.debug
(dispatch=+theForm.getDispatch());
it puts out the right value (graph or whatever I clicked in the form)
On 4/18/05, Hubert Rabago [EMAIL PROTECTED] wrote:
IIRC you wanted the graph method to be called because you had
set('graph') in an onclick handler. What does the set('graph')
method do? Does it modify the dispatch form field?
On 4/18/05, David Johnson [EMAIL PROTECTED] wrote:
Any further insights on this? It seems I'm missing something simple
here...
I dont want ot have to manually call methods on my action...
help? :)
Is there something beyond the
html:hidden property=dispatch value=error/
that I need (and the hidden field named dispatch)
and of course to have my Action inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from it... that wouldnt make a diffference though correct?
On 4/15/05, David Johnson [EMAIL PROTECTED] wrote:
in my HTML I have
html:hidden property=dispatch value=error/
in my struts config (for the appropriate action) I have
parameter=dispatch
Is there something else I need?
On 4/15/05, Rick Reumann [EMAIL PROTECTED] wrote:
David Johnson wrote the following on 4/15/2005 3:21 PM:
I saw that after I sent it. I have changed it to inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from DispatchAction) but the methods still arent being
called.
You sure you have the parameter property in your action mapping in
your
struts config?
set('graph'); I'm assuming is setting a hidden parameter (your
dispatch
parameter)... whatever that parameter is, is the one you need also
defined in your action mapping.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-Dave
[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]
--
-Dave
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dispatch Action Strangeness
Does it have an execute() method? If so, what does the execute method do?
Hubert
On 4/18/05, David Johnson [EMAIL PROTECTED] wrote:
the BaseAction has
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
private Log log;
and a constructor that initialized the log object so I can perform
logging in all my actions.
In addition it has a checkAuth() method that makes sure the user is
logged in properly.
On 4/18/05, Hubert Rabago [EMAIL PROTECTED] wrote:
One part I missed was when you said your base action is extending
DispatchAction. What is it that your base action is doing? It could
be conflicting with the dispatch logic.
Hubert
On 4/18/05, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
You've confirm that you've changed the action-mapping so that it is now
using your new dispatch action? If that's correct, then I'd say you need
to break at DispatchAction.execute() and step through it to see what's
going on.
Dennis
David Johnson [EMAIL PROTECTED]
04/18/2005 03:28 PM
Please respond to
Struts Users Mailing List user@struts.apache.org
To
Struts Users Mailing List user@struts.apache.org, Hubert Rabago
[EMAIL PROTECTED]
cc
Subject
Re: Dispatch Action Strangeness
yes, exactly. If changed the value of the hidden field to graph
That part is working too. If I do a log.debug
(dispatch=+theForm.getDispatch());
it puts out the right value (graph or whatever I clicked in the form)
On 4/18/05, Hubert Rabago [EMAIL PROTECTED] wrote:
IIRC you wanted the graph method to be called because you had
set('graph') in an onclick handler. What does the set('graph')
method do? Does it modify the dispatch form field?
On 4/18/05, David Johnson [EMAIL PROTECTED] wrote:
Any further insights on this? It seems I'm missing something simple
here...
I dont want ot have to manually call methods on my action...
help? :)
Is there something beyond the
html:hidden property=dispatch value=error/
that I need (and the hidden field named dispatch)
and of course to have my Action inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from it... that wouldnt make a diffference though correct?
On 4/15/05, David Johnson [EMAIL PROTECTED] wrote:
in my HTML I have
html:hidden property=dispatch value=error/
in my struts config (for the appropriate action) I have
parameter=dispatch
Is there something else I need?
On 4/15/05, Rick Reumann [EMAIL PROTECTED] wrote:
David Johnson wrote the following on 4/15/2005 3:21 PM:
I saw that after I sent it. I have changed it to inherit from
org.apache.struts.actions.DispatchAction (actually my BaseAction
inherits from DispatchAction) but the methods still arent being
called.
You sure you have the parameter property in your action mapping in
your
struts config?
set('graph'); I'm assuming is setting a hidden parameter (your
dispatch
parameter)... whatever that parameter is, is the one you need also
defined in your action mapping.
--
Rick
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-Dave
[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]
--
-Dave
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dispatch Action Strangeness
Hubert Rabago wrote: Does it have an execute() method? If so, what does the execute method do? Yeah--what you gave isn't enough. In order to diagnose we must see the code, because on the surface everything appears to be fine. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dispatch Action Strangeness
which part to you need to see? I'm s thankful for any help :) On 4/18/05, Dave Newton [EMAIL PROTECTED] wrote: Hubert Rabago wrote: Does it have an execute() method? If so, what does the execute method do? Yeah--what you gave isn't enough. In order to diagnose we must see the code, because on the surface everything appears to be fine. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Dave [EMAIL PROTECTED]
Re: Dispatch Action Strangeness
David Johnson wrote: which part to you need to see? I'm s thankful for any help :) All of it? What Hubert is asking is whether or not you override the execute method of the DispatchAction subclass, as that could easily munge up the dispatching. That's certainly among my top questions as well. Generally the relevent portions of the struts-config and Action (in your case, the base Action as well) are usually enough. Better too much information than too little, especially if you have a site you can put it on rather than sending it all to the entire list. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
binary view
I have an action in my application that generates a PNG image from some text stored in a session object. My view is very simple: [EMAIL PROTECTED] contentType=image/png% % java.io.OutputStream os = response.getOutputStream(); java.awt.image.BufferedImage buffer = (java.awt.image.BufferedImage) request.getAttribute(imageBuffer); javax.imageio.ImageIO.write(buffer,png,os); os.close(); % Thats it. My action loads imageBuffer with the image data. The first time I load the page I get the error: java.lang.IllegalStateException: getOutputStream() has already been called for this response Is there a better way to accomplish what I am after? I would prefer to load the page one time and have it work, rather than the refresh. Thanks in advance... DW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
content management tool
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]
RE: binary view
The problem is that you're opening the output stream at the beginning of your jsp and then reopening the output stream by calling response.getOutputStream(). I believe you can call response.reset() to fix this problem: % response.reset(); response.setContentType(image/png); java.io.OutputStream os = response.getOutputStream(); java.awt.image.BufferedImage buffer = (java.awt.image.BufferedImage) request.getAttribute(imageBuffer); javax.imageio.ImageIO.write(buffer,png,os); os.flush(); os.close(); % Regards, Thad Smith -Original Message- From: Daniel Watrous [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 4:20 PM To: user@struts.apache.org Subject: binary view I have an action in my application that generates a PNG image from some text stored in a session object. My view is very simple: [EMAIL PROTECTED] contentType=image/png% % java.io.OutputStream os = response.getOutputStream(); java.awt.image.BufferedImage buffer = (java.awt.image.BufferedImage) request.getAttribute(imageBuffer); javax.imageio.ImageIO.write(buffer,png,os); os.close(); % Thats it. My action loads imageBuffer with the image data. The first time I load the page I get the error: java.lang.IllegalStateException: getOutputStream() has already been called for this response Is there a better way to accomplish what I am after? I would prefer to load the page one time and have it work, rather than the refresh. Thanks in advance... DW - 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: binary view
Why even bother with a jsp? You have the response object in your action, just start spewing data into it. Larry On 4/18/05, Daniel Watrous [EMAIL PROTECTED] wrote: I have an action in my application that generates a PNG image from some text stored in a session object. My view is very simple: [EMAIL PROTECTED] contentType=image/png% % java.io.OutputStream os = response.getOutputStream(); java.awt.image.BufferedImage buffer = (java.awt.image.BufferedImage) request.getAttribute(imageBuffer); javax.imageio.ImageIO.write(buffer,png,os); os.close(); % Thats it. My action loads imageBuffer with the image data. The first time I load the page I get the error: java.lang.IllegalStateException: getOutputStream() has already been called for this response Is there a better way to accomplish what I am after? I would prefer to load the page one time and have it work, rather than the refresh. Thanks in advance... DW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: binary view
This might be a good case to write a custom tag. -Original Message- From: Daniel Watrous [mailto:[EMAIL PROTECTED] Sent: Monday, April 18, 2005 5:20 PM To: user@struts.apache.org Subject: binary view I have an action in my application that generates a PNG image from some text stored in a session object. My view is very simple: [EMAIL PROTECTED] contentType=image/png% % java.io.OutputStream os = response.getOutputStream(); java.awt.image.BufferedImage buffer = (java.awt.image.BufferedImage) request.getAttribute(imageBuffer); javax.imageio.ImageIO.write(buffer,png,os); os.close(); % Thats it. My action loads imageBuffer with the image data. The first time I load the page I get the error: java.lang.IllegalStateException: getOutputStream() has already been called for this response Is there a better way to accomplish what I am after? I would prefer to load the page one time and have it work, rather than the refresh. Thanks in advance... DW - 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]
Identify users
Hi: I have a question.I need to check if a user is the one who has permission to a certain action. His role is stored in the database, for example user.isStudent. The whole student object is stored in the session after he logs in successfully . From that point on, every time he sends a request that invokes an action , I need to verify if this student is who he claims he is. I could include a hidden field for example, his email in every page I send back to him and get this property back to verify who he is. I was wondering if this approach is problematic since he could manipulate the hidden field. Any better solutions to that?Thanks a lot! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Using validate() and returning to original page dynamically
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: AJAX: Whoa, Nellie!
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 Stéphane Zuckerman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Rodolfo García Esteban/CYII a écrit : Where do we find information about this marvellous stuff? Rodolfo __ Look for XMLHttpRequest and/or ActiveXObject(Microsoft.XMLHTTP) XML.com and the Apple dev center have good introductory articles about it. Basically, this is a way to make server call from JavaScript via the XMLHttpRequest (Safari/Gecko browsers) or XMLHTTP (Internet Explorer) objects. Thus it enables you to make dynamic calls to refresh some parts of a web page without reloading everything. This is used with gmail for instance. -- Stéphane Zuckerman - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
