You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Yuniar Setiawan <yu...@gmail.com> on 2005/08/16 03:29:21 UTC
Struts weaknesses question
Hi there,
I've just read "Struts in Action" and found that one of struts weakness is
"no event model", means "Struts is tightly coupled with the
request-response model used by HTTP, this can be restricting to developers
used to finely grained events"
I've found all about this event model in JSF too. What I don't really
understand is, why do we really need event model for web application? Isn't
it suitable for desktop application? do we expected to code web application
like VB or delphi or others?
What's event model offered?
Thanks in advance
YNR
Re: Struts weaknesses question
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Tue, August 16, 2005 7:01 am, Ted Husted said:
> On 8/15/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
>> The latest buzzword being tossed around lately is RIA, Rich Internet
>> Applications. Some of us laugh at the term because we've been doing
>> RIA's for 5+ years now and never thought to attach a special term to it
>> :) But I digress...
>
> Continuing the digression theme ... Buzzword would be one
> categorization, but "pattern name" might be another. Many people used
> Facade and Composite, et al, for years before the GOF gave them names.
> Ditto for POJO. To name a thing is to own a thing. Of late, we've come
> to own POJOs, Ajax, and RIAs. :)
Fair point... I guess I'm just annoyed that *I* didn't come up with a name
for it :)
I'm quite sure I wasn't the first, but I did an app that would very
clearly be called an RIA today just over 6 years ago as of two weeks
ago... didn't use AJAX as we know it today but did use a hidden frame to
receive XML-based responses which were then inserted into pre-loaded HTML
pages, so the server never rendered a full page except when the app was
first loaded, all 20+ pages (screens) of the app were in the browser
throughout the lifetime of the app, data was just inserted, fields
enabled/disabled, and different screens shown... the app is IE-only, but
not because any IE-specific features were used, just because the layout as
speced makes it look, feel and work almost exactly like a VB-based app,
and that was far easier to accomplish when cross-browser concerns aren't
in play.
Like I said, I'm sure I wasn't the first, but clearly I had an opportunity
to come up with a name. I missed the chance :)
> -Ted.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts weaknesses question
Posted by Ted Husted <te...@gmail.com>.
On 8/15/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> The latest buzzword being tossed around lately is RIA, Rich Internet
> Applications. Some of us laugh at the term because we've been doing
> RIA's for 5+ years now and never thought to attach a special term to it
> :) But I digress...
Continuing the digression theme ... Buzzword would be one
categorization, but "pattern name" might be another. Many people used
Facade and Composite, et al, for years before the GOF gave them names.
Ditto for POJO. To name a thing is to own a thing. Of late, we've come
to own POJOs, Ajax, and RIAs. :)
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts weaknesses question
Posted by netsql <ne...@roomity.com>.
Frank W. Zammetti wrote:
... these are applications that don't
> necessarily flow from page to page, instead the user can navigate them
> at will, more or less. "Events" that occur on the client-side don't
> automatically have to result in a whole new page being rendered (and
> this DOES NOT require AJAX, the other buzzword of the day, although it
> is one good way to achieve the result).
>
I actualy look at each "page/preport" as it's own MVC. User can just
type in any url at top, that is the event.
They start filling a form, go to lunch, check CNN.com, and go back to
your site. It's event driven programing, as opposed to procedural
programing on vt100 where the programer determined the next step.
I am ammused when newbies try to document or enforce a workflow arround
an ever chaning business process. Flow chart anyone :-)
Navigation/menu to me is ... just a menu that has all the urls of each
page. Event driven, user in control. They feel empowered.
hth,
.V
http://roomity.com (version 1.09 :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Struts weaknesses question
Posted by Robert Nicholls <ni...@ll.mit.edu>.
For those who may want to see an event model built on top of Struts I
suggest that they look at the code base generated by Common-Controls:
http://www.common-controls.com
The software may be considered as two interrelated parts: View and Control.
The control is built on Struts with events that are defined by the view but
can be independently defined with a little effort. The view is based on a
set of rich custom tags. It may be a way station to something more like JSF
but for the moment it has proven to be very useful to us in building faux
RIA's.
Bob N-
-----Original Message-----
From: Frank W. Zammetti [mailto:fzlists@omnytex.com]
Sent: Monday, August 15, 2005 10:17 PM
To: Struts Users Mailing List
Subject: Re: Struts weaknesses question
The latest buzzword being tossed around lately is RIA, Rich Internet
Applications. Some of us laugh at the term because we've been doing RIA's
for 5+ years now and never thought to attach a special term to it
:) But I digress...
It's true that Struts doesn't have any built-in provisions for event-driven
web development, but it does nothing to stop you from implementing it
yourself. I mean, in the end, ASP.Net, JSF, Shale, the work of Michael
Jouravlev, and all the other contenders are doing exactly that... it's still
HTTP underneath it all.
What does the event-driven model offer you? It allows you to build webapps
that are much more like fat-client apps in terms of how they work and how
the user interacts with it.
We're far enough along in things that we can now differentiate two types of
webapps... one is the "classic" model, as I like to call it... this is the
"fill in some form fields, click a button, wait for a new page to appear"
model. This served us well for a couple of years, but even from the
beginning you could see that is was a step back from what we were used to in
terms of native apps. There just wasn't much choice... we didn't yet know
how to do anything else!
Now we're moving on to the RIA's... these are applications that don't
necessarily flow from page to page, instead the user can navigate them at
will, more or less. "Events" that occur on the client-side don't
automatically have to result in a whole new page being rendered (and this
DOES NOT require AJAX, the other buzzword of the day, although it is one
good way to achieve the result).
As I said at the beginning, Struts doesn't offer this capability natively,
but it does nothing to stop you from doing it yourself. At the end of the
day, an event-driven model is more about a conceptual approach than it is
concrete techniques. Don't view your webapp as a series of pages. Instead,
view it as a collection of loosely-coupled "services" that you nit together
to form a whole. You've probably heaard the term SOA, Service-Oriented
Architecture... usually this refers to Web Services, but you can create a
SOA-based single application just as well.
Web development is going to continue to march more and more towards the RIA
model of things. It's pretty much inevitable in my view. People are just
now putting forth a number of different ways to get there, and it will be
interesting to see which ones survive the shakedown period...
I'm not sure it's fair to say that Struts lack of a true event model is a
weakness... it simply wasn't a coherent concept when Struts was created.
Frank
Yuniar Setiawan wrote:
> Hi there,
> I've just read "Struts in Action" and found that one of struts
> weakness is "no event model", means "Struts is tightly coupled with
> the request-response model used by HTTP, this can be restricting to
> developers used to finely grained events"
> I've found all about this event model in JSF too. What I don't really
> understand is, why do we really need event model for web application?
> Isn't it suitable for desktop application? do we expected to code web
> application like VB or delphi or others?
> What's event model offered?
> Thanks in advance
> YNR
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts weaknesses question
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
The latest buzzword being tossed around lately is RIA, Rich Internet
Applications. Some of us laugh at the term because we've been doing
RIA's for 5+ years now and never thought to attach a special term to it
:) But I digress...
It's true that Struts doesn't have any built-in provisions for
event-driven web development, but it does nothing to stop you from
implementing it yourself. I mean, in the end, ASP.Net, JSF, Shale, the
work of Michael Jouravlev, and all the other contenders are doing
exactly that... it's still HTTP underneath it all.
What does the event-driven model offer you? It allows you to build
webapps that are much more like fat-client apps in terms of how they
work and how the user interacts with it.
We're far enough along in things that we can now differentiate two types
of webapps... one is the "classic" model, as I like to call it... this
is the "fill in some form fields, click a button, wait for a new page to
appear" model. This served us well for a couple of years, but even from
the beginning you could see that is was a step back from what we were
used to in terms of native apps. There just wasn't much choice... we
didn't yet know how to do anything else!
Now we're moving on to the RIA's... these are applications that don't
necessarily flow from page to page, instead the user can navigate them
at will, more or less. "Events" that occur on the client-side don't
automatically have to result in a whole new page being rendered (and
this DOES NOT require AJAX, the other buzzword of the day, although it
is one good way to achieve the result).
As I said at the beginning, Struts doesn't offer this capability
natively, but it does nothing to stop you from doing it yourself. At
the end of the day, an event-driven model is more about a conceptual
approach than it is concrete techniques. Don't view your webapp as a
series of pages. Instead, view it as a collection of loosely-coupled
"services" that you nit together to form a whole. You've probably
heaard the term SOA, Service-Oriented Architecture... usually this
refers to Web Services, but you can create a SOA-based single
application just as well.
Web development is going to continue to march more and more towards the
RIA model of things. It's pretty much inevitable in my view. People
are just now putting forth a number of different ways to get there, and
it will be interesting to see which ones survive the shakedown period...
I'm not sure it's fair to say that Struts lack of a true event model is
a weakness... it simply wasn't a coherent concept when Struts was created.
Frank
Yuniar Setiawan wrote:
> Hi there,
> I've just read "Struts in Action" and found that one of struts weakness is
> "no event model", means "Struts is tightly coupled with the
> request-response model used by HTTP, this can be restricting to developers
> used to finely grained events"
> I've found all about this event model in JSF too. What I don't really
> understand is, why do we really need event model for web application? Isn't
> it suitable for desktop application? do we expected to code web application
> like VB or delphi or others?
> What's event model offered?
> Thanks in advance
> YNR
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Struts weaknesses question
Posted by Martin Gainty <mg...@hotmail.com>.
Yuniar-
You will need an event based model when actions from the client will be
/should drive the actions for the webapp instead of http
My take and Im no expert is that Microsoft in developed the .NET Platform
and allaire developed ColdFusion (later acquired by MacroMedia) when they
both realised that it was easier transition to their web application
environments for Swing and / or desktop developers if they gave them an
modeling system which is primarily event based
(if you peek under the covers you will discover in the case of .NET and CF
that the web server actually has listeners for those configured
events). and yes in the case of ColdFusion implementing those fine grained
events via a Servlet
Anyone else?
Martin-
----- Original Message -----
From: "Yuniar Setiawan" <yu...@gmail.com>
To: "Struts Users Mailing List" <us...@struts.apache.org>
Sent: Monday, August 15, 2005 9:29 PM
Subject: Struts weaknesses question
Hi there,
I've just read "Struts in Action" and found that one of struts weakness is
"no event model", means "Struts is tightly coupled with the
request-response model used by HTTP, this can be restricting to developers
used to finely grained events"
I've found all about this event model in JSF too. What I don't really
understand is, why do we really need event model for web application? Isn't
it suitable for desktop application? do we expected to code web application
like VB or delphi or others?
What's event model offered?
Thanks in advance
YNR
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org