Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Frank - Thanks again for all the work you've done on this front! Email the code to me at [EMAIL PROTECTED] I'll take a look over it and commit it to the saf project. If there are some interesting classes, you might want to add them to the JIRA issuse for discussion /Ian Frank W. Zammetti wrote: FYI, for anyone that's interested and been following this discussion, I finally got this all working, just need a few hours tomorrow night to do some final polishing and documentation (not that it'll be perfect out of the gate anyway, but I'd like to get as close as possible). In short, there is a total of seven new classes, 2 Interceptors (AjaxXMLInterceptor and AjaxJSONInterceptor, implementing Interceptor, not AroundInterceptor as I was originally doing), 2 Results (AjaxXMLResult and AjaxJSONResult), 2 marker interfaces (AjaxXMLAware and AjaxJSONAware) and a helper class that the Interceptors both use (AjaxInterceptorHelper). There is also a new dependency introduced, JSON-RPC-Java (http://oss.metaparadigm.com/jsonrpc/) which is used for serializing an Action to JSON (v1.0, which I used, is licensed under ASF 2.0, so shouldn't be a problem there). Technically there is a dependency on the Java classes from json.org as well, but they are included in the JSON-RPC-Java JAR. The classes are currently in the com.opensymphony.webwork.interceptor and com.opensymphony.webwork.result (new) package, I figured they could be moved to the correct SAF2 packages easy enough. I also have a complete WW 2.2.2 sample app built to test this all. It's a simple demonstration of constructing JSON or XML on the client from form entries, sending it to the server, the Action getting populated from that message, and then a response coming back in JSON or XML constructed from the Action's fields. No mapping files required, no extra code in the Action (other than implementing one, or both, of the new marker interfaces), just a modified Interceptor stack and using the new Results. I presume posting this to JIRA is the appropriate route? But, if I upload everything to it, the sample app and all, it's almost 8 megs... better to just post the new code and link to the sample app on my server I assume? Frank Frank W. Zammetti wrote: Argh... just so no one thinks I forgot about this... I've had to work from home all this week for various unforeseen reasons, and of course as a pessimist like myself would expect, the mostly working code got lost since this weekend. Thought there was a copy on my thumb drive, but of course not, copy on PC was since squashed, etc. Typical Murphy's Law. I believe there is an older version sitting on my work PC, so as soon as I get back there (which doesn't look to be tomorrow either), I can get it and figure out what I had fixed subsequent to that. Argh I say, ARGH! That just reminds me to set up SVN on my new home server this weekend! And Jason, I get what you wrote here about the Result, I was planning on refactoring to that before this little setback :) I don't think it would have been a problem per se to render the response in an Interceptor, that seemed like it was going to work, but it did present the problem of mixing and matching XML/JSON as we were discussing, so for that reason alone it would seem to make sense. Thanks for the info on that! Frank Jason Carreira wrote: Ted and Jason, I did see your messages about AroundInterceptor and Result correspondingly... right now, in the interest of simply getting it working, I'm just doing a simple AroundInterceptor using before() and after(), one interceptor for XML and one for JSON (although as I just wrote that it dawned on me that that probably won't work because mixing XML and JSON probably won't work... might have to combine them and allow configuration... I'll see...) I read up on Restults a bit yesterday, and I can certainly see why you'd say that Jason... this still feels to me like something that should really be just an interceptor though... but, the code is at this point generic enough that moving it or putting it in a different form shouldn't be a big deal, so that can be decided later... lemme just get it all working first :) Frank The problem you're having composing the JSON and XML is because the output should be a result. Interceptors don't produce content, that's orthogonal to their usage. Results are all about generating output. What would happen if I configured an Action with the JSON interceptor to read the incoming request and produce output, but also configured the action to have a JSP page as the Result? They can't BOTH write to the output stream. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=32216messageID=63313#63313 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Hi Ian, Your very welcome! It was fun working on it, learned quite a bit about WW in the process... I opened a JIRA ticket that includes everything: http://issues.apache.org/struts/browse/WW-1330 It has a link to a complete webapp demonstrating it (too big to attach to the ticket I thought), but the new code to commit *is* included on the ticket. The comments on the ticket is just a copy of the javadoc overview by the way (I always try and document my work as best I can) and it pretty well describes it all. FYI, I wrote it against WW 2.2.2, and the package structure is based on that as well. I added a new package, c.o.w.result. I wasn't 100% sure what the SAF2 package structure was, that's why I went with the existing WW structure. Feel free to not add that result package if you think there is an existing package for the results, I just thought it might be a good idea going forward should there be other new result types to add. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Mon, June 5, 2006 10:01 am, Ian Roughley wrote: Frank - Thanks again for all the work you've done on this front! Email the code to me at [EMAIL PROTECTED] I'll take a look over it and commit it to the saf project. If there are some interesting classes, you might want to add them to the JIRA issuse for discussion /Ian Frank W. Zammetti wrote: FYI, for anyone that's interested and been following this discussion, I finally got this all working, just need a few hours tomorrow night to do some final polishing and documentation (not that it'll be perfect out of the gate anyway, but I'd like to get as close as possible). In short, there is a total of seven new classes, 2 Interceptors (AjaxXMLInterceptor and AjaxJSONInterceptor, implementing Interceptor, not AroundInterceptor as I was originally doing), 2 Results (AjaxXMLResult and AjaxJSONResult), 2 marker interfaces (AjaxXMLAware and AjaxJSONAware) and a helper class that the Interceptors both use (AjaxInterceptorHelper). There is also a new dependency introduced, JSON-RPC-Java (http://oss.metaparadigm.com/jsonrpc/) which is used for serializing an Action to JSON (v1.0, which I used, is licensed under ASF 2.0, so shouldn't be a problem there). Technically there is a dependency on the Java classes from json.org as well, but they are included in the JSON-RPC-Java JAR. The classes are currently in the com.opensymphony.webwork.interceptor and com.opensymphony.webwork.result (new) package, I figured they could be moved to the correct SAF2 packages easy enough. I also have a complete WW 2.2.2 sample app built to test this all. It's a simple demonstration of constructing JSON or XML on the client from form entries, sending it to the server, the Action getting populated from that message, and then a response coming back in JSON or XML constructed from the Action's fields. No mapping files required, no extra code in the Action (other than implementing one, or both, of the new marker interfaces), just a modified Interceptor stack and using the new Results. I presume posting this to JIRA is the appropriate route? But, if I upload everything to it, the sample app and all, it's almost 8 megs... better to just post the new code and link to the sample app on my server I assume? Frank Frank W. Zammetti wrote: Argh... just so no one thinks I forgot about this... I've had to work from home all this week for various unforeseen reasons, and of course as a pessimist like myself would expect, the mostly working code got lost since this weekend. Thought there was a copy on my thumb drive, but of course not, copy on PC was since squashed, etc. Typical Murphy's Law. I believe there is an older version sitting on my work PC, so as soon as I get back there (which doesn't look to be tomorrow either), I can get it and figure out what I had fixed subsequent to that. Argh I say, ARGH! That just reminds me to set up SVN on my new home server this weekend! And Jason, I get what you wrote here about the Result, I was planning on refactoring to that before this little setback :) I don't think it would have been a problem per se to render the response in an Interceptor, that seemed like it was going to work, but it did present the problem of mixing and matching XML/JSON as we were discussing, so for that reason alone it would seem to make sense. Thanks for the info on that! Frank Jason Carreira wrote: Ted and Jason, I did see your messages about AroundInterceptor and Result correspondingly... right now, in the interest of simply getting it working, I'm just doing a simple AroundInterceptor using before() and after(), one interceptor for XML and one for JSON (although as I just wrote that it dawned on
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Since this donation includes standalone classes, we should ask Frank to file a CLA to cover this donation and any others. * http://www.apache.org/licenses/icla.txt I don't think we need to wait for it to go on file before accepting the donation, but Frank should confirm that he is willing and able to file a ICLA, and then let us know when he has faxed it in. -Ted. On 6/5/06, Ian Roughley [EMAIL PROTECTED] wrote: Frank - Thanks again for all the work you've done on this front! Email the code to me at [EMAIL PROTECTED] I'll take a look over it and commit it to the saf project. If there are some interesting classes, you might want to add them to the JIRA issuse for discussion /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Thanks Ted, I just faxed it over a minute ago... I just hope whoever looks at it can read my handwriting, I have *seriously* atrocious penmanship! It still needs to be sent in, correct? Frank On Mon, June 5, 2006 1:20 pm, Ted Husted wrote: Since this donation includes standalone classes, we should ask Frank to file a CLA to cover this donation and any others. * http://www.apache.org/licenses/icla.txt I don't think we need to wait for it to go on file before accepting the donation, but Frank should confirm that he is willing and able to file a ICLA, and then let us know when he has faxed it in. -Ted. On 6/5/06, Ian Roughley [EMAIL PROTECTED] wrote: Frank - Thanks again for all the work you've done on this front! Email the code to me at [EMAIL PROTECTED] I'll take a look over it and commit it to the saf project. If there are some interesting classes, you might want to add them to the JIRA issuse for discussion /Ian - 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: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
This looks weird, because as far as I knew contributions submitted through JIRA are already granting the copyright if not otherwise expressed. ./alex -- .w( the_mindstorm )p. On 6/5/06, Ted Husted [EMAIL PROTECTED] wrote: Since this donation includes standalone classes, we should ask Frank to file a CLA to cover this donation and any others. * http://www.apache.org/licenses/icla.txt I don't think we need to wait for it to go on file before accepting the donation, but Frank should confirm that he is willing and able to file a ICLA, and then let us know when he has faxed it in. -Ted. On 6/5/06, Ian Roughley [EMAIL PROTECTED] wrote: Frank - Thanks again for all the work you've done on this front! Email the code to me at [EMAIL PROTECTED] I'll take a look over it and commit it to the saf project. If there are some interesting classes, you might want to add them to the JIRA issuse for discussion /Ian - 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: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
For patches to existing classes, we do operate on the premise that there's an implicit grant, but when people start donating entire classes, we like to have an explicit licensing agreement on file. -Ted. On 6/5/06, Alexandru Popescu [EMAIL PROTECTED] wrote: This looks weird, because as far as I knew contributions submitted through JIRA are already granting the copyright if not otherwise expressed. ./alex -- .w( the_mindstorm )p. On 6/5/06, Ted Husted [EMAIL PROTECTED] wrote: Since this donation includes standalone classes, we should ask Frank to file a CLA to cover this donation and any others. * http://www.apache.org/licenses/icla.txt I don't think we need to wait for it to go on file before accepting the donation, but Frank should confirm that he is willing and able to file a ICLA, and then let us know when he has faxed it in. -Ted. On 6/5/06, Ian Roughley [EMAIL PROTECTED] wrote: Frank - Thanks again for all the work you've done on this front! Email the code to me at [EMAIL PROTECTED] I'll take a look over it and commit it to the saf project. If there are some interesting classes, you might want to add them to the JIRA issuse for discussion /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
FYI, for anyone that's interested and been following this discussion, I finally got this all working, just need a few hours tomorrow night to do some final polishing and documentation (not that it'll be perfect out of the gate anyway, but I'd like to get as close as possible). In short, there is a total of seven new classes, 2 Interceptors (AjaxXMLInterceptor and AjaxJSONInterceptor, implementing Interceptor, not AroundInterceptor as I was originally doing), 2 Results (AjaxXMLResult and AjaxJSONResult), 2 marker interfaces (AjaxXMLAware and AjaxJSONAware) and a helper class that the Interceptors both use (AjaxInterceptorHelper). There is also a new dependency introduced, JSON-RPC-Java (http://oss.metaparadigm.com/jsonrpc/) which is used for serializing an Action to JSON (v1.0, which I used, is licensed under ASF 2.0, so shouldn't be a problem there). Technically there is a dependency on the Java classes from json.org as well, but they are included in the JSON-RPC-Java JAR. The classes are currently in the com.opensymphony.webwork.interceptor and com.opensymphony.webwork.result (new) package, I figured they could be moved to the correct SAF2 packages easy enough. I also have a complete WW 2.2.2 sample app built to test this all. It's a simple demonstration of constructing JSON or XML on the client from form entries, sending it to the server, the Action getting populated from that message, and then a response coming back in JSON or XML constructed from the Action's fields. No mapping files required, no extra code in the Action (other than implementing one, or both, of the new marker interfaces), just a modified Interceptor stack and using the new Results. I presume posting this to JIRA is the appropriate route? But, if I upload everything to it, the sample app and all, it's almost 8 megs... better to just post the new code and link to the sample app on my server I assume? Frank Frank W. Zammetti wrote: Argh... just so no one thinks I forgot about this... I've had to work from home all this week for various unforeseen reasons, and of course as a pessimist like myself would expect, the mostly working code got lost since this weekend. Thought there was a copy on my thumb drive, but of course not, copy on PC was since squashed, etc. Typical Murphy's Law. I believe there is an older version sitting on my work PC, so as soon as I get back there (which doesn't look to be tomorrow either), I can get it and figure out what I had fixed subsequent to that. Argh I say, ARGH! That just reminds me to set up SVN on my new home server this weekend! And Jason, I get what you wrote here about the Result, I was planning on refactoring to that before this little setback :) I don't think it would have been a problem per se to render the response in an Interceptor, that seemed like it was going to work, but it did present the problem of mixing and matching XML/JSON as we were discussing, so for that reason alone it would seem to make sense. Thanks for the info on that! Frank Jason Carreira wrote: Ted and Jason, I did see your messages about AroundInterceptor and Result correspondingly... right now, in the interest of simply getting it working, I'm just doing a simple AroundInterceptor using before() and after(), one interceptor for XML and one for JSON (although as I just wrote that it dawned on me that that probably won't work because mixing XML and JSON probably won't work... might have to combine them and allow configuration... I'll see...) I read up on Restults a bit yesterday, and I can certainly see why you'd say that Jason... this still feels to me like something that should really be just an interceptor though... but, the code is at this point generic enough that moving it or putting it in a different form shouldn't be a big deal, so that can be decided later... lemme just get it all working first :) Frank The problem you're having composing the JSON and XML is because the output should be a result. Interceptors don't produce content, that's orthogonal to their usage. Results are all about generating output. What would happen if I configured an Action with the JSON interceptor to read the incoming request and produce output, but also configured the action to have a JSP page as the Result? They can't BOTH write to the output stream. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=32216messageID=63313#63313 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it!
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Argh... just so no one thinks I forgot about this... I've had to work from home all this week for various unforeseen reasons, and of course as a pessimist like myself would expect, the mostly working code got lost since this weekend. Thought there was a copy on my thumb drive, but of course not, copy on PC was since squashed, etc. Typical Murphy's Law. I believe there is an older version sitting on my work PC, so as soon as I get back there (which doesn't look to be tomorrow either), I can get it and figure out what I had fixed subsequent to that. Argh I say, ARGH! That just reminds me to set up SVN on my new home server this weekend! And Jason, I get what you wrote here about the Result, I was planning on refactoring to that before this little setback :) I don't think it would have been a problem per se to render the response in an Interceptor, that seemed like it was going to work, but it did present the problem of mixing and matching XML/JSON as we were discussing, so for that reason alone it would seem to make sense. Thanks for the info on that! Frank Jason Carreira wrote: Ted and Jason, I did see your messages about AroundInterceptor and Result correspondingly... right now, in the interest of simply getting it working, I'm just doing a simple AroundInterceptor using before() and after(), one interceptor for XML and one for JSON (although as I just wrote that it dawned on me that that probably won't work because mixing XML and JSON probably won't work... might have to combine them and allow configuration... I'll see...) I read up on Restults a bit yesterday, and I can certainly see why you'd say that Jason... this still feels to me like something that should really be just an interceptor though... but, the code is at this point generic enough that moving it or putting it in a different form shouldn't be a big deal, so that can be decided later... lemme just get it all working first :) Frank The problem you're having composing the JSON and XML is because the output should be a result. Interceptors don't produce content, that's orthogonal to their usage. Results are all about generating output. What would happen if I configured an Action with the JSON interceptor to read the incoming request and produce output, but also configured the action to have a JSP page as the Result? They can't BOTH write to the output stream. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=32216messageID=63313#63313 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Ted and Jason, I did see your messages about AroundInterceptor and Result correspondingly... right now, in the interest of simply getting it working, I'm just doing a simple AroundInterceptor using before() and after(), one interceptor for XML and one for JSON (although as I just wrote that it dawned on me that that probably won't work because mixing XML and JSON probably won't work... might have to combine them and allow configuration... I'll see...) I read up on Restults a bit yesterday, and I can certainly see why you'd say that Jason... this still feels to me like something that should really be just an interceptor though... but, the code is at this point generic enough that moving it or putting it in a different form shouldn't be a big deal, so that can be decided later... lemme just get it all working first :) Frank The problem you're having composing the JSON and XML is because the output should be a result. Interceptors don't produce content, that's orthogonal to their usage. Results are all about generating output. What would happen if I configured an Action with the JSON interceptor to read the incoming request and produce output, but also configured the action to have a JSP page as the Result? They can't BOTH write to the output stream. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=32216messageID=63313#63313 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Thanks guys... quick update... I took yesterday off, so I'm not quite as
far as I would have liked :) It *is* memorial day weekend after all!
However, I did on Friday get reasonably far... at this moment, I have
XML input working for simple (i.e., non-collection) Action fields, as
well as output (although I think the output part needs a little
tightening up). Doing JSON will just be a matter of taking the existing
class and modifying it for JSON rather than XML, the basic outline is
the same.
On a side note, is there any code under Apache anywhere to parse and
create JSON server-side yet? Might make a reasonable Commons component,
although I'm not sure it's really big enough for that :) (Probably
would fit better in Silk would be my guess)
I may work on it a bit more tonight, not sure yet... have some friends
coming over, so it might turn into a do nothing productive night :)
Ted and Jason, I did see your messages about AroundInterceptor and
Result correspondingly... right now, in the interest of simply getting
it working, I'm just doing a simple AroundInterceptor using before() and
after(), one interceptor for XML and one for JSON (although as I just
wrote that it dawned on me that that probably won't work because mixing
XML and JSON probably won't work... might have to combine them and allow
configuration... I'll see...)
I read up on Restults a bit yesterday, and I can certainly see why you'd
say that Jason... this still feels to me like something that should
really be just an interceptor though... but, the code is at this point
generic enough that moving it or putting it in a different form
shouldn't be a big deal, so that can be decided later... lemme just get
it all working first :)
Frank
Ted Husted wrote:
The AroundInterceptor is an abstraction (that we've recently discussed
deprecating).
The cannonical idiom is to to call {{invocaton.invoke();}} to separate
any before code from any after code. The invoke method let any
other Interceptors and the Action fire.
The simplest example might from be the XWork TimerInterceptor:
long startTime = System.currentTimeMillis();
String result = invocation.invoke();
long executionTime = System.currentTimeMillis() - startTime;
-Ted.
On 5/25/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
See, I learned something already... I thought there was a difference
between Interceptors that fire before and after an Action, now I see it's
just before() and after() methods of AroundInterceptor, so it's just two
Interceptors, AjaxXMLIOInterceptor and AjaxJSONIOInterceptor. This is
*already* a worthwile exercise! :)
Frank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
The AroundInterceptor is an abstraction (that we've recently discussed
deprecating).
The cannonical idiom is to to call {{invocaton.invoke();}} to separate
any before code from any after code. The invoke method let any
other Interceptors and the Action fire.
The simplest example might from be the XWork TimerInterceptor:
long startTime = System.currentTimeMillis();
String result = invocation.invoke();
long executionTime = System.currentTimeMillis() - startTime;
-Ted.
On 5/25/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
See, I learned something already... I thought there was a difference
between Interceptors that fire before and after an Action, now I see it's
just before() and after() methods of AroundInterceptor, so it's just two
Interceptors, AjaxXMLIOInterceptor and AjaxJSONIOInterceptor. This is
*already* a worthwile exercise! :)
Frank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
HTH, Ted.
* http://www.husted.com/struts/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
So, you are saying that your preference would be to include no ajax integration and leave the framework and let users integrate this as required - either directly in the HTML or by creating custom themes? /Ian -- From Down Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ [EMAIL PROTECTED] wrote: I'm going to take a moment to chime in here as I've been watching this thread develop. I'm going to come out in the open and say I've never used DWR or even looked at it's documentation. When I've used ajax functionality in the past we've simply made the XmlHttpRequest hit an action that in turn hits a JSP page with the contentType set to xml. I've done this on several different apps and it always works fine. We even created a modified interceptor stack that stripped out the stuff we didn't need and left it to the basics like authentication, validation, etc. Furthermore using a JSP page as the result we had access to all the taglibs we needed. I can see where this may get a bit heavy if you're doing a lot of XmlHttpRequests (e.g. in a Google Suggest type situation) however I think for the majority of apps it should work fine. -Brian On Wed, May 24, 2006 12:32 pm, Alexandru Popescu wrote: On 5/24/06, Joe Germuska [EMAIL PROTECTED] wrote: At 11:55 AM -0400 5/24/06, Frank W. Zammetti wrote: On Wed, May 24, 2006 11:12 am, Joe Germuska wrote: Forgive me if this has been covered elsewhere, but I'm still confused about why someone would want to integrate DWR with Struts? I've only used it a bit, but in each case, I didn't really see much value in coaxing it to work through Struts' request processing model. They co-exist quite peacefully in a webapp without needing to know anything about each other. I think I can answer that by asking what you would want DWR to call? I would say that in a properly-constructed webapp, you have a business facade, and that is what you would want to call via DWR. In that case, I would tend to agree, integration probably isn't a big gain. If you are intent on calling Actions though, that's where I think integration makes sense... but if you want to model best practices, then you have to ask why would you be intent on calling Actions? I'm not trying to build walls so that people can't just get-the-job-done, but I do know from experience that people tend to overload Actions with too much business responsibility, and integrating DWR with Struts would only encourage that. Would you rather prefer to have your requests served directly by your services? Or by the domain model objects? I think that an action is a pretty good idea of a gateway. I tend to view an pplication as a collection of loosely-coupled services, and an Action is the gateway into a given service. The Action is still doing little other than delegating to some business class, but it's still the starting point that the external world (i.e., the client-side of my app) sees. To that way of thinking, making a call via DWR should go to an Action, not directly to the business facade, because it's really just a different calling syntax to the same service. But then you raise the question you had earlier, which is that Actions are generally written so that they can assume certain context which is established by Struts before they are called; duplicating all of that behavior in DWR seems peculiar at best. I think you are looking in the wrong direction here. Things are much more simpler than you imagine and they need almost no duplication. I have done this... and the proof is online and working. All my teammates were very happy with this solution and it brought a lot of reusability in our sourcecode. I would think it probably better to advise people to use ServletFilters where they want common behavior on every request. Then what's the point of Webwork? :) Interceptors are quite akin to filters conceptually, yet we're all thrilled with the idea of interceptors in SAF2. But we're thrilled with interceptors when we have a common process for receiving input (http request parameters) and a roughly common process for responding (by dispatching to a view). A DWR request has neither of these, and it seems like square pegs and round holes to try to get a DWR request to fit into a Struts request-handling process. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com I guess that for some the square pegs are not square or at least they fit extremely well into the round wholes :-). ./alex -- :Architect of InfoQ.com: .w( the_mindstorm )p. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Ian Roughley wrote: So, you are saying that your preference would be to include no ajax integration and leave the framework and let users integrate this as required - either directly in the HTML or by creating custom themes? /Ian No, I definitely would love to see ajax support...I just think it needs to be done right. Integrating DWR looks like it might get a bit messy. Taking ideas from DWR, maybe even some of the code and/or the js libs, and building the support directly into SAF2 would be a better option. That way the look and feel of writing ajax enabled actions is the same as writing other actions. This keeps the SAF2 code simple (e.g. you don't need to worry about the glue holding together SAF2 and DWR breaking when a new version of DWR comes out, developers don't need to jump between the DWR codebase and SAF2 codebase) and will be easier for users when configuring their apps (everything is configured in xwork.xml or annotations, no dwr.xml, no servlet extra config in web.xml, etc.). That's just my two cents, I know it's kind of reinventing the wheel but I think it would definitely pay off in the end. Brian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
On 5/24/06, Joe Germuska [EMAIL PROTECTED] wrote: but if you want to model best practices, then you have to ask why would you be intent on calling Actions? I'm not trying to build walls so that people can't just get-the-job-done, but I do know from experience that people tend to overload Actions with too much business responsibility, and integrating DWR with Struts would only encourage that. In SAF1 putting too much on Actions is considered a bad idea because those Actions are coupled to the web layer. Actions are used as an adapter between HTTP and the business logic, and we find, in practice, it's a bad idea to overload a SAF1 Action with additional responsibilities. In SAF2, Actions are not coupled to the web layer. Interceptors do the HTTP adapting. A SAF2 Action is the next best thing to a POJO. It's not correct to assume that every bad practice with a SAF1 Action is also going to be a bad practice with a SAF2 Action. One could even construct the business facade with XWork Actions and use those Actions in *any* programming environment. SAF2 Actions can be invoked and tested in isolation, just like any POJO facade. Right now, I'm constructing my facades with CoR Commands, but I could also see doing the same with SAF2 Actions. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Brian Dittmer wrote: Ian Roughley wrote: So, you are saying that your preference would be to include no ajax integration and leave the framework and let users integrate this as required - either directly in the HTML or by creating custom themes? /Ian No, I definitely would love to see ajax support...I just think it needs to be done right. Integrating DWR looks like it might get a bit messy. Taking ideas from DWR, maybe even some of the code and/or the js libs, and building the support directly into SAF2 would be a better option. That way the look and feel of writing ajax enabled actions is the same as writing other actions. But this IS the goal. The action will be exactly the same as writing non-ajax called actions - the data may potentially be populated differently. This keeps the SAF2 code simple (e.g. you don't need to worry about the glue holding together SAF2 and DWR breaking when a new version of DWR comes out, developers don't need to jump between the DWR codebase and SAF2 codebase) We will use DWR under-the-covers to provide the glue - it is mentioned here only because it is the dev list and those on the list are most likely interested in the enabling technology. The problem found with using dojo is that the user is pulled into the dojo source, and way too often. I'm not sure that re-inventing the wheel is a good idea, but we will control the integration and upgrades to DWR and work closely with Joe to ensure that the are no issues with releases. and will be easier for users when configuring their apps (everything is configured in xwork.xml or annotations, no dwr.xml, no servlet extra config in web.xml, etc.). This is also the case - my reading the package/action configuration there is NO additional DWR configuration on a per action case. There may be an additional web.xml servlet entry, but I think this is acceptable. That's just my two cents, I know it's kind of reinventing the wheel but I think it would definitely pay off in the end. Brian - 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: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
No, I definitely would love to see ajax support...I just think it needs to be done right. Integrating DWR looks like it might get a bit messy. Taking ideas from DWR, maybe even some of the code and/or the js libs, and building the support directly into SAF2 would be a better option. That way the look and feel of writing ajax enabled actions is the same as writing other actions. This keeps the SAF2 code simple (e.g. you don't need to worry about the glue holding together SAF2 and DWR breaking when a new version of DWR comes out, developers don't need to jump between the DWR codebase and SAF2 codebase) and will be easier for users when configuring their apps (everything is configured in xwork.xml or annotations, no dwr.xml, no servlet extra config in web.xml, etc.). That's just my two cents, I know it's kind of reinventing the wheel but I think it would definitely pay off in the end. Brian Well, I don't think anyone wants to do it wrong ;-) This is like the issue with XWork in SAF 2. SAF 2 is still going to be built on XWork, like WebWork is, but you're just not going to have to SEE it. We could do the same with DWR. We can make the capabilities of DWR available without having to make you have a dwr.xml file, etc. What's more, with JDK5 and annotations, we could just let you tag your actions as @AjaxEndpoint or something (maybe @AjaxList for things that provide a type-ahead list, etc)? I'm still waiting to see how this plays out... I've been a big proponent of Dojo and built several Dojo widgets, but I understand that it can be tricky and not as easy to use as we'd all like. I think there'll be room for different strategies and implementations, and we'll figure it out as we go. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=32216messageID=62655#62655 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
On 5/25/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Thu, May 25, 2006 2:12 pm, Jason Carreira wrote: I'm still waiting to see how this plays out... I've been a big proponent of Dojo and built several Dojo widgets, but I understand that it can be tricky and not as easy to use as we'd all like. I think there'll be room for different strategies and implementations, and we'll figure it out as we go. It's been talked about here, but I don't know how much interest there might be... At this moment I'm grabbing the code I started and intend to finish it this weekend... My plan is to create 4 interceptors. Two for input and two for output, one each for XML and one each for JSON. How I envision it working is that let's say for example you want to send XML to an Action and get JSON back... ok, so you add the (a) AjaxXMLInputInterceptor and (b) AjaxJsonOutputInterceptor to the stack... On input, (a) determines (not quite sure how yet) that the request has XML in the request body. So it gets it, parses it, and sets the fields on the Action as I outlined yesterday. I would expect a well-behaved client to set the content type on the incoming request to text/xml for XML content, so you should be able to check that. Likewise, isn't JSON content supposed to be sent with text/javascript? On output, (b) takes the Action and generates JSON from its fields. And you should, of course, set the correct content type on the response too. Craig At least initially, the only added config is the new interceptors. There are some obvious ways to expand this, and some obvious problems, but for a first pass I think it's enough. I believe this will allow you to make Ajax calls to an Action from any Ajax code, without much of any extra work on your part. It should also allow for XML/JSON responses, at least simplistically, without any extra work. Does this sound reasonable to anyone? I'm going to go ahead and do it in any case as it is my first try at writing an interceptor, and also the first time I'm doing anything that requires even minimal internal knowledge of XW/WW, so it should be a learning experience if nothing else. I may be missing something, but it seems like it might be useful too :) Frank - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=32216messageID=62655#62655 - 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: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
On Thu, May 25, 2006 2:47 pm, Craig McClanahan wrote: I would expect a well-behaved client to set the content type on the incoming request to text/xml for XML content, so you should be able to check that. Yes, I think that's a reasonable assumption (something, I'm ashamed to say, my Ajax code doesn't do!). Doesn't sound at all like an unreasonable requirement either. Likewise, isn't JSON content supposed to be sent with text/javascript? Not sure, but I'll check on that. It definitely *sounds* right, and again, probably isn't an unreasonable requirement in any case. I was actually thinking of a String property in the Action that defines what type the request is, but your answer is I think definitely better. On output, (b) takes the Action and generates JSON from its fields. And you should, of course, set the correct content type on the response too. Yes, agreed. *That* I usually do at least :) Craig Thanks Craig, I think your suggestions will defnitely make it work out better. Off to work I go now :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
On Thu, May 25, 2006 2:30 pm, Frank W. Zammetti wrote: My plan is to create 4 interceptors. Two for input and two for output, one each for XML and one each for JSON. See, I learned something already... I thought there was a difference between Interceptors that fire before and after an Action, now I see it's just before() and after() methods of AroundInterceptor, so it's just two Interceptors, AjaxXMLIOInterceptor and AjaxJSONIOInterceptor. This is *already* a worthwile exercise! :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
Likewise, isn't JSON content supposed to be sent with text/javascript? actually, no, application/json text/* types are meant to be things that are more human readable, despite the historic reality of text/javascript http://www.ietf.org/internet-drafts/draft-crockford-jsonorg-json-04.txt Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
On 5/25/06, Joe Germuska [EMAIL PROTECTED] wrote: Likewise, isn't JSON content supposed to be sent with text/javascript? actually, no, application/json text/* types are meant to be things that are more human readable, despite the historic reality of text/javascript http://www.ietf.org/internet-drafts/draft-crockford-jsonorg-json-04.txt Ah ... thanks Joe. I had looked around the JSON site for an authoritative statement on this, but hadn't found this one. Joe Craig
[Fwd: Re: JavaOne Ajax Discussion]
-- From Down Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ ---BeginMessage--- Frank W. Zammetti wrote: On Tue, May 23, 2006 2:57 pm, Ian Roughley wrote: What we came up with is: 1. Struts2 should be able to work generically as a data source for any ajax client. This would entail being able to return HTML and XML results, but also JSON results. Additionally, as well as populating the action from the HttpServletRequest we will look into populating it from JSON and XML (this could be tricky as the XML structure would need to be defined). Argh, you guys beat me to the punch! Coincidentally, I had the very early beginnings of code to do exactly this starting to cooking over the weekend :) So I guess you can count me as supportive of the idea! I had taken the cop-out approach though... any field in the Action where a matching element is found anywhere in the XML, as long as the element only appears once, is populated. For elements that appear multiple times, it looks for a Collection or array with a matching name and populates it. This saves you from having to define the XML structure outright, and should work the same basic way for JSON as well. The obvious problem is that it's a little *too* flexible perhaps... I was thinking of providing a simple mapping file that could be read for any Action mapping, something like this: myAction firstName/ children firstName/ firstName/ /children /myAction My thinking was to create a DTD on-the-fly from this, validate the incoming request against it, and then pluck the values out and populate the Action, using the same basic logic as I outlined above. As I wrote this paragraph, it occurred to me that just providing a DTD straight away would probably be sufficient. I think it might be easier on developers those to actually write the XML they expect to receive and save them (as easy as it generally is) to write a DTD or schema. I think a separate mapping file adds a little too much complexity. Initially my thought was to use an XML format similar to that which XStream produces (very similar to what you have) where an attribute defined at a particular level will be set on the corresponding action/object graph. 2. Struts2 should limit the number of ajax libraries it uses. I would hope you mean limit what libraries it uses by default, not limit what libraries it *can* use ;) (I know you do) correct - there may be a need to add in others (perhaps even dojo) for very specific tasks. It was agreed to use DWR as the core library. Cool! I'm a big fan of DWR, I think that's a fantastic decision. Is the idea to have the DWR servlet running in the same context as the WW app, or somehow more directly integrate DWR into WW so the servlet isn't necessary? I would think a filter approach could work here, without thinking about it very much. It would also keep WW configuration as far as web.xml goes as simple as can be. Joe thought that a Struts2 creator that read could read existing Struts2 configuration files, and expose a package would be fairly simple to do. This would avoid additional configurations. So by default all the Actions would be exposed as, in essence, service endpoints, in this package? I'm not sure I like that, sounds like a potential security nightmare. How do you see this as a security risk? Actions are by default endpoints - they just take URL/form parameters rather than XML. This would not be all actions, but actions from a specific package/namespace (URL path). When developing ajax webwork/strut2 applications I find I develop them this way anyway - to remove the sitemesh decoration. Or would you still have to enable what can be accessed? If you have to still write config to enable things anyway, I'm not sure how much it would save. I'd like to hear more about how Joe envisions this working. 3. We should get out off the business of simply wrapping existing widgets / components when we add no additional benefit to users. Defining this distinction is a little harder. The easy examples are obtaining remote content, providing ajax-based select lists (with backing actions), data backed tables and mouse-over tips (obtained via remote content) - things that need interaction with the server-side. Ok... what does everyone think? I think anyone that makes an Ajax call to retrieve tooltip text is inherently evil :) LOL I kid, I kid. Seriously though, it's very easy to abuse Ajax and wind up with a server ground to its knees when the load gets high enough. Even though each Ajax request is generally smaller and easier to generate on the server resource-wise than a full page refresh, I think it is good to try and dissuade people from doing things like
Re: JavaOne Ajax Discussion
Animesh, I'm a little confused by your comments below. Currently the ajax validation uses DWR and returns a value from the server-side java - take a look at the DWRValidator class. Are you talking about direct remoting, or the new comet functionality? I think the first thing that needs to be undertaken is to properly define the components that will be ajax-enabled. We have a couple of these already, but I'm sure there are others that people want. Does anyone know if Joe is listening on this list? Perhaps he can better answer the concerns? /Ian -- From Down Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ [EMAIL PROTECTED] wrote: Hi Ian, I think using DWR as the core library will come up with some problems. For example How do you get the return value for the javascript function you call? (if receiveMessages() returns something ) How do you switch between polling and Comet? Solution (From forum) Right now you return values are not handled automatically - there is a slightly manual solution where you arrange for your Javascript to call a remoted method with the reply. You can change the method currently using the following: DWREngine._pollComet = true; We'll have a better method for this in the next release. Any Comments? Regards, Animesh Saxena RR Donnelley Wipro Technologies I don't believe in fear, I don't believe in faith, I don't believe in anything that I can't break. -Original Message- From: Ian Roughley [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 12:28 AM To: dev@struts.apache.org Subject: JavaOne Ajax Discussion Hi everyone, Wanted to document the discussion we had at JavaOne regarding ajax support for Struts2. In attendance were Pat, myself and Martin from the committers group, as well as Joe (from DWR) and a couple of other people (my apologies for not writing down names). The discussion focused around a couple of main points, these were: 1. There have been several cases lately that the ajax support was not what users expected. 2. Dojo does not necessarily work the way that you would expect, making debugging and new user orientation more difficult than needed. 3. Struts2 should provide a benefit to the user and not just wrap pre-existing widgets/components What we came up with is: 1. Struts2 should be able to work generically as a data source for any ajax client. This would entail being able to return HTML and XML results, but also JSON results. Additionally, as well as populating the action from the HttpServletRequest we will look into populating it from JSON and XML (this could be tricky as the XML structure would need to be defined). 2. Struts2 should limit the number of ajax libraries it uses. It was agreed to use DWR as the core library. Joe thought that a Struts2 creator that read could read existing Struts2 configuration files, and expose a package would be fairly simple to do. This would avoid additional configurations. Ajax integration via dojo would continue via an independent struts-dojo project. 3. We should get out off the business of simply wrapping existing widgets / components when we add no additional benefit to users. Defining this distinction is a little harder. The easy examples are obtaining remote content, providing ajax-based select lists (with backing actions), data backed tables and mouse-over tips (obtained via remote content) - things that need interaction with the server-side. Ok... what does everyone think? /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne Ajax Discussion
I am somehow a little confused by some of the comments... pls see inlined On 5/23/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Tue, May 23, 2006 2:57 pm, Ian Roughley wrote: Joe thought that a Struts2 creator that read could read existing Struts2 configuration files, and expose a package would be fairly simple to do. This would avoid additional configurations. So by default all the Actions would be exposed as, in essence, service endpoints, in this package? I'm not sure I like that, sounds like a potential security nightmare. Or would you still have to enable what can be accessed? If you have to still write config to enable things anyway, I'm not sure how much it would save. I'd like to hear more about how Joe envisions this working. Not sure why it would be a security nightmare, because the actions are already there, so somebody wanting to call them will however have access to them. Now, it falls to the way you write your actions: are they safe-written, than try and call me. I am getting the feeling I am missing something :-(. I think anyone that makes an Ajax call to retrieve tooltip text is inherently evil :) LOL I kid, I kid. Seriously though, it's very easy to abuse Ajax and wind up with a server ground to its knees when the load gets high enough. Even though each Ajax request is generally smaller and easier to generate on the server resource-wise than a full page refresh, I think it is good to try and dissuade people from doing things like getting tooltip text from the server as a best practice, and therefor not providing things in the framework that makes it too easy. After all, if your going to use Javascript to retrieve a tooltip, why not just have it on the client and generate it there? It's script either way. I am not sure how using Ajax can bring your server down. As you say, Ajax calls are generally smaller, and I cannot see a way how you can stop a bad developer to not take his tooltips from the server if he really wants it. This is something that I think is called good practice, and as we already know there will always be guys that are not following it. cheers, ./alex -- :Architect of InfoQ.com: .w( the_mindstorm )p. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne Ajax Discussion
On 5/24/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, May 24, 2006 9:46 am, Alexandru Popescu wrote: I am somehow a little confused by some of the comments... pls see inlined What, me confusing?!?!? sarcasmNNNOOO.../sarcasm ;) On 5/23/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Tue, May 23, 2006 2:57 pm, Ian Roughley wrote: Joe thought that a Struts2 creator that read could read existing Struts2 configuration files, and expose a package would be fairly simple to do. This would avoid additional configurations. So by default all the Actions would be exposed as, in essence, service endpoints, in this package? I'm not sure I like that, sounds like a potential security nightmare. Or would you still have to enable what can be accessed? If you have to still write config to enable things anyway, I'm not sure how much it would save. I'd like to hear more about how Joe envisions this working. Not sure why it would be a security nightmare, because the actions are already there, so somebody wanting to call them will however have access to them. Now, it falls to the way you write your actions: are they safe-written, than try and call me. I am getting the feeling I am missing something :-(. Yes, Ian raised the same question... Here's what I was thinking... The way DWR works today, it instantiates and makes direct calls on some class, whether an Action or otherwise, it doesn't know or care. Note that this isn't an HTTP request, so it isn't going through any filters, interceptors, container-managed security, etc (and the class may or may not be part of a webapp to begin with of course). This is what I think might be (and I may be wrong) a security problem... Assuming we're talking about exposing Actionst... An Action isn't really just exposed in a typical webapp because an HTTP request has to go through whatever security you have set up. Many of us believe that externalized security is a best practice, so our Actions, indeed all our application code, doesn't have any security written into it, and we use some external security system (CMS, Netegrity, just some filter, whatever). Exposing Actions via DWR would open them up where they weren't open before because DWR would instantiate them and call methods on them, thereby bypassing any externalized security. A normal request to an Action doesn't bypass any of this. Even if you have security coded into the Actions, are you checking things on each method call? If not, I think it's still a (potential) security problem because DWR is going to allow direct method calls. Obviously my concern can be dismissed by insisting people code security into their Actions, but I don't think that's the best answer and would run contrary to what I see a lot of large corporations doing (certainly the one I work for is one example). In the DWR-WW action invocation toy I have used when building InfoQ.com, the action invocation passes through exactly the same process as a normal request, so I have no concerns. I am not sure how using Ajax can bring your server down. As you say, Ajax calls are generally smaller, and I cannot see a way how you can stop a bad developer to not take his tooltips from the server if he really wants it. This is something that I think is called good practice, and as we already know there will always be guys that are not following it. Yes, the requests are generally (although not necessarily) smaller, but there can be a lot more of them. This is what I was referring to. If I have a UI that is making numerous small calls for tooltips (or something else that happens somewhat frequently, I don't want to be just picking on tooktips here!), and you have a decently high user load, that can be just as bad, and maybe even worse, than sending back a 50k HTML document rather than a 10k one that then requires those subsequent hits (i.e., the 50k document has the tooltips included and you use script to display them vs. a smaller initial document that then requires potentially numerous small requests subsequent to that initial load). Take Google Suggests as an example... they have some relatively complex code in place to throttle the number of requests it makes... think about how it works... if it was sending a request on each keystroke, and you get a fast typer like me, they would start to get a ton of requests, albeit small ones, and with enough users even their great hardware infrastructure would start to be affected at some level of scaling. They recognized this, and so they have code that actually slows down the request rate as the typing rate increases (or something to that effect, I'm not sure of all the details on how it works). That's in fact a good example of my arguement: good developers will always know what to do to protect their site. Bad developers will not know this. We are preparing a framework so that they are gonna use. If they want to use it the wrong way, I would say that this is
Re: JavaOne Ajax Discussion
On Wed, May 24, 2006 10:32 am, Alexandru Popescu wrote: In the DWR-WW action invocation toy I have used when building InfoQ.com, the action invocation passes through exactly the same process as a normal request, so I have no concerns. I haven't seen your work, so I can't talk intelligently about it... I would agree though that if DWR is going to make HTTP calls to execute Actions (a suggestion I might add that I made about two months ago to Joe with regard to how to better integrate with Struts), then that certainly alleviates my concern. However, that's a completely different calling mechanism for DWR, as I mentioned when I originally made the suggestion... I suggested something of a pluggable architecture in terms of the calling mechanism from DWR to the target object, so you could do an IPC call as it basically does not, or an HTTP request, or RMI, or whatever else... I don't see that as being a problem, but it *does* fundamentally change the way DWR works now, at least (a) as far as I understand it and (b) in this case specifically for WW, as it obviously couldn't be the *only* way it works. That's in fact a good example of my arguement: good developers will always know what to do to protect their site. Bad developers will not know this. We are preparing a framework so that they are gonna use. If they want to use it the wrong way, I would say that this is definitely their problem. From my pov I just want that the simple things to be extremely simple, and complex things possible. Other than this, it is developers talent. Well, you certainly won't get any argument from me that you have to count on developers to be smart to a large extent :) That being said, I think there is still a difference between simply providing a framework where developers can either be smart or shoot themselves in the foot, and providing things that either (a) directly do something that a smart developer probably wouldn't do or (b) make it seem like it's the right way to do things. For an example of (a), imagine Webwork provides a Google Suggests widget that makes an Ajax request on each keystroke... that's something a smart developer wouldn't do, as I think we just agreed! :-), so WW shouldn't provide that out-of-the-box. For an example of (b), even if such a widget was only part of an example app, people tend to look at those as defining best practices, so doing something that, at least arguably, isn't a best practice, should be avoided there too. As for the simple things extremely simple and the complex things possible... so long as the simple things aren't made extremely simple by doing them in a less than optimal way (i.e., a widget sending requests on each keystroke), then of course I agree :) ./alex Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne Ajax Discussion
On Wed, May 24, 2006 11:10 am, Alexandru Popescu wrote: Not sure how to read it, but call it request, or XMLHttpRequest it is still a request hiting your server. Probably on the comet-part things may be different, but that's completely another story. I think this is worth going at a little more because either I'm totally wrong, which is certainly possible, or there really *is* a potential problem... better to flesh it out now :) I know you know all this already, but just to level-set... As DWR works today, as I understand it... a request comes in to the DWR servlet... using the info from the dwr.xml file, it instantiates some class, be it an Action or not, and calls some method on it. The result is then mashalled (not sure the form it takes, maybe JSON?) and is returned to the client, where it is unmarshalled into a Javascript object. This all of course happens under the covers so that to the developer, the Javascript looks like it is executing on the client but is in fact making the call to the servlet and ultimately to the specified class. For example... in one app I did, I have this call: AddressBookManager.retrieveContacts(replyRetrieveContacts); The URL that gets called is: http://localhost:8080/instamail/dwr/exec/AddressBookManager.retrieveContacts.dwr The DWR servlet is of course mapped to /dwr/* Now, again, as DWR exists today, the call to the retrieveContacts() method of the AddressBookManager class is direct, i.e., AddressBookManager is instantiated by the DWR servlet and retrieveContacts() is called. Therefore, if your webapp has security implemented outside the Actions, i.e., CMS or something, then it is effectively bypassed. And even if you had security in the Action, it would have to be in every method, otherwise DWR could still bypass that security possibly, depending on how you implemented it. Now, one option would be to secure the calls to the DWR servlet. You could set up a constraint to cover this particular call (/dwr/exec/AddressBookManager.* would probably do the trick), but then your writing a bunch of constraints to cover whatever calls you want constrainted. And remember, a server serves by default, so anything you forget to constrain is wide open. But, in the end, this would work I think. The other option is to have DWR not instantiate AddressBookManager and call retrieveAccounts() directly, but instead call an appropriate ACTION MAPPING for it via the usual HTTP. This would incur all the security that you have implemented in your webapp, so there would be nothing new to add for DWR. It would also in the case of WW go through the whole interceptor stack, which again is bypassed as DWR works today. This is precisely what my suggestion on the DWR list a few months back was, but we were discussing Struts at the time, not WW. By the way, another tangential problem here is that in executing an Action in the manner DWR does today, i.e., not making an HTTP request, what's populated in ActionContext? There isn't a session for instance, so what if the Action tries to pull something out of session? What about the request parameters? It seems obvious that calling an Action directly isn't the right answer. Now, I'm not familiar with how DWR is integrated with WW today... maybe it already *does* make an HTTP request somehow. It seems to me, as far as security goes as well as the issue of ActionContext and such, it has to. About the other things I fully agree: a framework should never provide something that shoots the user in his foot... but a framework will never be able to guarantee that if the user especially wants this to happen it will not be able to do it :-). Hehe :) Every time I hear or use the phrase shoot yourself in the foot with regard to programming, I can't help but think of the Real Programmer's list; http://www.opundo.com/shootfoot.htm ./alex Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
On Wed, May 24, 2006 11:12 am, Joe Germuska wrote: At 10:46 AM -0400 5/24/06, Frank W. Zammetti wrote: I haven't seen your work, so I can't talk intelligently about it... I would agree though that if DWR is going to make HTTP calls to execute Actions (a suggestion I might add that I made about two months ago to Joe with regard to how to better integrate with Struts), then that certainly alleviates my concern. Forgive me if this has been covered elsewhere, but I'm still confused about why someone would want to integrate DWR with Struts? I've only used it a bit, but in each case, I didn't really see much value in coaxing it to work through Struts' request processing model. They co-exist quite peacefully in a webapp without needing to know anything about each other. I think I can answer that by asking what you would want DWR to call? I would say that in a properly-constructed webapp, you have a business facade, and that is what you would want to call via DWR. In that case, I would tend to agree, integration probably isn't a big gain. If you are intent on calling Actions though, that's where I think integration makes sense... I tend to view an pplication as a collection of loosely-coupled services, and an Action is the gateway into a given service. The Action is still doing little other than delegating to some business class, but it's still the starting point that the external world (i.e., the client-side of my app) sees. To that way of thinking, making a call via DWR should go to an Action, not directly to the business facade, because it's really just a different calling syntax to the same service. In my case, I have external security that secures each service. And I'd still want a call made via DWR to leverage that security. There might also be, if we start talking about Webwork, interceptors that deal with some cross-cutting concerns that I'd still want executed (maybe logging, as an admittedly lame example). As DWR stands today, the servlet effectively bypasses any of this sort of thing, so integration I think starts to make sense there in order to make sure those things still happen with a DWR request. I'd think a well designed application would have both Struts Actions and DWR remote objects obtaining services they need from the ServletContext, Spring, or some other independent mechanism, and DWR doesn't need to render a view in any conventional way... so what is left for Struts to do? Right, basically what I said above :) But as I mentioned, I'm not sure calling the business facade directly is the right answer (this is at least debatable), and I'm not sure I see the point in having extra classes that are specially present for DWR to call... sounds like extra work to me :) My goal is to have any external request, of any form I intend to support, going through the same stack of operations, excepting the things that necessarily have to be different (i.e., an incoming request in the form of a SOAP message can't, without extra processing, go through a step that populates some bean with request parameters obviously). I admit that I did extend DWR so that the ExecutionContext could provide a reference to a Struts 1.3 ActionContext (or rather, my custom subclass of it), so that I could maintain consistency in how I interacted with various session attributes... but it seems to me that anyone who is extending ActionContext is also in a position to extend DWR where necessary. True, but if the intergration was there from the start they likely wouldn't have to do it themselves :) I would think it probably better to advise people to use ServletFilters where they want common behavior on every request. Then what's the point of Webwork? :) Interceptors are quite akin to filters conceptually, yet we're all thrilled with the idea of interceptors in SAF2. My point is that while I agree that advising the use of filters for common behavior is a good idea, and also jives with the advice I tend to give in those situations, not having to do that extra work because there is integration that eliminates the need is even better :) Help me out here... Did I? ;) Joe Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
At 11:55 AM -0400 5/24/06, Frank W. Zammetti wrote: On Wed, May 24, 2006 11:12 am, Joe Germuska wrote: Forgive me if this has been covered elsewhere, but I'm still confused about why someone would want to integrate DWR with Struts? I've only used it a bit, but in each case, I didn't really see much value in coaxing it to work through Struts' request processing model. They co-exist quite peacefully in a webapp without needing to know anything about each other. I think I can answer that by asking what you would want DWR to call? I would say that in a properly-constructed webapp, you have a business facade, and that is what you would want to call via DWR. In that case, I would tend to agree, integration probably isn't a big gain. If you are intent on calling Actions though, that's where I think integration makes sense... but if you want to model best practices, then you have to ask why would you be intent on calling Actions? I'm not trying to build walls so that people can't just get-the-job-done, but I do know from experience that people tend to overload Actions with too much business responsibility, and integrating DWR with Struts would only encourage that. I tend to view an pplication as a collection of loosely-coupled services, and an Action is the gateway into a given service. The Action is still doing little other than delegating to some business class, but it's still the starting point that the external world (i.e., the client-side of my app) sees. To that way of thinking, making a call via DWR should go to an Action, not directly to the business facade, because it's really just a different calling syntax to the same service. But then you raise the question you had earlier, which is that Actions are generally written so that they can assume certain context which is established by Struts before they are called; duplicating all of that behavior in DWR seems peculiar at best. I would think it probably better to advise people to use ServletFilters where they want common behavior on every request. Then what's the point of Webwork? :) Interceptors are quite akin to filters conceptually, yet we're all thrilled with the idea of interceptors in SAF2. But we're thrilled with interceptors when we have a common process for receiving input (http request parameters) and a roughly common process for responding (by dispatching to a view). A DWR request has neither of these, and it seems like square pegs and round holes to try to get a DWR request to fit into a Struts request-handling process. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne Ajax Discussion
Frank you are absolutely correct about the description of how DWR works today. What I have done is exactly what you are thinking of: made DWR work through the normal WebWork chain. So, all incoming DWR requests are done to a single entry point that is than initializing/making the request pass through the WebWork normal chain. In this case there will be no security issue: you have the exact same options as for a normal request. hth, ./alex -- .w( the_mindstorm )p. On 5/24/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, May 24, 2006 11:10 am, Alexandru Popescu wrote: Not sure how to read it, but call it request, or XMLHttpRequest it is still a request hiting your server. Probably on the comet-part things may be different, but that's completely another story. I think this is worth going at a little more because either I'm totally wrong, which is certainly possible, or there really *is* a potential problem... better to flesh it out now :) I know you know all this already, but just to level-set... As DWR works today, as I understand it... a request comes in to the DWR servlet... using the info from the dwr.xml file, it instantiates some class, be it an Action or not, and calls some method on it. The result is then mashalled (not sure the form it takes, maybe JSON?) and is returned to the client, where it is unmarshalled into a Javascript object. This all of course happens under the covers so that to the developer, the Javascript looks like it is executing on the client but is in fact making the call to the servlet and ultimately to the specified class. For example... in one app I did, I have this call: AddressBookManager.retrieveContacts(replyRetrieveContacts); The URL that gets called is: http://localhost:8080/instamail/dwr/exec/AddressBookManager.retrieveContacts.dwr The DWR servlet is of course mapped to /dwr/* Now, again, as DWR exists today, the call to the retrieveContacts() method of the AddressBookManager class is direct, i.e., AddressBookManager is instantiated by the DWR servlet and retrieveContacts() is called. Therefore, if your webapp has security implemented outside the Actions, i.e., CMS or something, then it is effectively bypassed. And even if you had security in the Action, it would have to be in every method, otherwise DWR could still bypass that security possibly, depending on how you implemented it. Now, one option would be to secure the calls to the DWR servlet. You could set up a constraint to cover this particular call (/dwr/exec/AddressBookManager.* would probably do the trick), but then your writing a bunch of constraints to cover whatever calls you want constrainted. And remember, a server serves by default, so anything you forget to constrain is wide open. But, in the end, this would work I think. The other option is to have DWR not instantiate AddressBookManager and call retrieveAccounts() directly, but instead call an appropriate ACTION MAPPING for it via the usual HTTP. This would incur all the security that you have implemented in your webapp, so there would be nothing new to add for DWR. It would also in the case of WW go through the whole interceptor stack, which again is bypassed as DWR works today. This is precisely what my suggestion on the DWR list a few months back was, but we were discussing Struts at the time, not WW. By the way, another tangential problem here is that in executing an Action in the manner DWR does today, i.e., not making an HTTP request, what's populated in ActionContext? There isn't a session for instance, so what if the Action tries to pull something out of session? What about the request parameters? It seems obvious that calling an Action directly isn't the right answer. Now, I'm not familiar with how DWR is integrated with WW today... maybe it already *does* make an HTTP request somehow. It seems to me, as far as security goes as well as the issue of ActionContext and such, it has to. About the other things I fully agree: a framework should never provide something that shoots the user in his foot... but a framework will never be able to guarantee that if the user especially wants this to happen it will not be able to do it :-). Hehe :) Every time I hear or use the phrase shoot yourself in the foot with regard to programming, I can't help but think of the Real Programmer's list; http://www.opundo.com/shootfoot.htm ./alex Frank - 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: JavaOne Ajax Discussion
On Wed, May 24, 2006 12:21 pm, Alexandru Popescu wrote: Frank you are absolutely correct about the description of how DWR works today. What I have done is exactly what you are thinking of: made DWR work through the normal WebWork chain. So, all incoming DWR requests are done to a single entry point that is than initializing/making the request pass through the WebWork normal chain. In this case there will be no security issue: you have the exact same options as for a normal request. That sounds perfect! :) So it sounds like you have a single class that is executed by DWR, and which then makes an HTTP request to the appropriate WW Action? That's pretty much exactly what I had envisioned. Now, if you generalize it just a bit, you could swap in a different class that maybe created a SOAP message for example, and sends the request to some external Web Service, and the beauty of it is that from Javascript, the call is exactly the same. Great work! I hope you'll pass your work along to Joe Walker... I'd love to see it in DWR, even outside this whole integration discussion. hth, ./alex Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
On 5/24/06, Joe Germuska [EMAIL PROTECTED] wrote: At 11:55 AM -0400 5/24/06, Frank W. Zammetti wrote: On Wed, May 24, 2006 11:12 am, Joe Germuska wrote: Forgive me if this has been covered elsewhere, but I'm still confused about why someone would want to integrate DWR with Struts? I've only used it a bit, but in each case, I didn't really see much value in coaxing it to work through Struts' request processing model. They co-exist quite peacefully in a webapp without needing to know anything about each other. I think I can answer that by asking what you would want DWR to call? I would say that in a properly-constructed webapp, you have a business facade, and that is what you would want to call via DWR. In that case, I would tend to agree, integration probably isn't a big gain. If you are intent on calling Actions though, that's where I think integration makes sense... but if you want to model best practices, then you have to ask why would you be intent on calling Actions? I'm not trying to build walls so that people can't just get-the-job-done, but I do know from experience that people tend to overload Actions with too much business responsibility, and integrating DWR with Struts would only encourage that. Would you rather prefer to have your requests served directly by your services? Or by the domain model objects? I think that an action is a pretty good idea of a gateway. I tend to view an pplication as a collection of loosely-coupled services, and an Action is the gateway into a given service. The Action is still doing little other than delegating to some business class, but it's still the starting point that the external world (i.e., the client-side of my app) sees. To that way of thinking, making a call via DWR should go to an Action, not directly to the business facade, because it's really just a different calling syntax to the same service. But then you raise the question you had earlier, which is that Actions are generally written so that they can assume certain context which is established by Struts before they are called; duplicating all of that behavior in DWR seems peculiar at best. I think you are looking in the wrong direction here. Things are much more simpler than you imagine and they need almost no duplication. I have done this... and the proof is online and working. All my teammates were very happy with this solution and it brought a lot of reusability in our sourcecode. I would think it probably better to advise people to use ServletFilters where they want common behavior on every request. Then what's the point of Webwork? :) Interceptors are quite akin to filters conceptually, yet we're all thrilled with the idea of interceptors in SAF2. But we're thrilled with interceptors when we have a common process for receiving input (http request parameters) and a roughly common process for responding (by dispatching to a view). A DWR request has neither of these, and it seems like square pegs and round holes to try to get a DWR request to fit into a Struts request-handling process. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com I guess that for some the square pegs are not square or at least they fit extremely well into the round wholes :-). ./alex -- :Architect of InfoQ.com: .w( the_mindstorm )p. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne Ajax Discussion
On 5/24/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, May 24, 2006 12:21 pm, Alexandru Popescu wrote: Frank you are absolutely correct about the description of how DWR works today. What I have done is exactly what you are thinking of: made DWR work through the normal WebWork chain. So, all incoming DWR requests are done to a single entry point that is than initializing/making the request pass through the WebWork normal chain. In this case there will be no security issue: you have the exact same options as for a normal request. That sounds perfect! :) So it sounds like you have a single class that is executed by DWR, and which then makes an HTTP request to the appropriate WW Action? That's pretty much exactly what I had envisioned. Now, if you generalize it just a bit, you could swap in a different class that maybe created a SOAP message for example, and sends the request to some external Web Service, and the beauty of it is that from Javascript, the call is exactly the same. That's exactly the idea. Glad you like it. Great work! I hope you'll pass your work along to Joe Walker... I'd love to see it in DWR, even outside this whole integration discussion. I am now thinking of where this fits better: WW/SAF2 or DWR. I intend to open it soon, but I am still looking for the right umbrella :-). ./alex -- .w( the_mindstorm )p. hth, ./alex Frank - 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: JavaOne Ajax Discussion
There is a point that I would like to re-iterate. The proposal is for 2 separate approaches: #1 - Have struts2 actions accept JSON / XML content when being called from a URI and have JSON/XML responses. This is to allow struts2 to interact with any ajax/XHR framework, and would involve new interceptors and result types. #2 - Use DWR for struts2 ajax-based widgets. This should be a tight coupling of a UI element to a back-end function / action - i.e. get a list of things to display in the UI. The way I see #2 working is this - we have a specialized DWR object that accepts requests and calls an action (from a preconfigured package) the same way that it does today via Http. We also introduce several new interfaces - for example lets say AjaxList and AjaxObject. The specialized DWR object has several methods that can be called depending on the type being returned (i.e. the interface that it uses to return the result, or whether the result is rendered and returned). This is very similar to what Alex has. Damn it! You guys beat me to this ;-) /Ian Frank W. Zammetti wrote: On Wed, May 24, 2006 11:10 am, Alexandru Popescu wrote: Not sure how to read it, but call it request, or XMLHttpRequest it is still a request hiting your server. Probably on the comet-part things may be different, but that's completely another story. I think this is worth going at a little more because either I'm totally wrong, which is certainly possible, or there really *is* a potential problem... better to flesh it out now :) I know you know all this already, but just to level-set... As DWR works today, as I understand it... a request comes in to the DWR servlet... using the info from the dwr.xml file, it instantiates some class, be it an Action or not, and calls some method on it. The result is then mashalled (not sure the form it takes, maybe JSON?) and is returned to the client, where it is unmarshalled into a Javascript object. This all of course happens under the covers so that to the developer, the Javascript looks like it is executing on the client but is in fact making the call to the servlet and ultimately to the specified class. For example... in one app I did, I have this call: AddressBookManager.retrieveContacts(replyRetrieveContacts); The URL that gets called is: http://localhost:8080/instamail/dwr/exec/AddressBookManager.retrieveContacts.dwr The DWR servlet is of course mapped to /dwr/* Now, again, as DWR exists today, the call to the retrieveContacts() method of the AddressBookManager class is direct, i.e., AddressBookManager is instantiated by the DWR servlet and retrieveContacts() is called. Therefore, if your webapp has security implemented outside the Actions, i.e., CMS or something, then it is effectively bypassed. And even if you had security in the Action, it would have to be in every method, otherwise DWR could still bypass that security possibly, depending on how you implemented it. Now, one option would be to secure the calls to the DWR servlet. You could set up a constraint to cover this particular call (/dwr/exec/AddressBookManager.* would probably do the trick), but then your writing a bunch of constraints to cover whatever calls you want constrainted. And remember, a server serves by default, so anything you forget to constrain is wide open. But, in the end, this would work I think. The other option is to have DWR not instantiate AddressBookManager and call retrieveAccounts() directly, but instead call an appropriate ACTION MAPPING for it via the usual HTTP. This would incur all the security that you have implemented in your webapp, so there would be nothing new to add for DWR. It would also in the case of WW go through the whole interceptor stack, which again is bypassed as DWR works today. This is precisely what my suggestion on the DWR list a few months back was, but we were discussing Struts at the time, not WW. By the way, another tangential problem here is that in executing an Action in the manner DWR does today, i.e., not making an HTTP request, what's populated in ActionContext? There isn't a session for instance, so what if the Action tries to pull something out of session? What about the request parameters? It seems obvious that calling an Action directly isn't the right answer. Now, I'm not familiar with how DWR is integrated with WW today... maybe it already *does* make an HTTP request somehow. It seems to me, as far as security goes as well as the issue of ActionContext and such, it has to. About the other things I fully agree: a framework should never provide something that shoots the user in his foot... but a framework will never be able to guarantee that if the user especially wants this to happen it will not be able to do it :-). Hehe :) Every time I hear or use the phrase shoot yourself in the foot with regard to programming, I can't help but think of the Real Programmer's list;
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
On Wed, May 24, 2006 12:09 pm, Joe Germuska wrote: At 11:55 AM -0400 5/24/06, Frank W. Zammetti wrote: On Wed, May 24, 2006 11:12 am, Joe Germuska wrote: Forgive me if this has been covered elsewhere, but I'm still confused about why someone would want to integrate DWR with Struts? I've only used it a bit, but in each case, I didn't really see much value in coaxing it to work through Struts' request processing model. They co-exist quite peacefully in a webapp without needing to know anything about each other. I think I can answer that by asking what you would want DWR to call? I would say that in a properly-constructed webapp, you have a business facade, and that is what you would want to call via DWR. In that case, I would tend to agree, integration probably isn't a big gain. If you are intent on calling Actions though, that's where I think integration makes sense... but if you want to model best practices, then you have to ask why would you be intent on calling Actions? I'm not trying to build walls so that people can't just get-the-job-done, but I do know from experience that people tend to overload Actions with too much business responsibility, and integrating DWR with Struts would only encourage that. That would echo my experience as well... and I'm sure if we both look back, we were probably guilty of it ourselves at one early time or another :) I agree it's best practices to call the business facade directly, but what I'm saying is I'm not sure it *should* be best practices... If we were to assume that developers wrote Actions correctly, i.e., very thin and not much more than an entry point, then I think the benefits you get of calling the Actions, i.e., common security, all that the request processing does for you, only having one thing to call regardless of how the call is made, and so on, outweighs any negative there may be, and I'm not sure what negative there really is if the Actions really are thin :) I'm not so sure integrating it in the way Alexandru has apparently done would encourage bad design... I mean, certainly we've all drilled it into each others' heads for a while now that Actions shouldn't include business logic of any substanative amount... if someone chooses to ignore that admonishment just because DWR is there, I think there's a bigger problem, right?? LOL I tend to view an pplication as a collection of loosely-coupled services, and an Action is the gateway into a given service. The Action is still doing little other than delegating to some business class, but it's still the starting point that the external world (i.e., the client-side of my app) sees. To that way of thinking, making a call via DWR should go to an Action, not directly to the business facade, because it's really just a different calling syntax to the same service. But then you raise the question you had earlier, which is that Actions are generally written so that they can assume certain context which is established by Struts before they are called; duplicating all of that behavior in DWR seems peculiar at best. I'm not sure I follow this point... I would absolutely agree that if any Struts behavior is duplicated in DWR it's, as you say, peculiar at best. That's why I like what Alexandru has done, which is exactly what I had suggested on the DWR list a while back: instead of essentially an IPC call from the DWR servlet to some class (inter-JVM I guess is more accurate), be it an Action or not, instead make an HTTP request through Struts (or WW, or JSF, or whatever) to the appropriate end-point, of course an Action in the case of Struts. This requires that the incoming request to the DWR servlet be marshaleld into a new HTTP request, and from that point on, Struts simply does its thing. The question that remains of course is what is the response? My guess is that Alexandru has a JSP that renders XML or JSON or something like that, which then gets marshalled back into whatever form DWR sends back to the client. I suppose that's an implementation detail though :) I would think it probably better to advise people to use ServletFilters where they want common behavior on every request. Then what's the point of Webwork? :) Interceptors are quite akin to filters conceptually, yet we're all thrilled with the idea of interceptors in SAF2. But we're thrilled with interceptors when we have a common process for receiving input (http request parameters) and a roughly common process for responding (by dispatching to a view). A DWR request has neither of these, and it seems like square pegs and round holes to try to get a DWR request to fit into a Struts request-handling process. You are of course right, you don't have any of that with a DWR request... well, I suppose technically you *do* have request parameters, but I'm not sure what form they are in... maybe JSON in a POST body? Your right though, it's clearly not the same as a form submission to an Action. But
Re: JavaOne Ajax Discussion
At 7:21 PM +0300 5/24/06, Alexandru Popescu wrote: Frank you are absolutely correct about the description of how DWR works today. What I have done is exactly what you are thinking of: made DWR work through the normal WebWork chain. So, all incoming DWR requests are done to a single entry point that is than initializing/making the request pass through the WebWork normal chain. In this case there will be no security issue: you have the exact same options as for a normal request. OK. well, if the net result is beginning the chain at the beginning and ending at the end, with no confusion about inconsistent states based on different invocation mechanisms, then I don't see any real objection. I still don't *get it*, but that's my problem :) Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com You really can't burn anything out by trying something new, and even if you can burn it out, it can be fixed. Try something new. -- Robert Moog - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne Ajax Discussion
On Wed, May 24, 2006 12:38 pm, Ian Roughley wrote: There is a point that I would like to re-iterate. The proposal is for 2 separate approaches: #1 - Have struts2 actions accept JSON / XML content when being called from a URI and have JSON/XML responses. This is to allow struts2 to interact with any ajax/XHR framework, and would involve new interceptors and result types. I agree that a new interceptor or two to take XML/JSON input and populate the Action fields from it would be very nice indeed. Would definitely be a big productivity booster. I wonder about the response though... one thing I've found is that people for some reason, generally anyway, don't realize that they can use a JSP to render an Ajax response. Maybe all the examples they see shows the response being constructed manually in a servlet or Action and they figure that's what you have to do. I mean, constructing JSON or XML in a JSP is childs' play, and you get the benefit of being able to use all the same tags you use to create an HTML response. I wonder if it might be sufficient to simply demonstrate this to people and make it more well-known, rather than writing anything to do it specifically, and then getting into new result types and all that? What do you think? #2 - Use DWR for struts2 ajax-based widgets. This should be a tight coupling of a UI element to a back-end function / action - i.e. get a list of things to display in the UI. Someone suggested to me privately integrating GWT with SAF2 for all our widget needs... I love the work Don did to get JSF components involved, but I wonder it GWT is the larger answer? The way I see #2 working is this - we have a specialized DWR object that accepts requests and calls an action (from a preconfigured package) the same way that it does today via Http. We also introduce several new interfaces - for example lets say AjaxList and AjaxObject. The specialized DWR object has several methods that can be called depending on the type being returned (i.e. the interface that it uses to return the result, or whether the result is rendered and returned). This is very similar to what Alex has. Damn it! You guys beat me to this ;-) Yeah, he beat me to it too ;) Always nice to have your theories proven out, whether you did the work or not! /Ian Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne Ajax Discussion
-- From Down Around, Inc. Innovative IT Solutions Software Architecture * Design * Development ~ web: www.fdar.com email [EMAIL PROTECTED] phone:617.821.5430 ~ Frank W. Zammetti wrote: On Wed, May 24, 2006 12:38 pm, Ian Roughley wrote: There is a point that I would like to re-iterate. The proposal is for 2 separate approaches: #1 - Have struts2 actions accept JSON / XML content when being called from a URI and have JSON/XML responses. This is to allow struts2 to interact with any ajax/XHR framework, and would involve new interceptors and result types. I agree that a new interceptor or two to take XML/JSON input and populate the Action fields from it would be very nice indeed. Would definitely be a big productivity booster. I wonder about the response though... one thing I've found is that people for some reason, generally anyway, don't realize that they can use a JSP to render an Ajax response. Maybe all the examples they see shows the response being constructed manually in a servlet or Action and they figure that's what you have to do. I mean, constructing JSON or XML in a JSP is childs' play, and you get the benefit of being able to use all the same tags you use to create an HTML response. I wonder if it might be sufficient to simply demonstrate this to people and make it more well-known, rather than writing anything to do it specifically, and then getting into new result types and all that? What do you think? True, but it would be nice if a pre-determined XML structure or JSON could be automatically generated by using the model from the ModelAware interface. It would lower the entry point for people using the feature. #2 - Use DWR for struts2 ajax-based widgets. This should be a tight coupling of a UI element to a back-end function / action - i.e. get a list of things to display in the UI. Someone suggested to me privately integrating GWT with SAF2 for all our widget needs... I love the work Don did to get JSF components involved, but I wonder it GWT is the larger answer? I sat in on the google presentation on this at J1. The feeling I get is that GWT is for constructing entire application rather than for individual components, and it ties in heavily to the custom logic. I need to look into it further though. The way I see #2 working is this - we have a specialized DWR object that accepts requests and calls an action (from a preconfigured package) the same way that it does today via Http. We also introduce several new interfaces - for example lets say AjaxList and AjaxObject. The specialized DWR object has several methods that can be called depending on the type being returned (i.e. the interface that it uses to return the result, or whether the result is rendered and returned). This is very similar to what Alex has. Damn it! You guys beat me to this ;-) Yeah, he beat me to it too ;) Always nice to have your theories proven out, whether you did the work or not! /Ian Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne Ajax Discussion
On Wed, May 24, 2006 1:09 pm, Ian Roughley wrote: I wonder about the response though... one thing I've found is that people for some reason, generally anyway, don't realize that they can use a JSP to render an Ajax response. Maybe all the examples they see shows the response being constructed manually in a servlet or Action and they figure that's what you have to do. I mean, constructing JSON or XML in a JSP is childs' play, and you get the benefit of being able to use all the same tags you use to create an HTML response. I wonder if it might be sufficient to simply demonstrate this to people and make it more well-known, rather than writing anything to do it specifically, and then getting into new result types and all that? What do you think? True, but it would be nice if a pre-determined XML structure or JSON could be automatically generated by using the model from the ModelAware interface. It would lower the entry point for people using the feature. I hear you. In that case, I would suggest focusing on JSON... with XML, you really do have to pre-determine the schema, but with JSON that shouldn't be an issue since it's just a representation of the internal object graph of a given object. Might make it easier to get the feature implemented initially, and then expand it later to XML or whatever else. Just a thought. I sat in on the google presentation on this at J1. The feeling I get is that GWT is for constructing entire application rather than for individual components, and it ties in heavily to the custom logic. I need to look into it further though. It's funny... when I first saw the GWT announcement, I remember looking at it and thinking eh, big whoop. Then I see everyone everyone saying how it's the greatest thing since sliced bread... well, either it's just Google fanboyism, or I missed something :) So I'm in the same boat as you, I need to take a further look. I was just raising it because someone raised it to me. I do think however that a widget object model would be a very nice thing to have, and I think would jive with what you were talking about early in terms of using DWR for widgets... I've always felt that Struts was way too thin in what it offered on the client, something Webwork is already a big improvement in, so taking it further seems naturaly. It seems to me that that would be easier to do if there was a known component model to write widgets to. Maybe Don's work with getting JSF component in is the answer, maybe a whole new object model, maybe some other existing answer, I don't know. /Ian Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
but if you want to model best practices, then you have to ask why would you be intent on calling Actions? I'm not trying to build walls so that people can't just get-the-job-done, but I do know from experience that people tend to overload Actions with too much business responsibility, and integrating DWR with Struts would only encourage that. Would you rather prefer to have your requests served directly by your services? Or by the domain model objects? I think that an action is a pretty good idea of a gateway. Ok, so here's one reason why: Type Conversion My actions often use domain objects directly, and I'm able to have a property named user which calls the setUser() method, but the type conversion takes care of doing the database lookup to get the User object based on the HTTP parameter, which is just an ID. I'm not that familiar with how DWR works under the covers, but I've got to think I'd have to write another set of type converters to get the User instance loaded from the database and ready for updating. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=32216messageID=62400#62400 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DWR/Struts integration: why? (Re: JavaOne Ajax Discussion)
I'm going to take a moment to chime in here as I've been watching this thread develop. I'm going to come out in the open and say I've never used DWR or even looked at it's documentation. When I've used ajax functionality in the past we've simply made the XmlHttpRequest hit an action that in turn hits a JSP page with the contentType set to xml. I've done this on several different apps and it always works fine. We even created a modified interceptor stack that stripped out the stuff we didn't need and left it to the basics like authentication, validation, etc. Furthermore using a JSP page as the result we had access to all the taglibs we needed. I can see where this may get a bit heavy if you're doing a lot of XmlHttpRequests (e.g. in a Google Suggest type situation) however I think for the majority of apps it should work fine. -Brian On Wed, May 24, 2006 12:32 pm, Alexandru Popescu wrote: On 5/24/06, Joe Germuska [EMAIL PROTECTED] wrote: At 11:55 AM -0400 5/24/06, Frank W. Zammetti wrote: On Wed, May 24, 2006 11:12 am, Joe Germuska wrote: Forgive me if this has been covered elsewhere, but I'm still confused about why someone would want to integrate DWR with Struts? I've only used it a bit, but in each case, I didn't really see much value in coaxing it to work through Struts' request processing model. They co-exist quite peacefully in a webapp without needing to know anything about each other. I think I can answer that by asking what you would want DWR to call? I would say that in a properly-constructed webapp, you have a business facade, and that is what you would want to call via DWR. In that case, I would tend to agree, integration probably isn't a big gain. If you are intent on calling Actions though, that's where I think integration makes sense... but if you want to model best practices, then you have to ask why would you be intent on calling Actions? I'm not trying to build walls so that people can't just get-the-job-done, but I do know from experience that people tend to overload Actions with too much business responsibility, and integrating DWR with Struts would only encourage that. Would you rather prefer to have your requests served directly by your services? Or by the domain model objects? I think that an action is a pretty good idea of a gateway. I tend to view an pplication as a collection of loosely-coupled services, and an Action is the gateway into a given service. The Action is still doing little other than delegating to some business class, but it's still the starting point that the external world (i.e., the client-side of my app) sees. To that way of thinking, making a call via DWR should go to an Action, not directly to the business facade, because it's really just a different calling syntax to the same service. But then you raise the question you had earlier, which is that Actions are generally written so that they can assume certain context which is established by Struts before they are called; duplicating all of that behavior in DWR seems peculiar at best. I think you are looking in the wrong direction here. Things are much more simpler than you imagine and they need almost no duplication. I have done this... and the proof is online and working. All my teammates were very happy with this solution and it brought a lot of reusability in our sourcecode. I would think it probably better to advise people to use ServletFilters where they want common behavior on every request. Then what's the point of Webwork? :) Interceptors are quite akin to filters conceptually, yet we're all thrilled with the idea of interceptors in SAF2. But we're thrilled with interceptors when we have a common process for receiving input (http request parameters) and a roughly common process for responding (by dispatching to a view). A DWR request has neither of these, and it seems like square pegs and round holes to try to get a DWR request to fit into a Struts request-handling process. Joe -- Joe Germuska [EMAIL PROTECTED] * http://blog.germuska.com I guess that for some the square pegs are not square or at least they fit extremely well into the round wholes :-). ./alex -- :Architect of InfoQ.com: .w( the_mindstorm )p. - 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]
JavaOne Ajax Discussion
Hi everyone, Wanted to document the discussion we had at JavaOne regarding ajax support for Struts2. In attendance were Pat, myself and Martin from the committers group, as well as Joe (from DWR) and a couple of other people (my apologies for not writing down names). The discussion focused around a couple of main points, these were: 1. There have been several cases lately that the ajax support was not what users expected. 2. Dojo does not necessarily work the way that you would expect, making debugging and new user orientation more difficult than needed. 3. Struts2 should provide a benefit to the user and not just wrap pre-existing widgets/components What we came up with is: 1. Struts2 should be able to work generically as a data source for any ajax client. This would entail being able to return HTML and XML results, but also JSON results. Additionally, as well as populating the action from the HttpServletRequest we will look into populating it from JSON and XML (this could be tricky as the XML structure would need to be defined). 2. Struts2 should limit the number of ajax libraries it uses. It was agreed to use DWR as the core library. Joe thought that a Struts2 creator that read could read existing Struts2 configuration files, and expose a package would be fairly simple to do. This would avoid additional configurations. Ajax integration via dojo would continue via an independent struts-dojo project. 3. We should get out off the business of simply wrapping existing widgets / components when we add no additional benefit to users. Defining this distinction is a little harder. The easy examples are obtaining remote content, providing ajax-based select lists (with backing actions), data backed tables and mouse-over tips (obtained via remote content) - things that need interaction with the server-side. Ok... what does everyone think? /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JavaOne Ajax Discussion
On Tue, May 23, 2006 2:57 pm, Ian Roughley wrote: What we came up with is: 1. Struts2 should be able to work generically as a data source for any ajax client. This would entail being able to return HTML and XML results, but also JSON results. Additionally, as well as populating the action from the HttpServletRequest we will look into populating it from JSON and XML (this could be tricky as the XML structure would need to be defined). Argh, you guys beat me to the punch! Coincidentally, I had the very early beginnings of code to do exactly this starting to cooking over the weekend :) So I guess you can count me as supportive of the idea! I had taken the cop-out approach though... any field in the Action where a matching element is found anywhere in the XML, as long as the element only appears once, is populated. For elements that appear multiple times, it looks for a Collection or array with a matching name and populates it. This saves you from having to define the XML structure outright, and should work the same basic way for JSON as well. The obvious problem is that it's a little *too* flexible perhaps... I was thinking of providing a simple mapping file that could be read for any Action mapping, something like this: myAction firstName/ children firstName/ firstName/ /children /myAction My thinking was to create a DTD on-the-fly from this, validate the incoming request against it, and then pluck the values out and populate the Action, using the same basic logic as I outlined above. As I wrote this paragraph, it occurred to me that just providing a DTD straight away would probably be sufficient. I think it might be easier on developers those to actually write the XML they expect to receive and save them (as easy as it generally is) to write a DTD or schema. 2. Struts2 should limit the number of ajax libraries it uses. I would hope you mean limit what libraries it uses by default, not limit what libraries it *can* use ;) (I know you do) It was agreed to use DWR as the core library. Cool! I'm a big fan of DWR, I think that's a fantastic decision. Is the idea to have the DWR servlet running in the same context as the WW app, or somehow more directly integrate DWR into WW so the servlet isn't necessary? I would think a filter approach could work here, without thinking about it very much. It would also keep WW configuration as far as web.xml goes as simple as can be. Joe thought that a Struts2 creator that read could read existing Struts2 configuration files, and expose a package would be fairly simple to do. This would avoid additional configurations. So by default all the Actions would be exposed as, in essence, service endpoints, in this package? I'm not sure I like that, sounds like a potential security nightmare. Or would you still have to enable what can be accessed? If you have to still write config to enable things anyway, I'm not sure how much it would save. I'd like to hear more about how Joe envisions this working. 3. We should get out off the business of simply wrapping existing widgets / components when we add no additional benefit to users. Defining this distinction is a little harder. The easy examples are obtaining remote content, providing ajax-based select lists (with backing actions), data backed tables and mouse-over tips (obtained via remote content) - things that need interaction with the server-side. Ok... what does everyone think? I think anyone that makes an Ajax call to retrieve tooltip text is inherently evil :) LOL I kid, I kid. Seriously though, it's very easy to abuse Ajax and wind up with a server ground to its knees when the load gets high enough. Even though each Ajax request is generally smaller and easier to generate on the server resource-wise than a full page refresh, I think it is good to try and dissuade people from doing things like getting tooltip text from the server as a best practice, and therefor not providing things in the framework that makes it too easy. After all, if your going to use Javascript to retrieve a tooltip, why not just have it on the client and generate it there? It's script either way. Aside from that one quibble, this all sounds quite good to me. /Ian Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JavaOne Ajax Discussion
Hi Ian, I think using DWR as the core library will come up with some problems. For example How do you get the return value for the javascript function you call? (if receiveMessages() returns something ) How do you switch between polling and Comet? Solution (From forum) Right now you return values are not handled automatically - there is a slightly manual solution where you arrange for your Javascript to call a remoted method with the reply. You can change the method currently using the following: DWREngine._pollComet = true; We'll have a better method for this in the next release. Any Comments? Regards, Animesh Saxena RR Donnelley Wipro Technologies I don't believe in fear, I don't believe in faith, I don't believe in anything that I can't break. -Original Message- From: Ian Roughley [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 12:28 AM To: dev@struts.apache.org Subject: JavaOne Ajax Discussion Hi everyone, Wanted to document the discussion we had at JavaOne regarding ajax support for Struts2. In attendance were Pat, myself and Martin from the committers group, as well as Joe (from DWR) and a couple of other people (my apologies for not writing down names). The discussion focused around a couple of main points, these were: 1. There have been several cases lately that the ajax support was not what users expected. 2. Dojo does not necessarily work the way that you would expect, making debugging and new user orientation more difficult than needed. 3. Struts2 should provide a benefit to the user and not just wrap pre-existing widgets/components What we came up with is: 1. Struts2 should be able to work generically as a data source for any ajax client. This would entail being able to return HTML and XML results, but also JSON results. Additionally, as well as populating the action from the HttpServletRequest we will look into populating it from JSON and XML (this could be tricky as the XML structure would need to be defined). 2. Struts2 should limit the number of ajax libraries it uses. It was agreed to use DWR as the core library. Joe thought that a Struts2 creator that read could read existing Struts2 configuration files, and expose a package would be fairly simple to do. This would avoid additional configurations. Ajax integration via dojo would continue via an independent struts-dojo project. 3. We should get out off the business of simply wrapping existing widgets / components when we add no additional benefit to users. Defining this distinction is a little harder. The easy examples are obtaining remote content, providing ajax-based select lists (with backing actions), data backed tables and mouse-over tips (obtained via remote content) - things that need interaction with the server-side. Ok... what does everyone think? /Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
