You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Michael Rasmussen <ra...@gmail.com> on 2004/12/29 21:36:19 UTC
Re: RoadMap [was Re: ViewUtils ... ][Slightly OT]
> other page oriented technologies as the past. The future, as I see it,
> is in highly dynamic apps
What exactly do you mean by "highly dynamic"? Are you referring to
applications like gmail? Do you mean XAML type applications? (God
willing they won't actually be XAML ;-) ) Or are you referring to
something all together different?
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 29 Dec 2004 13:59:17 -0800, Craig McClanahan <cr...@gmail.com> wrote:
> On Wed, 29 Dec 2004 16:50:51 -0500, Sean Schofield
> <se...@gmail.com> wrote:
>
> [snip]
> > Probably a little bit off topic, but I wanted to respond to your
> > theory. If your theory is correct, then yes, JSF is a dead-end. I
> > don't agree with that theory, but I'm not sure that JSF will be the
> > next step either. That will depend on how fast developers evaluate
> > and then adopt the technology. And that will depend on how fast JSF
> > evolves to address various issues (see an earlier post of mine about
> > current JSF limitations.)
>
> Assuming that JSF and "highly dynamic" apps (i.. where a high degree
> of interactivity happens on the client side via DHTML and JavaScript)
> are mutually exclusive is too simplistic. The standard components in
> 1.0/1.1 don't help you do this sort of thing, but there are already
> JSF component libraries available that do. Such libraries use the JSF
> components to persist the page author's design decisions (i.e. set the
> correct attributes on the correct tags or whatever), rather than do
> the actual rendering -- so they still fit nicely into development
> tools that know how to manipulate components.
Toolkits like FacesClient Components and ADF Faces are a step in the
right direction, but they do not address most of the things I
mentioned. At least as far as I'm aware, neither can handle drag and
drop in the browser, real time updates, or wizard pages in the client.
They do handle some of the simple cases for dynamic apps, but they
don't tackle the hard problems. When you get to more complex
components, and more complex interactions, I don't see how this is
going to be handled in a way that makes it make sense to use JSF.
(Also, I don't know about ADF Faces, but FacesClient Components
appears to commit the cardinal sin of believing it owns the JavaScript
global namespace, which is pretty much guaranteed to cause problems
when any other JavaScript is used in the app.)
--
Martin Cooper
> >
> > sean
> >
>
> Craig
>
>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 29 Dec 2004 16:50:51 -0500, Sean Schofield
<se...@gmail.com> wrote:
[snip]
> Probably a little bit off topic, but I wanted to respond to your
> theory. If your theory is correct, then yes, JSF is a dead-end. I
> don't agree with that theory, but I'm not sure that JSF will be the
> next step either. That will depend on how fast developers evaluate
> and then adopt the technology. And that will depend on how fast JSF
> evolves to address various issues (see an earlier post of mine about
> current JSF limitations.)
Assuming that JSF and "highly dynamic" apps (i.. where a high degree
of interactivity happens on the client side via DHTML and JavaScript)
are mutually exclusive is too simplistic. The standard components in
1.0/1.1 don't help you do this sort of thing, but there are already
JSF component libraries available that do. Such libraries use the JSF
components to persist the page author's design decisions (i.e. set the
correct attributes on the correct tags or whatever), rather than do
the actual rendering -- so they still fit nicely into development
tools that know how to manipulate components.
>
> sean
>
Craig
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Dakota Jack <da...@gmail.com>.
Sometimes Martin just hits the nail on the head. The House of Lords
once debated putting up neon "FOG" signs in London for those that
could not see the obvious. We have Martin to help us. My hats are
off to this bit of very important bit of common sense.
Jack
On Wed, 29 Dec 2004 14:39:27 -0800, Martin Cooper <mf...@gmail.com> wrote:
>
> The key to highly dynamic apps is JavaScript, not Java. The browser is
> actually a very powerful beast, it's just that it's a royal pain to
> tame it. ;-)
>
> --
> Martin Cooper
--
------------------------------
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-----------------------------------------------
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 29 Dec 2004 16:50:51 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > I would classify Gmail as "moderately dynamic", but it's heading in
> > the right direction. I'm talking about things like handling wizard
> > page changes entirely on the client, up until Apply or OK is clicked;
> > drag and drop in the browser; master/detail handling within the
> > browser; real-time updates (i.e. not polling). Stuff like that. One of
> > the characteristics is minimising, if not eliminating, the number of
> > full-page refreshes, which makes page-oriented technologies like JSF a
> > whole lot less relevant.
> >
>
> GMail is pretty much a standard web application (even if its a
> relatively simple one from an interface standpoint.) Do you really
> think these kinds of web applications are likely to be obsolete
> anytime soon?
No, I don't. People will still develop web apps using today's
technology for a long time, but I don't think that's a reason not to
innovate and work with newer, more dynamic technologies.
> I'd admit it would be nice, but my feeling is that we are going to be
> stuck with full page refreshes (or IFrame refreshes) for a long time.
> This is the fundamental nature of web pages and the HTTP protocol.
> Yes it sucks but I don't see anything on the horizon that is likely to
> change this.
There is nothing in the nature of HTTP that has anything to do with
pages; it's simply a request / response protocol. Using HTTP doesn't
tie you to full page refreshes at all, and it's quite feasible to make
HTTP requests "behind the scenes", receive back HTML, XML, JavaScript,
or whatever, and optionally pre-process it in the browser before
updating some part of the page. This is all here today, and I'm using
it today, in production.
> I've written a lot of cool WebStart applications using JMS on the back
> end. They work great but we had the luxury of installing WebStart on
> the all of the customer's computers. I think of the browser as a
> crappier version of WebStart. Its just a vehicle for running your
> application. The key is that its a world-wide standard. Changing
> this will take time. If and when this changes, its likely to be
> influenced heavily by Microsoft. I wouldn't count on it supporting
> Java ;-)
The key to highly dynamic apps is JavaScript, not Java. The browser is
actually a very powerful beast, it's just that it's a royal pain to
tame it. ;-)
--
Martin Cooper
> Probably a little bit off topic, but I wanted to respond to your
> theory. If your theory is correct, then yes, JSF is a dead-end. I
> don't agree with that theory, but I'm not sure that JSF will be the
> next step either. That will depend on how fast developers evaluate
> and then adopt the technology. And that will depend on how fast JSF
> evolves to address various issues (see an earlier post of mine about
> current JSF limitations.)
>
> > Martin Cooper
>
> sean
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Vic <vi...@friendvu.com>.
Sean Schofield wrote:
>I think of the browser as a
>crappier version of WebStart.
>
;-)
"Walk towards the light"
I try to make my apps look like they are browser based..... so people I
show it to say: Nice DHTML. :-). Yah.
This is not the old Swing, Swing Extensions in JDNC are VERY good ...
and they are OPEN SOURCE!
JRE 1.5 Web Start is better than 1.42... so I see no road blocks yet.
(W/Flex/Lazlo, I found major performance issues in UI). Installation is
painless even for a father in law.
(Someplace I heard that 70% of Java developers know Struts. I think the
number of closet Swing people is higher - they will all come out.
ECMA-script has no chance, Swing is MVC for DataGrids)
.V
--
RiA-SoA w/JDNC <http://www.SandraSF.com> forums
- help develop a community
My blog <http://www.sandrasf.com/adminBlog>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Sean Schofield <se...@gmail.com>.
> I would classify Gmail as "moderately dynamic", but it's heading in
> the right direction. I'm talking about things like handling wizard
> page changes entirely on the client, up until Apply or OK is clicked;
> drag and drop in the browser; master/detail handling within the
> browser; real-time updates (i.e. not polling). Stuff like that. One of
> the characteristics is minimising, if not eliminating, the number of
> full-page refreshes, which makes page-oriented technologies like JSF a
> whole lot less relevant.
>
GMail is pretty much a standard web application (even if its a
relatively simple one from an interface standpoint.) Do you really
think these kinds of web applications are likely to be obsolete
anytime soon?
I'd admit it would be nice, but my feeling is that we are going to be
stuck with full page refreshes (or IFrame refreshes) for a long time.
This is the fundamental nature of web pages and the HTTP protocol.
Yes it sucks but I don't see anything on the horizon that is likely to
change this.
I've written a lot of cool WebStart applications using JMS on the back
end. They work great but we had the luxury of installing WebStart on
the all of the customer's computers. I think of the browser as a
crappier version of WebStart. Its just a vehicle for running your
application. The key is that its a world-wide standard. Changing
this will take time. If and when this changes, its likely to be
influenced heavily by Microsoft. I wouldn't count on it supporting
Java ;-)
Probably a little bit off topic, but I wanted to respond to your
theory. If your theory is correct, then yes, JSF is a dead-end. I
don't agree with that theory, but I'm not sure that JSF will be the
next step either. That will depend on how fast developers evaluate
and then adopt the technology. And that will depend on how fast JSF
evolves to address various issues (see an earlier post of mine about
current JSF limitations.)
> Martin Cooper
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RoadMap [was Re: ViewUtils ... ][Slightly OT]
Posted by Martin Cooper <mf...@gmail.com>.
On Wed, 29 Dec 2004 14:36:19 -0600, Michael Rasmussen
<ra...@gmail.com> wrote:
> > other page oriented technologies as the past. The future, as I see it,
> > is in highly dynamic apps
>
> What exactly do you mean by "highly dynamic"? Are you referring to
> applications like gmail? Do you mean XAML type applications? (God
> willing they won't actually be XAML ;-) ) Or are you referring to
> something all together different?
I would classify Gmail as "moderately dynamic", but it's heading in
the right direction. I'm talking about things like handling wizard
page changes entirely on the client, up until Apply or OK is clicked;
drag and drop in the browser; master/detail handling within the
browser; real-time updates (i.e. not polling). Stuff like that. One of
the characteristics is minimising, if not eliminating, the number of
full-page refreshes, which makes page-oriented technologies like JSF a
whole lot less relevant.
--
Martin Cooper
> Michael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org