See yourself: http://wiki.apache.org/struts/StrutsSolutions?action=diff&rev2=14&rev1=12
I guess I should just put redirects on pages, not delete them. Deletion seems to be unrecoverable operation. On 7/17/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
Yep, looks good... I still thought there was more to the web service page, but maybe not. The memory is the first thing to go they say :) Frank Michael Jouravlev wrote: > Is it better now? I guess I should stop fiddling with wiki for today ;-) > > On 7/17/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> Michael, it looks like this update got botched a bit... or maybe your >> still working on it, in which case ignore this... it looks like some of >> the content from the web service info is missing (my memory may be off >> though, but I did think there was more to it), but from bullet #5 down >> is talking about opening a new window from an Action, not web services, >> so that part at least would appear to be misplaced for sure. >> >> Frank >> >> Apache Wiki wrote: >> > Dear Wiki user, >> > >> > You have subscribed to a wiki page or wiki category on "Struts Wiki" >> for change notification. >> > >> > The following page has been changed by MichaelJouravlev: >> > http://wiki.apache.org/struts/StrutsWebService >> > >> > New page: >> > By Frank Zammetti, extracted from StrutsSolutions page. >> > >> > Please see [url]http://sourceforge.net/projects/strutsws/ for >> complete details, but in brief... >> > >> > I decided that, in my case at least, the easiest path "into the >> application" that could be exposed as a service would actually be the >> Actions themselves. You may ask, assuming the application was >> architected properly and the Actions delegated out work to business >> classes (that IS the case), why not just expose the business classes? >> The answer is that I wanted to leverage all the form validation and >> security built in to the app (it was a custom security solution). >> Because of this, I needed Struts to "do it's thing" leading up to the >> business class execution. >> > >> > My solution was to write a custom request processor that could >> recognize a Web Service request (SOAP over HTTP). It would be able to >> "unroll" the SOAP request, then let Struts process the request as it >> usually would, and then render the response. My solution does this. >> > >> > I don't claim this is THE way to do Web Services. Far from it. >> What I WILL claim though is that if you have an existing application >> and you want to expose parts of it as Web Services, this solution can >> give you a very easy way to do it, with some limitations of course... >> First, it is Struts 1.1-only at the moment. Second, the incoming >> request must be "flat", that is, no nested elements are allowed (aside >> from children of the root element). Third, only strings are >> supported, so you lose the notion of true data typing that SOAP gives >> you. >> > >> > All these details, and plenty more, as well as full source, are >> available at the linked address above. I welcome any suggestions >> anyone has. Although I haven't done much on this in a while (because >> it met my needs as-is), I would love to continue this work if enough >> people find it useful. >> > >> > 5. Simply put, there is no way to do this. Opening a new window is >> a strictly client-side activity. You have to "fake it". There's two >> ways to do it... >> > >> > First, you could simply target your HTML form using the >> target="_blank" attribute. This will result in whatever response the >> server sends back appearing in a new window. The down-side to this is >> you have to know before-hand to do this. If you want a variable >> solution, you have to get into scripting... You can set the target >> attribute's value via client-side scripting as appropiate before >> submitting the form. >> > >> > Second, you could have a check in all JSP's that looks for some flag >> in the request object. When present, the JSP inserts an onLoad >> Javascript event handler that opens the new window and redirects to >> the URL where the content can be found. >> > >> > Another possibility if you are using frames is to target all form >> submissions to a hidden frame. Include in all pages some Javascript >> that performs some checks and handles things accordingly... I use this >> in one system I wrote... The checks I'm speaking of are based on some >> flag value in the request object (just insert the value into a >> page-level Javascript variable)... The flag may direct the page to >> copy itself to the main display frame, or to a new window. The former >> is a very nice way to have a "Please Wait" screen while the server is >> processing. The later is the same basic idea, but in a new window. >> This also allows you to do some nice error handling things, such as >> simply hiding the Please Wait layer in the main frame to expose the >> page as it existed before the form was submitted. Nice way to debuild >> a page without incurring any server time. But now I'm getting off on >> a tangent :) >> > >> > The bottom-line here is this: There is no way to direct the browser >> to open the response in a new window from an Action. You either have >> to indicate you want this behavior when the form is submitted, or make >> it happen with scripting once the response is back at the browser. At >> least, this is true within the confines of plain old HTML... You could >> always pull an applet out and do something like this! >> > >> > >> > >> >> -- >> 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] >> >> > > --------------------------------------------------------------------- > 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
