I can see a use for this in what Im doing! :-)
Im busy writing (in what little spare time I have!) a multiplayer strategy
game - using Struts of course, and while its cool having it go through a
browser interface, being able to do a richer UI in Swing (or whatever) for
those players willing to
I think your completely right, if you've written an application correctly
then absolutely it's the classes that your Actions call upon that should
really be exposed. No argument there at all.
However, as you say, many people don't follow that model completely (for
whatever reason, probably
Thanks very much Ted!
* Please consider putting the code under Apache License 2.0
http://apache.org/licenses/. I
I will look at the license now. I can't imagine I'd have any problem
putting it under that license, and at this point I'd expect to do so when I
put out the next release (probably
Wow, that's kind of harsh, Duncan.
-Original Message-
From: Duncan Mills [mailto:[EMAIL PROTECTED]
Sent: Friday, June 04, 2004 3:38 AM
To: Struts Developers List
Subject: Re: Struts Web Services Enablement Project
Frank forgive me here, but playing Devils Advocate, if you have clean
I didn't think it was harsh myself, I think it was a valid point. My answer
from a previous response basically boils down to I don't think this solves
everyone's Web Services needs, but I think in some cases it can be an easy
path to take. Sometimes the path of least resistance is all you
Didn't mean to be harsh - I was just presenting the alternative
viewpoint that has to be answered. Personally I can see the benefit
that this project could offer, but the counter stance is a one to raise
is it not?
Regards
Duncan Mills
Senior Principal Product Manager
Oracle Application
Don, I'd be lieing if I said I understood all of what you said. If I'm
getting it at all though, I think the basic point, correct me if I'm wrong,
is that since one of the limitations of my package is that the incoming
request has to be flat in form, you are suggesting a way to allow for
I will join in too on this one...
What it sounds like you've done is put business logic in your actions, when
actions should simple call interactions between business delegates or
business facades. (See Sun's J2EE Patterns).
By mingling business logic in your actions, you've forever committed
Yeah...but I thought that in a true MVC environment you should only have 1
controller. If struts is going ot be the controller then it should ALWAYS
be the controller. So why would you re-implement the controller another
place?
Unless you are saying that struts should only be the beginning
From: Hookom, Jacob [mailto:[EMAIL PROTECTED]
If you want to do Web Services, have the services talk to
your business providers, the same ones your actions would talk to.
In a perfect world, sure. :) But that means yet another webapp (Axis,
for example,) to learn and keep up with. Last
My point was directed at the idea of reusing actions written for processing
http forms. Yes, I think Micheal's proposal is a good idea for cases like
you describe.
As always, I believe it's just a confusion of terminology between different
developers. In my mind, the controller/actions should
Yeah, I did :-)
-Original Message-
From: Frank Zammetti [mailto:[EMAIL PROTECTED]
Sent: Friday, June 04, 2004 1:21 PM
To: [EMAIL PROTECTED]
Subject: RE: Struts Web Services Enablement Project
My point was directed at the idea of reusing actions written for processing
http forms. Yes, I
I didn't think I had made any worthwhile points!
From: Hookom, Jacob [EMAIL PROTECTED]
Reply-To: Struts Developers List [EMAIL PROTECTED]
To: 'Struts Developers List' [EMAIL PROTECTED]
Subject: RE: Struts Web Services Enablement Project
Date: Fri, 4 Jun 2004 13:33:08 -0500
Yeah, I did :-)
Frank Zammetti wrote:
Don, I'd be lieing if I said I understood all of what you said. If
I'm getting it at all though, I think the basic point, correct me if
I'm wrong, is that since one of the limitations of my package is that
the incoming request has to be flat in form, you are suggesting a
Yes, as already confirmed. One area where web services are used is
standardizing how multiple applications can retrieve the same type of data
from different servers. For example, if you have multiple servers that
produce gridded weather data, all the data producers could get together and
Gotcha. This is clear in my mind now. The only concern I might have, and
believe me I know how weird this going to sound, is that this might make it
TOO flexible!
In most cases, you would only be transforming against incoming documents you expected
from different clients, as opposed to an
In most cases, you would only be transforming against incoming documents
you expected
from different clients, as opposed to an open ended set of formats. It's
just the flexibility
to be *able* to transform that I think is key. You might have rules that
sniff the incoming
document for it's
While I understand your personal goal of simply making Struts actions
available through SOAP, I think you touch on a much larger issue of how
to write applications that have robust HTML and SOAP interfaces with the
least amount of effort. Yes, one could write a Struts webapp and an
Axis
Hi
I know people has been asking about this before, but I saw previous posts
mention
commons collection 3.0 as a show stopper before the 1.2.1 release? Isn't
3.0 out already?
In any case, was just wondering what's in the way of a 1.2.1 release.
I saw that log4j Wiki has a todo list page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29379.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29343.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=29354.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=27861.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
23 matches
Mail list logo
