Michael Jouravlev wrote:
Command is only better because it does not throw HTTP stuff right in
one's face.

Precisely the point :)

> Is it really better? Maybe just for testing.

Not just for testing... wouldn't it be great if you could take that same controller code, the code that really forms an application by the way because the business facade is really just a collection of (hopefully) loosely-coupled services, the control layer is what ties those services together to form an application, and truly slap on a whole new presentation to it? We've seen questions around here about putting a Swing interface on top of Struts... that's difficult with Actions precisely because it's tied to the servlet API. Remove that and your ability to reuse code goes up.

> From webapp
point of view, Command is as bad as Action. Meaning that HttpServlet
has doGet() and doPost() and therefore forces people to think what
kind of request they are processing and what method is better to use.

I suggest taking a look at WW... note how you can code your Actions to not care about any of that.

Action's only execute() method blurries vision, makes everything a web
service so to speak. Many do not think on what kind of request they
are actually processing and in what other interactions this Action or
a business/UI object represented by this action participates.

Your right... but you've just defeated your own argument :) Your describing why Action isn't the best idea... Command removes those problems... well, I suppose you could argue that it's a single abstracted context object being passed to a Command that actually does away with the "problems" :) I'd have to agree!

After all, until developers move on to GWT or move back to Swing, they
will continue developing against 1995 protocol. It is important to
consider features, quirks and requirements of this protocol despite
popular opinion that protocol-agnostic application is better thing.

It's a popular opinion because there is great validity to it :) It's easy to limit your thinking to a subset of use cases out there, and in that subset, something like Command has not much benefit. Expand your view though and the benefit becomes fairly obvious... a company that can change from a web-based application to a fat client, or vice versa, quickly and easily, without touching the "core" of the application, is highly agile, and more likely to succeed. Business drives technology, not the other way around, at least, it's supposed to. Otherwise we'd all just be theoretical computer scientists :)

Um, I have to think on this paragraph, I have not got it yet, but
maybe I will get it later, after my head stop aching and I reread it
couple more times :)

Yeah, definitely something to make sure you wrap your brain around... I could see you taking what your doing and making it just a different processing chain. That would probably be the best of both worlds.

Frank

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to