You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-user@portals.apache.org by Gerry Reno <gr...@yahoo.com> on 2003/08/06 03:47:57 UTC
JSR-168 Article Part 1 in JavaWorld
I just finished reading the article " Introducing the Portlet
Specification, Part 1" in JavaWorld. I was hoping to find there some
latitude in the portlet spec that would allow for a portlet interaction
model such as I had proposed to the JSR-168 team in response to the
public release of the spec and in these two threads:
http://marc.theaimsgroup.com/?l=jetspeed-user&m=105850057414235&w=2
http://marc.theaimsgroup.com/?l=jetspeed-user&m=105846310309122&w=2
Unfortunately there appears to be no latitude in the spec. The JSR-168
spec is supposed to permit creation of Enterprise Information Portals
(EIP) using standardized portlets that are portable. This is good.
But, I think that a lot of people have got themselves so caught up in
the portlet lifecycle and the API and the storing of persistent portlet
data and how do I create a ______ type portlet and all the rest that
they are failing to look at a bigger picture of some of the
human-factors and user-experience perspectives and expectations with
regard to web enterprise information portals. From my perspective this
is very important since JSR-168 is going to be declared *the* standard.
The standard should provide enough flexibility to accomodate all the
common types of paradigms and technologies to which users have come to
use when utilizing the Web.
The portlet spec as currently written is analogous to having a number
of browsers open on your desktop and each one would represent a portlet
and if you were to hit the reload button or minimize or maximize or
submit a form from any of them, then all of them would reload their
pages. Well this works great if you don't mind losing any client-side
processing that is going on. The problem is that users are accustomed
to having client-side processing and in fact expect a consistent
context when interacting with client-side technologies. As it stands
now, the portlet spec is dictating that every portlet mode or window
state change causes an action request to be sent to the server. If you
understand how the browser and pages and the document object model and
browser client-side technologies work you immediately realize that
constantly reloading pages is not a good thing.
Ok, let's look at a real simple example. A user is interacting with
an information rich JSR-168 portal. In the portal there is a media
player portlet that allows the user to select from a list of available
videos to view and there are other portlets on the page for various
other information purposes. While the user is viewing a video
presentation, one of these other portlets is doing something
distracting and the user would like to minimize it so that the user can
concentrate on the video presentation. Under the current JSR-168 spec
the user's action to minimize this portlet results in a page request
being sent back to the server which in turn results in the page being
reloaded. What that does is destroy the original document object model
(DOM) in the browser representing the original page and the subsequent
creation of a new DOM representing the newly reloaded page. All
running embedded client-side technologies such as applets, DHTML,
javascript, Flash, SVG, etc. etc. are destroyed losing their contexts.
The browser then redraws the reloaded page and all the portlets and
initializes and starts all client-side scripts, modules, applets,
objects, etc. once again. Well, for our user watching the video what
happens is that the media player in the portlet is destroyed,
recreated, initialized and starts over waiting for the user to make a
video selection. Not exactly what the user would expect. Users are
used to doing things like expanding and contracting lists, boxes and
tables without seeing an expensive round trip to the server and a page
reload. These are all things that are very easy to do on the client
using DHTML, javascript, Flash, SVG or any other of the client-side
technologies that can manipulate the DOM. In a broader perspective,
under the current JSR-168 spec, all uses of client-side technologies
are severely limited due to the interaction model dictated by the spec.
Another issue is the user's perception of performance. I submit that
a better model is one in which Java dovetails with client-side
technologies to minimize round-trips to the server. Try testing a
Jetspeed portal from a dial-up connection. If you are interacting with
its portlets and using any of the buttons controlling portlet mode or
window state, each button press results is a new page being served with
the net experience being a portal that is painfully slow. What I
notice a lot of the current Jetspeed sites doing is completely removing
any of the portlet mode or window state buttons from the portlets and
forcing the user into a rigid predetermined layout. This reduces the
abilty of a user to cause a page reload but it defeats nearly all of
the user preference flexibility of the portal.
To create a portal model that will provide for a good user experience
is going to require both server-side and client-side technologies
working together. I would much rather see portlets implemented as
either all iframes that can be controlled and reloaded individually or
even better as something like CSS <div> elements that can dynamically
be controlled on the client-side by DHTML, javascript, Flash, SVG, etc.
for things like minimizing, maximizing, print-friendly, help, edit.
That way the only thing that is going to cause a trip to the server is
something like a form submit and even that should be done in a iframe
so that the rest of the page doesn't reload.
Please take some time to think about this spec and the type of portal
behavior into which users will be locked. For a portal operating under
my suggested model, when the user want to maximize a portlet, the
portlet is nearly instanteously maximized with enhanced content and
none of this is requiring a trip to the server. Additionally the user
can now maximize, normalize, and minimize the portlet as many times as
they like all without any requests being sent to the server. The
portal can now even operate in an offline mode, the DOM integrity has
been maintained so client-side technologies function as expected,
portlets such as Jetspeed's IFramePortlet function properly, and the
user is experiencing near instanteous response from the user interface
and their overall experience will be much more satisfying.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi Marc,
--- Marc Tremblay <ma...@tremblay.name> wrote:
> While I agree that allowing for the use of rich client side
> technologies
> is highly desirable, we need to remember that not all user agents
> will
> be able to support said technologies. I'm thinking specifically of
> the
> myriad of WML devices out there. Since this is an initial spec, I'm
> much happier that it is capable of working with user agents of
> limited
> ability than if such user agents were forgotten altogether or simply
> tacked on at the end.
>
> Let's get a foundation in place first, then we can tweak it. It
> reminds
> me of the EJB 1.0 spec whose greatest purpose, IMO, was to be the
> foundation for later revisions which were actually usable.
>
> -- Marc
>
I just don't think that the current spec is going to be extendable.
The fundamental model has to be right and I don't think that it is. As
far as WML devices and as I said in a letter that I wrote to JSR-168
team, the small screen device technology is progressing at a very rapid
pace and these devices will very shortly be capable of DOM processing.
Check out all the buzz about SVG on small screen devices. I think the
spec is placing way too much emphasis on the 'lowest common
denominator' approach. Users, as the Java community knows all too
well, tend to reject these types of approaches. Look at AWT, Swing,
applets. They were to be the killer technologies and users didn't
embrace them en-masse because they wanted a richer experience. My
feeling is that the portlet spec is making the same type of mistake
here.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi Marc,
--- Marc Tremblay <ma...@tremblay.name> wrote:
> While I agree that allowing for the use of rich client side
> technologies
> is highly desirable, we need to remember that not all user agents
> will
> be able to support said technologies. I'm thinking specifically of
> the
> myriad of WML devices out there. Since this is an initial spec, I'm
> much happier that it is capable of working with user agents of
> limited
> ability than if such user agents were forgotten altogether or simply
> tacked on at the end.
>
> Let's get a foundation in place first, then we can tweak it. It
> reminds
> me of the EJB 1.0 spec whose greatest purpose, IMO, was to be the
> foundation for later revisions which were actually usable.
>
> -- Marc
>
I just don't think that the current spec is going to be extendable.
The fundamental model has to be right and I don't think that it is. As
far as WML devices and as I said in a letter that I wrote to JSR-168
team, the small screen device technology is progressing at a very rapid
pace and these devices will very shortly be capable of DOM processing.
Check out all the buzz about SVG on small screen devices. I think the
spec is placing way too much emphasis on the 'lowest common
denominator' approach. Users, as the Java community knows all too
well, tend to reject these types of approaches. Look at AWT, Swing,
applets. They were to be the killer technologies and users didn't
embrace them en-masse because they wanted a richer experience. My
feeling is that the portlet spec is making the same type of mistake
here.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Marc Tremblay <ma...@tremblay.name>.
While I agree that allowing for the use of rich client side technologies
is highly desirable, we need to remember that not all user agents will
be able to support said technologies. I'm thinking specifically of the
myriad of WML devices out there. Since this is an initial spec, I'm
much happier that it is capable of working with user agents of limited
ability than if such user agents were forgotten altogether or simply
tacked on at the end.
Let's get a foundation in place first, then we can tweak it. It reminds
me of the EJB 1.0 spec whose greatest purpose, IMO, was to be the
foundation for later revisions which were actually usable.
-- Marc
On Tue, 2003-08-05 at 19:47, Gerry Reno wrote:
> I just finished reading the article " Introducing the Portlet
> Specification, Part 1" in JavaWorld. I was hoping to find there some
> latitude in the portlet spec that would allow for a portlet interaction
> model such as I had proposed to the JSR-168 team in response to the
> public release of the spec and in these two threads:
> http://marc.theaimsgroup.com/?l=jetspeed-user&m=105850057414235&w=2
>
> http://marc.theaimsgroup.com/?l=jetspeed-user&m=105846310309122&w=2
>
> Unfortunately there appears to be no latitude in the spec. The JSR-168
> spec is supposed to permit creation of Enterprise Information Portals
> (EIP) using standardized portlets that are portable. This is good.
> But, I think that a lot of people have got themselves so caught up in
> the portlet lifecycle and the API and the storing of persistent portlet
> data and how do I create a ______ type portlet and all the rest that
> they are failing to look at a bigger picture of some of the
> human-factors and user-experience perspectives and expectations with
> regard to web enterprise information portals. From my perspective this
> is very important since JSR-168 is going to be declared *the* standard.
> The standard should provide enough flexibility to accomodate all the
> common types of paradigms and technologies to which users have come to
> use when utilizing the Web.
> The portlet spec as currently written is analogous to having a number
> of browsers open on your desktop and each one would represent a portlet
> and if you were to hit the reload button or minimize or maximize or
> submit a form from any of them, then all of them would reload their
> pages. Well this works great if you don't mind losing any client-side
> processing that is going on. The problem is that users are accustomed
> to having client-side processing and in fact expect a consistent
> context when interacting with client-side technologies. As it stands
> now, the portlet spec is dictating that every portlet mode or window
> state change causes an action request to be sent to the server. If you
> understand how the browser and pages and the document object model and
> browser client-side technologies work you immediately realize that
> constantly reloading pages is not a good thing.
> Ok, let's look at a real simple example. A user is interacting with
> an information rich JSR-168 portal. In the portal there is a media
> player portlet that allows the user to select from a list of available
> videos to view and there are other portlets on the page for various
> other information purposes. While the user is viewing a video
> presentation, one of these other portlets is doing something
> distracting and the user would like to minimize it so that the user can
> concentrate on the video presentation. Under the current JSR-168 spec
> the user's action to minimize this portlet results in a page request
> being sent back to the server which in turn results in the page being
> reloaded. What that does is destroy the original document object model
> (DOM) in the browser representing the original page and the subsequent
> creation of a new DOM representing the newly reloaded page. All
> running embedded client-side technologies such as applets, DHTML,
> javascript, Flash, SVG, etc. etc. are destroyed losing their contexts.
> The browser then redraws the reloaded page and all the portlets and
> initializes and starts all client-side scripts, modules, applets,
> objects, etc. once again. Well, for our user watching the video what
> happens is that the media player in the portlet is destroyed,
> recreated, initialized and starts over waiting for the user to make a
> video selection. Not exactly what the user would expect. Users are
> used to doing things like expanding and contracting lists, boxes and
> tables without seeing an expensive round trip to the server and a page
> reload. These are all things that are very easy to do on the client
> using DHTML, javascript, Flash, SVG or any other of the client-side
> technologies that can manipulate the DOM. In a broader perspective,
> under the current JSR-168 spec, all uses of client-side technologies
> are severely limited due to the interaction model dictated by the spec.
>
> Another issue is the user's perception of performance. I submit that
> a better model is one in which Java dovetails with client-side
> technologies to minimize round-trips to the server. Try testing a
> Jetspeed portal from a dial-up connection. If you are interacting with
> its portlets and using any of the buttons controlling portlet mode or
> window state, each button press results is a new page being served with
> the net experience being a portal that is painfully slow. What I
> notice a lot of the current Jetspeed sites doing is completely removing
> any of the portlet mode or window state buttons from the portlets and
> forcing the user into a rigid predetermined layout. This reduces the
> abilty of a user to cause a page reload but it defeats nearly all of
> the user preference flexibility of the portal.
> To create a portal model that will provide for a good user experience
> is going to require both server-side and client-side technologies
> working together. I would much rather see portlets implemented as
> either all iframes that can be controlled and reloaded individually or
> even better as something like CSS <div> elements that can dynamically
> be controlled on the client-side by DHTML, javascript, Flash, SVG, etc.
> for things like minimizing, maximizing, print-friendly, help, edit.
> That way the only thing that is going to cause a trip to the server is
> something like a form submit and even that should be done in a iframe
> so that the rest of the page doesn't reload.
> Please take some time to think about this spec and the type of portal
> behavior into which users will be locked. For a portal operating under
> my suggested model, when the user want to maximize a portlet, the
> portlet is nearly instanteously maximized with enhanced content and
> none of this is requiring a trip to the server. Additionally the user
> can now maximize, normalize, and minimize the portlet as many times as
> they like all without any requests being sent to the server. The
> portal can now even operate in an offline mode, the DOM integrity has
> been maintained so client-side technologies function as expected,
> portlets such as Jetspeed's IFramePortlet function properly, and the
> user is experiencing near instanteous response from the user interface
> and their overall experience will be much more satisfying.
>
> rgds,
> Gerry Reno
>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Erik, Serge (I'm going to respond to both of you here)
--- Serge Huber2 <sh...@jahia.com> wrote:
> At 14:44 06.08.2003 -0700, you wrote:
> > The portlet spec is locking out client-side technologies!! If
> the
> >arguments and points that I have presented have not convinced you
> then
> >sobeit. I can pretty much guarantee you that going forward with the
> >spec the way it is it will fail. Users are going to reject the slow
> >performance the lack of being able to use good client-side
> technologies
> >that other portal implementations are going to allow. The only way
> >that I'll even consider designing anything around this current spec
> is
> >to remove all of the portlet window state buttons and portlet mode
> >buttons so that I can use some client-side technologies in the
> portal
> >and the user won't be experiencing constant page reloading.
>
> Well the spec is actually very close to the Servlet API in some ways.
> The
> Servlet API is also quite minimal in it's coverage, and I wouldn't
> call it
> a failure despite the fact that it didn't cover areas such as :
>
> - browser capabilities
> - client-side supported technologies
> - file uploads
>
> etc...
>
> I do understand very well the point you are making. For example I
> personally prefer to use an email client such as Evolution or Eudora
> than
> using the web interface of Hotmail or Yahoo Mail. Why ? Because of
> all the
> server round trips that do make some operations tedious. But I also
> like to
> have my mail all in one place, and not have to login into seperate
> web
> interfaces to check my mail, which I guess brings my needs back to
> portal
> needs.
>
> But I fail to understand your point as to why the current spec is
> locking
> client-side technologies out. As I said previously I think the spec
> is
> lacking in the areas of specifying the lookup and dispatching
> technologies
> to portlets, but I think that can come in a later revision of the
> spec, or
> become a defacto standard through the promotion of technologies such
> as
> Pluto that are (will be actually) under a very free license such as
> Apache.
> I think the spec doesn't include client technology support as per
> say, but
> I wouldn't say it "locks it out".
>
> If I take a quick look at what is needed using todays technologies in
> order
> to make the client-side experience nicer :
> - Javascript
> - DOM Level 2
> - Probably LiveConnect if we want to interact with applets
> - A way to communicate on a portlet basis with the server, be it
> iFrame, or
> SOAP calls or something like that.
> On the server-side we need :
> - a SOAP server or an HTTP server that hooks up to the client
> - A collection of portlets
>
> Now what let's say that the portlets interact with the client through
> WSRP.
> Why couldn't the WSRP server communicate with it's portlets through
> the
> JSR-168 interfaces (which is exactly what Oracle's implementation
> does btw)
> ? It would then just be up to the implementation of the portlets to
> follow
> guidelines (which are NOT in the spec), to interface well with the
> client
> side controls. These guidelines might be what you think is lacking in
> the
> spec, but as I see it it is technologically possible to do this,
> although
> not as easy.
>
> The point I am mostly trying to make here is that the spec is aimed
> at
> defining how portlet developers should do their work in a broad and
> all-encompassing fashion. Constraining them too much will probably
> scare
> them away. Now they should ALSO have the possibility to write code
> without
> any client-side controls, and the spec allows this too. But I think
> that if
> there is some serious flaw in the spec that we have yet to uncover,
> either
> we must correct it now if still possible, or it will be corrected in
> a
> later update.
>
> Regards,
> Serge Huber.
>
I think that this spec needs to recognize that in order for a portal
to be able to preserve the context for client-side technologies, which
by definition means that you must maintain the integrity of the main
page DOM, that it cannot have every portlet action reloading the main
page. Now it can have portlet actions reloading iframes. But if the
actions are going to reload the main page then there is no way to
preserve the context for the client-side technologies and therefore the
client-side technologies have been rendered virtually useless. I see
no way that WSRP or anything else will improve this unless of course
you talking about hacking whole tree sections of the DOM instead of
reloading the whole main page.
The model that is necessary to insure that client-side technologies
are usable would involve having the portlets all implemented as iframes
with a client-side controller/proxy to talk to the server and to
control the presentation of the portlets in the browser itself. This
does not mean that you are prevented from having portlets operate in a
mode without client-side control. The key is specifying the right
model that will permit the case for also allowing a client-side
controller that can be used to talk with the portlets (all iframe
based) and will permit the main page to remain intact in the browser so
that client-side technologies will be able to maintain context and work
all the while portlets are changing window states or portlet modes.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Erik, Serge (I'm going to respond to both of you here)
--- Serge Huber2 <sh...@jahia.com> wrote:
> At 14:44 06.08.2003 -0700, you wrote:
> > The portlet spec is locking out client-side technologies!! If
> the
> >arguments and points that I have presented have not convinced you
> then
> >sobeit. I can pretty much guarantee you that going forward with the
> >spec the way it is it will fail. Users are going to reject the slow
> >performance the lack of being able to use good client-side
> technologies
> >that other portal implementations are going to allow. The only way
> >that I'll even consider designing anything around this current spec
> is
> >to remove all of the portlet window state buttons and portlet mode
> >buttons so that I can use some client-side technologies in the
> portal
> >and the user won't be experiencing constant page reloading.
>
> Well the spec is actually very close to the Servlet API in some ways.
> The
> Servlet API is also quite minimal in it's coverage, and I wouldn't
> call it
> a failure despite the fact that it didn't cover areas such as :
>
> - browser capabilities
> - client-side supported technologies
> - file uploads
>
> etc...
>
> I do understand very well the point you are making. For example I
> personally prefer to use an email client such as Evolution or Eudora
> than
> using the web interface of Hotmail or Yahoo Mail. Why ? Because of
> all the
> server round trips that do make some operations tedious. But I also
> like to
> have my mail all in one place, and not have to login into seperate
> web
> interfaces to check my mail, which I guess brings my needs back to
> portal
> needs.
>
> But I fail to understand your point as to why the current spec is
> locking
> client-side technologies out. As I said previously I think the spec
> is
> lacking in the areas of specifying the lookup and dispatching
> technologies
> to portlets, but I think that can come in a later revision of the
> spec, or
> become a defacto standard through the promotion of technologies such
> as
> Pluto that are (will be actually) under a very free license such as
> Apache.
> I think the spec doesn't include client technology support as per
> say, but
> I wouldn't say it "locks it out".
>
> If I take a quick look at what is needed using todays technologies in
> order
> to make the client-side experience nicer :
> - Javascript
> - DOM Level 2
> - Probably LiveConnect if we want to interact with applets
> - A way to communicate on a portlet basis with the server, be it
> iFrame, or
> SOAP calls or something like that.
> On the server-side we need :
> - a SOAP server or an HTTP server that hooks up to the client
> - A collection of portlets
>
> Now what let's say that the portlets interact with the client through
> WSRP.
> Why couldn't the WSRP server communicate with it's portlets through
> the
> JSR-168 interfaces (which is exactly what Oracle's implementation
> does btw)
> ? It would then just be up to the implementation of the portlets to
> follow
> guidelines (which are NOT in the spec), to interface well with the
> client
> side controls. These guidelines might be what you think is lacking in
> the
> spec, but as I see it it is technologically possible to do this,
> although
> not as easy.
>
> The point I am mostly trying to make here is that the spec is aimed
> at
> defining how portlet developers should do their work in a broad and
> all-encompassing fashion. Constraining them too much will probably
> scare
> them away. Now they should ALSO have the possibility to write code
> without
> any client-side controls, and the spec allows this too. But I think
> that if
> there is some serious flaw in the spec that we have yet to uncover,
> either
> we must correct it now if still possible, or it will be corrected in
> a
> later update.
>
> Regards,
> Serge Huber.
>
I think that this spec needs to recognize that in order for a portal
to be able to preserve the context for client-side technologies, which
by definition means that you must maintain the integrity of the main
page DOM, that it cannot have every portlet action reloading the main
page. Now it can have portlet actions reloading iframes. But if the
actions are going to reload the main page then there is no way to
preserve the context for the client-side technologies and therefore the
client-side technologies have been rendered virtually useless. I see
no way that WSRP or anything else will improve this unless of course
you talking about hacking whole tree sections of the DOM instead of
reloading the whole main page.
The model that is necessary to insure that client-side technologies
are usable would involve having the portlets all implemented as iframes
with a client-side controller/proxy to talk to the server and to
control the presentation of the portlets in the browser itself. This
does not mean that you are prevented from having portlets operate in a
mode without client-side control. The key is specifying the right
model that will permit the case for also allowing a client-side
controller that can be used to talk with the portlets (all iframe
based) and will permit the main page to remain intact in the browser so
that client-side technologies will be able to maintain context and work
all the while portlets are changing window states or portlet modes.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Serge Huber2 <sh...@jahia.com>.
At 14:44 06.08.2003 -0700, you wrote:
> The portlet spec is locking out client-side technologies!! If the
>arguments and points that I have presented have not convinced you then
>sobeit. I can pretty much guarantee you that going forward with the
>spec the way it is it will fail. Users are going to reject the slow
>performance the lack of being able to use good client-side technologies
>that other portal implementations are going to allow. The only way
>that I'll even consider designing anything around this current spec is
>to remove all of the portlet window state buttons and portlet mode
>buttons so that I can use some client-side technologies in the portal
>and the user won't be experiencing constant page reloading.
Well the spec is actually very close to the Servlet API in some ways. The
Servlet API is also quite minimal in it's coverage, and I wouldn't call it
a failure despite the fact that it didn't cover areas such as :
- browser capabilities
- client-side supported technologies
- file uploads
etc...
I do understand very well the point you are making. For example I
personally prefer to use an email client such as Evolution or Eudora than
using the web interface of Hotmail or Yahoo Mail. Why ? Because of all the
server round trips that do make some operations tedious. But I also like to
have my mail all in one place, and not have to login into seperate web
interfaces to check my mail, which I guess brings my needs back to portal
needs.
But I fail to understand your point as to why the current spec is locking
client-side technologies out. As I said previously I think the spec is
lacking in the areas of specifying the lookup and dispatching technologies
to portlets, but I think that can come in a later revision of the spec, or
become a defacto standard through the promotion of technologies such as
Pluto that are (will be actually) under a very free license such as Apache.
I think the spec doesn't include client technology support as per say, but
I wouldn't say it "locks it out".
If I take a quick look at what is needed using todays technologies in order
to make the client-side experience nicer :
- Javascript
- DOM Level 2
- Probably LiveConnect if we want to interact with applets
- A way to communicate on a portlet basis with the server, be it iFrame, or
SOAP calls or something like that.
On the server-side we need :
- a SOAP server or an HTTP server that hooks up to the client
- A collection of portlets
Now what let's say that the portlets interact with the client through WSRP.
Why couldn't the WSRP server communicate with it's portlets through the
JSR-168 interfaces (which is exactly what Oracle's implementation does btw)
? It would then just be up to the implementation of the portlets to follow
guidelines (which are NOT in the spec), to interface well with the client
side controls. These guidelines might be what you think is lacking in the
spec, but as I see it it is technologically possible to do this, although
not as easy.
The point I am mostly trying to make here is that the spec is aimed at
defining how portlet developers should do their work in a broad and
all-encompassing fashion. Constraining them too much will probably scare
them away. Now they should ALSO have the possibility to write code without
any client-side controls, and the spec allows this too. But I think that if
there is some serious flaw in the spec that we have yet to uncover, either
we must correct it now if still possible, or it will be corrected in a
later update.
Regards,
Serge Huber.
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Serge Huber2 <sh...@jahia.com>.
At 14:44 06.08.2003 -0700, you wrote:
> The portlet spec is locking out client-side technologies!! If the
>arguments and points that I have presented have not convinced you then
>sobeit. I can pretty much guarantee you that going forward with the
>spec the way it is it will fail. Users are going to reject the slow
>performance the lack of being able to use good client-side technologies
>that other portal implementations are going to allow. The only way
>that I'll even consider designing anything around this current spec is
>to remove all of the portlet window state buttons and portlet mode
>buttons so that I can use some client-side technologies in the portal
>and the user won't be experiencing constant page reloading.
Well the spec is actually very close to the Servlet API in some ways. The
Servlet API is also quite minimal in it's coverage, and I wouldn't call it
a failure despite the fact that it didn't cover areas such as :
- browser capabilities
- client-side supported technologies
- file uploads
etc...
I do understand very well the point you are making. For example I
personally prefer to use an email client such as Evolution or Eudora than
using the web interface of Hotmail or Yahoo Mail. Why ? Because of all the
server round trips that do make some operations tedious. But I also like to
have my mail all in one place, and not have to login into seperate web
interfaces to check my mail, which I guess brings my needs back to portal
needs.
But I fail to understand your point as to why the current spec is locking
client-side technologies out. As I said previously I think the spec is
lacking in the areas of specifying the lookup and dispatching technologies
to portlets, but I think that can come in a later revision of the spec, or
become a defacto standard through the promotion of technologies such as
Pluto that are (will be actually) under a very free license such as Apache.
I think the spec doesn't include client technology support as per say, but
I wouldn't say it "locks it out".
If I take a quick look at what is needed using todays technologies in order
to make the client-side experience nicer :
- Javascript
- DOM Level 2
- Probably LiveConnect if we want to interact with applets
- A way to communicate on a portlet basis with the server, be it iFrame, or
SOAP calls or something like that.
On the server-side we need :
- a SOAP server or an HTTP server that hooks up to the client
- A collection of portlets
Now what let's say that the portlets interact with the client through WSRP.
Why couldn't the WSRP server communicate with it's portlets through the
JSR-168 interfaces (which is exactly what Oracle's implementation does btw)
? It would then just be up to the implementation of the portlets to follow
guidelines (which are NOT in the spec), to interface well with the client
side controls. These guidelines might be what you think is lacking in the
spec, but as I see it it is technologically possible to do this, although
not as easy.
The point I am mostly trying to make here is that the spec is aimed at
defining how portlet developers should do their work in a broad and
all-encompassing fashion. Constraining them too much will probably scare
them away. Now they should ALSO have the possibility to write code without
any client-side controls, and the spec allows this too. But I think that if
there is some serious flaw in the spec that we have yet to uncover, either
we must correct it now if still possible, or it will be corrected in a
later update.
Regards,
Serge Huber.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Erik Bruchez <er...@bruchez.org>.
> The portlet spec is locking out client-side technologies!! If the
> arguments and points that I have presented have not convinced you
> then sobeit.
I am not saying that the current spec does or does not lock out
client-side technologies. I for one would rather say that it carefully
avoids mentioning them. Some posters in this thread have started to
suggest that maybe you can use some client-side technologies while
still following 168. I don't know if that is realistic or not.
What I am saying though is that the world of client-side is complex
and unevenly supported by clients, I am suggesting that you make more
concrete suggestions as to how a portlet specification could support
them better than 168 does. Theory vs. practice, if you will.
> I can pretty much guarantee you that going forward with the spec the
> way it is it will fail.
Wanna bet money? ;-)
-Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Erik Bruchez <er...@bruchez.org>.
> The portlet spec is locking out client-side technologies!! If the
> arguments and points that I have presented have not convinced you
> then sobeit.
I am not saying that the current spec does or does not lock out
client-side technologies. I for one would rather say that it carefully
avoids mentioning them. Some posters in this thread have started to
suggest that maybe you can use some client-side technologies while
still following 168. I don't know if that is realistic or not.
What I am saying though is that the world of client-side is complex
and unevenly supported by clients, I am suggesting that you make more
concrete suggestions as to how a portlet specification could support
them better than 168 does. Theory vs. practice, if you will.
> I can pretty much guarantee you that going forward with the spec the
> way it is it will fail.
Wanna bet money? ;-)
-Erik
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Raphael,
>De : Gerry Reno [mailto:grenoml@yahoo.com]
>>
>> Erik, Serge (I'm going to respond to both of you here)
>>
>> <snip answe from Serge>
>>
>> I think that this spec needs to recognize that in order for
>> a portal to be able to preserve the context for client-side
>> technologies, which by definition means that you must
>> maintain the integrity of the main
>> page DOM, that it cannot have every portlet action reloading
>> the main page.
>> <snip iFrame based model description>
<snip/>
>I'll try summarize what has been said so far (I hope I will not
>miss a major point somewhere) :
>A1. you advocate the need for a strong support of client side
> technologies in the JSR 168 portal specificcation
Correct.
>A2 you propose a portal implementation model based around portlet
> content included in IFrame tags and a persistent client-side
> controller in the main page.
Yes.
>A3 Scott has proposed an alternate implementation model for
> the client side based around a reqsuest proxy to a hidden
> iFrame that is manipulated by the main window, which is
> interacting with the user.
I took this as essentially the same type of solution as A2.
>A4 Erik has stated that he needs to be convinced that advanced
> client-side technologies as a viable market right now due to
> lack of standard support in IE which has a commanding share
> of the browser market.
The minor issues with IE are well-known and can easily be worked
around.
>A5 Serge has stated that the current JSR 168 spec does allow portlet
> developers to take advantage a client-side technologies if they
> wish but it's a good thing that it does not require them to do so.
Well, only if the developer writes all the aggregation code and puts in
place all the necessary communication and window control mechanisms.
Not exactly the way to insure a portable standardized approach. There
would need to be a standard model developed and an implementation that
demonstrated the ability of this approach to work in all scenarios.
This is the type of thing that I'm looking for the spec to provide.
>A6 Several people have expressed the importance of supporting light
> clients (like CHTML, WML, etc...) with the spec.
Agreed. I don't see the two goals as conflicting.
>A7 Serge and myself have pointed out that WSRP would allow you to
> invoke a server based portlet and completely control the
> aggregation on the client.
see A5 comment.
>
>About A2, I must point out that in this setup *no* real output
>aggregation actually occurs since iFrames are really independant
>documents based on independant HTTP requests.
>I find this setup
>- limiting cross-portlet communication (like you can't use request
> attributes to pass information around between portlets on the same
> page) and portal-portlet communication (how to you refresh a page
> navigation title based on a portlet content change if you don't
> reload the page ?)
Is main page request attributes the only way that inter-portlet
communication can take place? I would hope not.
>- mush less efficient in terms of network and processing power for
> "information oriented" portals (like Yahoo), where probably 90%
> of the requests are read the page/update the page. In these
> scenarios the client-side code to download, the multiple request
> to process and possibly the larger amount of content you send out
> initially to the client to allow it to handle the minimize/maximize
> features without portal callback quickly add up to reduce the
> overall performance
I really disagree with this assessment. Yes, you are making more
requests but these requests are each much smaller. As far as sending
the data for a minimize/maximize without callback, as I stated, you
load the normalize view in the foreground and you load the maximize
view in the background and the user will not experience any difference
in performance.
>- difficult to implement for public sites where validating "rich"
> client-side portal features against many client configurations
> is a costly proposition.
We all do this today. It's not a big deal.
>- not necessarily extremely user friendly given the nature of
> IFRAME rendering, for example implementing a
> complete *printable* portal page around IFRAMEs, one that never
> truncates content, looks like a real challenge for me.
I don't think that most people are going to want to print the portal
page. What they want is to be able to print the 'portlet' page. This
is a simple manipulation of CSS attribute in the DOM.
>
>Based on the above, I personnally tend to agree with Erik to A4
>and with Serge would that JSR 168 has set out to standardize a
>portlet specification within a server-controlled aggregation process
>and has done a pretty good job of it, without imposing too many
>constraints on the developers although it *does* feel like they
>settled for the minimum common denominator this time around and that
>they could have gone further on some points.
>Since what you really call for is a client-controlled aggregation,
>I can only reiterate that you look closely at WSRP which will allow
>you to implement exactly any behavior you like while still leveraging
>JSR 168 compliant portal through a WSRP connector.
I understand WSRP and setting up client-side aggregation. But that
whole model, if it can be proven to work and to protect client-side
technologies, needs to be part of JSR-168 then. Otherwise, you'll have
no standard type of implementation that portlet developers can target.
There may need to be some types of portlet attributes such as
'persistent', 'non-persistent' and perhaps others that would apply in a
client-side aggregation model.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Raphael,
>De : Gerry Reno [mailto:grenoml@yahoo.com]
>>
>> Erik, Serge (I'm going to respond to both of you here)
>>
>> <snip answe from Serge>
>>
>> I think that this spec needs to recognize that in order for
>> a portal to be able to preserve the context for client-side
>> technologies, which by definition means that you must
>> maintain the integrity of the main
>> page DOM, that it cannot have every portlet action reloading
>> the main page.
>> <snip iFrame based model description>
<snip/>
>I'll try summarize what has been said so far (I hope I will not
>miss a major point somewhere) :
>A1. you advocate the need for a strong support of client side
> technologies in the JSR 168 portal specificcation
Correct.
>A2 you propose a portal implementation model based around portlet
> content included in IFrame tags and a persistent client-side
> controller in the main page.
Yes.
>A3 Scott has proposed an alternate implementation model for
> the client side based around a reqsuest proxy to a hidden
> iFrame that is manipulated by the main window, which is
> interacting with the user.
I took this as essentially the same type of solution as A2.
>A4 Erik has stated that he needs to be convinced that advanced
> client-side technologies as a viable market right now due to
> lack of standard support in IE which has a commanding share
> of the browser market.
The minor issues with IE are well-known and can easily be worked
around.
>A5 Serge has stated that the current JSR 168 spec does allow portlet
> developers to take advantage a client-side technologies if they
> wish but it's a good thing that it does not require them to do so.
Well, only if the developer writes all the aggregation code and puts in
place all the necessary communication and window control mechanisms.
Not exactly the way to insure a portable standardized approach. There
would need to be a standard model developed and an implementation that
demonstrated the ability of this approach to work in all scenarios.
This is the type of thing that I'm looking for the spec to provide.
>A6 Several people have expressed the importance of supporting light
> clients (like CHTML, WML, etc...) with the spec.
Agreed. I don't see the two goals as conflicting.
>A7 Serge and myself have pointed out that WSRP would allow you to
> invoke a server based portlet and completely control the
> aggregation on the client.
see A5 comment.
>
>About A2, I must point out that in this setup *no* real output
>aggregation actually occurs since iFrames are really independant
>documents based on independant HTTP requests.
>I find this setup
>- limiting cross-portlet communication (like you can't use request
> attributes to pass information around between portlets on the same
> page) and portal-portlet communication (how to you refresh a page
> navigation title based on a portlet content change if you don't
> reload the page ?)
Is main page request attributes the only way that inter-portlet
communication can take place? I would hope not.
>- mush less efficient in terms of network and processing power for
> "information oriented" portals (like Yahoo), where probably 90%
> of the requests are read the page/update the page. In these
> scenarios the client-side code to download, the multiple request
> to process and possibly the larger amount of content you send out
> initially to the client to allow it to handle the minimize/maximize
> features without portal callback quickly add up to reduce the
> overall performance
I really disagree with this assessment. Yes, you are making more
requests but these requests are each much smaller. As far as sending
the data for a minimize/maximize without callback, as I stated, you
load the normalize view in the foreground and you load the maximize
view in the background and the user will not experience any difference
in performance.
>- difficult to implement for public sites where validating "rich"
> client-side portal features against many client configurations
> is a costly proposition.
We all do this today. It's not a big deal.
>- not necessarily extremely user friendly given the nature of
> IFRAME rendering, for example implementing a
> complete *printable* portal page around IFRAMEs, one that never
> truncates content, looks like a real challenge for me.
I don't think that most people are going to want to print the portal
page. What they want is to be able to print the 'portlet' page. This
is a simple manipulation of CSS attribute in the DOM.
>
>Based on the above, I personnally tend to agree with Erik to A4
>and with Serge would that JSR 168 has set out to standardize a
>portlet specification within a server-controlled aggregation process
>and has done a pretty good job of it, without imposing too many
>constraints on the developers although it *does* feel like they
>settled for the minimum common denominator this time around and that
>they could have gone further on some points.
>Since what you really call for is a client-controlled aggregation,
>I can only reiterate that you look closely at WSRP which will allow
>you to implement exactly any behavior you like while still leveraging
>JSR 168 compliant portal through a WSRP connector.
I understand WSRP and setting up client-side aggregation. But that
whole model, if it can be proven to work and to protect client-side
technologies, needs to be part of JSR-168 then. Otherwise, you'll have
no standard type of implementation that portlet developers can target.
There may need to be some types of portlet attributes such as
'persistent', 'non-persistent' and perhaps others that would apply in a
client-side aggregation model.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi Erik,
--- Erik Bruchez <er...@bruchez.org> wrote:
> > You appear to be responding to the very beginning of the thread.
> > You might want to read through the rest of the thread.
>
> I did read the whole thread. My comments regarded your initial post,
> hence I replied to it.
>
> > They have made a number of improvements to support CSS. Agreed,
> > they didn't implement the box model correctly in V5 but this is
> well
> > known and easily compensated for.
>
> Really...
Yes, really. The latest techniques involve attempting to create a
box in the browser and then access the DOM and see what size it thinks
it is. Then you can compensate. Or are you thinking that you have to
use the old 'box hack' with all the goofy "\"}\"" type stuff?
>
> > By client-side technologies I"m referring to Flash, SVG, applets,
> > DHTML. These aren't at all flaky unless someone doesn't
> understand
> > how to work with them.
>
> I like SVG, but no browser natively supports the technology, you have
> to use a plugin. Mozilla support is far from being complete and
> stable, and IE doesn't care.
Look, don't just pick the latest cutting-edge client-side technology
to point to. DHTML, javascript, Flash work just fine.
>Applets not flaky: right!
And applets work just fine if you know anything about what you're
doing.
Yes, you have to use the tricks with the <embed> and <object> tags.
Big deal!
>
> > Totally disagree - round trips make for a completely annoying user
> > experience and it's what is wrong with many sites.
>
> That's unfortunate, but that's the best we have IMO.
>
> > Any proof-of-concept would have to come from those that are
> > interally familiar with the implementation. Perhaps some Jetspeed
> > team members might be willing to assist in producing such a proof.
> > I really don't think it necessary. I think the arguments and
> points
> > made in the thread speak for themselves.
>
> Out of the current 20 messages in this thread, 12 are by you, and
> *nobody* has made a single reply to any of your messages. My point is
> that there is no real discussion here, and no significant progress or
> definitive conclusion. The only arguments I see are yours, and of
> course you agree with yourself ;-)
Erik, I really have to wonder what your purpose is with these
statements? People have been responding my postings otherwise how else
would all my comments end up in their postings? I think as in the
other threads before on this issue many people are listening and
thinking about this issue. There are a lot of lurkers who are trying
to absorb this and who maybe don't feel comfortable with posting until
they manage to get a full grasp of everything.
>
> > If you read through all of the threads dealing with the issue you
> > will find examples of all of these things.
>
> I have, and I am not convinced. There are many applications and
> framework (mostly commercial) that have attempted to reproduce the
> desktop application model by delegating more of the UI logic in Web
> browsers. My experience so far is that they have all pretty much
> failed, in that they have been fragile, browser-dependent, and have
> not significantly improved the usability of Web applications. Just my
> $0.02 though. So I need to be convinced, that's all.
>
> -Erik
>
The portlet spec is locking out client-side technologies!! If the
arguments and points that I have presented have not convinced you then
sobeit. I can pretty much guarantee you that going forward with the
spec the way it is it will fail. Users are going to reject the slow
performance the lack of being able to use good client-side technologies
that other portal implementations are going to allow. The only way
that I'll even consider designing anything around this current spec is
to remove all of the portlet window state buttons and portlet mode
buttons so that I can use some client-side technologies in the portal
and the user won't be experiencing constant page reloading.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi Erik,
--- Erik Bruchez <er...@bruchez.org> wrote:
> > You appear to be responding to the very beginning of the thread.
> > You might want to read through the rest of the thread.
>
> I did read the whole thread. My comments regarded your initial post,
> hence I replied to it.
>
> > They have made a number of improvements to support CSS. Agreed,
> > they didn't implement the box model correctly in V5 but this is
> well
> > known and easily compensated for.
>
> Really...
Yes, really. The latest techniques involve attempting to create a
box in the browser and then access the DOM and see what size it thinks
it is. Then you can compensate. Or are you thinking that you have to
use the old 'box hack' with all the goofy "\"}\"" type stuff?
>
> > By client-side technologies I"m referring to Flash, SVG, applets,
> > DHTML. These aren't at all flaky unless someone doesn't
> understand
> > how to work with them.
>
> I like SVG, but no browser natively supports the technology, you have
> to use a plugin. Mozilla support is far from being complete and
> stable, and IE doesn't care.
Look, don't just pick the latest cutting-edge client-side technology
to point to. DHTML, javascript, Flash work just fine.
>Applets not flaky: right!
And applets work just fine if you know anything about what you're
doing.
Yes, you have to use the tricks with the <embed> and <object> tags.
Big deal!
>
> > Totally disagree - round trips make for a completely annoying user
> > experience and it's what is wrong with many sites.
>
> That's unfortunate, but that's the best we have IMO.
>
> > Any proof-of-concept would have to come from those that are
> > interally familiar with the implementation. Perhaps some Jetspeed
> > team members might be willing to assist in producing such a proof.
> > I really don't think it necessary. I think the arguments and
> points
> > made in the thread speak for themselves.
>
> Out of the current 20 messages in this thread, 12 are by you, and
> *nobody* has made a single reply to any of your messages. My point is
> that there is no real discussion here, and no significant progress or
> definitive conclusion. The only arguments I see are yours, and of
> course you agree with yourself ;-)
Erik, I really have to wonder what your purpose is with these
statements? People have been responding my postings otherwise how else
would all my comments end up in their postings? I think as in the
other threads before on this issue many people are listening and
thinking about this issue. There are a lot of lurkers who are trying
to absorb this and who maybe don't feel comfortable with posting until
they manage to get a full grasp of everything.
>
> > If you read through all of the threads dealing with the issue you
> > will find examples of all of these things.
>
> I have, and I am not convinced. There are many applications and
> framework (mostly commercial) that have attempted to reproduce the
> desktop application model by delegating more of the UI logic in Web
> browsers. My experience so far is that they have all pretty much
> failed, in that they have been fragile, browser-dependent, and have
> not significantly improved the usability of Web applications. Just my
> $0.02 though. So I need to be convinced, that's all.
>
> -Erik
>
The portlet spec is locking out client-side technologies!! If the
arguments and points that I have presented have not convinced you then
sobeit. I can pretty much guarantee you that going forward with the
spec the way it is it will fail. Users are going to reject the slow
performance the lack of being able to use good client-side technologies
that other portal implementations are going to allow. The only way
that I'll even consider designing anything around this current spec is
to remove all of the portlet window state buttons and portlet mode
buttons so that I can use some client-side technologies in the portal
and the user won't be experiencing constant page reloading.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Erik Bruchez <er...@bruchez.org>.
> You appear to be responding to the very beginning of the thread.
> You might want to read through the rest of the thread.
I did read the whole thread. My comments regarded your initial post,
hence I replied to it.
> They have made a number of improvements to support CSS. Agreed,
> they didn't implement the box model correctly in V5 but this is well
> known and easily compensated for.
Really...
> By client-side technologies I"m referring to Flash, SVG, applets,
> DHTML. These aren't at all flaky unless someone doesn't understand
> how to work with them.
I like SVG, but no browser natively supports the technology, you have
to use a plugin. Mozilla support is far from being complete and
stable, and IE doesn't care. Applets not flaky: right!
> Totally disagree - round trips make for a completely annoying user
> experience and it's what is wrong with many sites.
That's unfortunate, but that's the best we have IMO.
> Any proof-of-concept would have to come from those that are
> interally familiar with the implementation. Perhaps some Jetspeed
> team members might be willing to assist in producing such a proof.
> I really don't think it necessary. I think the arguments and points
> made in the thread speak for themselves.
Out of the current 20 messages in this thread, 12 are by you, and
*nobody* has made a single reply to any of your messages. My point is
that there is no real discussion here, and no significant progress or
definitive conclusion. The only arguments I see are yours, and of
course you agree with yourself ;-)
> If you read through all of the threads dealing with the issue you
> will find examples of all of these things.
I have, and I am not convinced. There are many applications and
framework (mostly commercial) that have attempted to reproduce the
desktop application model by delegating more of the UI logic in Web
browsers. My experience so far is that they have all pretty much
failed, in that they have been fragile, browser-dependent, and have
not significantly improved the usability of Web applications. Just my
$0.02 though. So I need to be convinced, that's all.
-Erik
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Erik Bruchez <er...@bruchez.org>.
> You appear to be responding to the very beginning of the thread.
> You might want to read through the rest of the thread.
I did read the whole thread. My comments regarded your initial post,
hence I replied to it.
> They have made a number of improvements to support CSS. Agreed,
> they didn't implement the box model correctly in V5 but this is well
> known and easily compensated for.
Really...
> By client-side technologies I"m referring to Flash, SVG, applets,
> DHTML. These aren't at all flaky unless someone doesn't understand
> how to work with them.
I like SVG, but no browser natively supports the technology, you have
to use a plugin. Mozilla support is far from being complete and
stable, and IE doesn't care. Applets not flaky: right!
> Totally disagree - round trips make for a completely annoying user
> experience and it's what is wrong with many sites.
That's unfortunate, but that's the best we have IMO.
> Any proof-of-concept would have to come from those that are
> interally familiar with the implementation. Perhaps some Jetspeed
> team members might be willing to assist in producing such a proof.
> I really don't think it necessary. I think the arguments and points
> made in the thread speak for themselves.
Out of the current 20 messages in this thread, 12 are by you, and
*nobody* has made a single reply to any of your messages. My point is
that there is no real discussion here, and no significant progress or
definitive conclusion. The only arguments I see are yours, and of
course you agree with yourself ;-)
> If you read through all of the threads dealing with the issue you
> will find examples of all of these things.
I have, and I am not convinced. There are many applications and
framework (mostly commercial) that have attempted to reproduce the
desktop application model by delegating more of the UI logic in Web
browsers. My experience so far is that they have all pretty much
failed, in that they have been fragile, browser-dependent, and have
not significantly improved the usability of Web applications. Just my
$0.02 though. So I need to be convinced, that's all.
-Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi Erik,
You appear to be responding to the very beginning of the thread. You
might want to read through the rest of the thread.
--- Erik Bruchez <er...@bruchez.org> wrote:
> Gerry,
>
> You are starting a debate very similar to the one around JavaServer
> Faces. Both JSRs strictly focus around a strictly server-side
> framework as opposed to a client-side framework (or a combination of
> both).
>
> To the defense of JSR-168, I think that client-side technologies are
> at best flaky, a situation that hasn't changed much in 4-5 years
> now. Microsoft hasn't made one significant improvement to IE since
> version 4.
They have made a number of improvements to support CSS. Agreed, they
didn't implement the box model correctly in V5 but this is well known
and easily compensated for.
By client-side technologies I"m referring to Flash, SVG, applets,
DHTML. These aren't at all flaky unless someone doesn't understand how
to work with them.
>Mozilla has done better, but represents an almost
> insignificant market share. There is just not much happening in that
> arena today, partly because of IE's monopoly. The question of chosing
> a technology common denominator is difficult.
>
> The trend in the past few years has been to go back to server-side
> technologies generating pretty basic HTML, JavaScript and CSS. Today,
> the Web sites and Web apps with the best usability IMO are the ones
> that try to minimize the use of fancy client-side technologies. In
> theory diminishing the number of round-trips to the server is better,
> but the reality is that round-trips work!
Totally disagree - round trips make for a completely annoying user
experience and it's what is wrong with many sites. It only works from
the standpoint of being able to pick up server-side data.
>
> In addition, the JSR must allows for different types of clients, such
> as PDAs. It also must be 100% agnostic wrt the technology used for
> the
> presentation (JSP, XSLT, etc.). Clearly not everybody has
> standardized
> on JSP.
>
> I think some of your concerns are valid (but not too important to
> somebody like me I have to say) but remain way too theoretical. The
> best approach to convince people would be to point to an
> implementation addressing them. Such an proof of concept could be a
> good basis for inclusion in a JSR.
>
> -Erik
>
Any proof-of-concept would have to come from those that are interally
familiar with the implementation. Perhaps some Jetspeed team members
might be willing to assist in producing such a proof. I really don't
think it necessary. I think the arguments and points made in the
thread speak for themselves. The current portlet spec completely
destroys the capabilities of client-side technologies. In fact, some
of the existing portlets do not even function properly due to the
interaction model being dictated by the spec. If you read through all
of the threads dealing with the issue you will find examples of all of
these things.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi Erik,
You appear to be responding to the very beginning of the thread. You
might want to read through the rest of the thread.
--- Erik Bruchez <er...@bruchez.org> wrote:
> Gerry,
>
> You are starting a debate very similar to the one around JavaServer
> Faces. Both JSRs strictly focus around a strictly server-side
> framework as opposed to a client-side framework (or a combination of
> both).
>
> To the defense of JSR-168, I think that client-side technologies are
> at best flaky, a situation that hasn't changed much in 4-5 years
> now. Microsoft hasn't made one significant improvement to IE since
> version 4.
They have made a number of improvements to support CSS. Agreed, they
didn't implement the box model correctly in V5 but this is well known
and easily compensated for.
By client-side technologies I"m referring to Flash, SVG, applets,
DHTML. These aren't at all flaky unless someone doesn't understand how
to work with them.
>Mozilla has done better, but represents an almost
> insignificant market share. There is just not much happening in that
> arena today, partly because of IE's monopoly. The question of chosing
> a technology common denominator is difficult.
>
> The trend in the past few years has been to go back to server-side
> technologies generating pretty basic HTML, JavaScript and CSS. Today,
> the Web sites and Web apps with the best usability IMO are the ones
> that try to minimize the use of fancy client-side technologies. In
> theory diminishing the number of round-trips to the server is better,
> but the reality is that round-trips work!
Totally disagree - round trips make for a completely annoying user
experience and it's what is wrong with many sites. It only works from
the standpoint of being able to pick up server-side data.
>
> In addition, the JSR must allows for different types of clients, such
> as PDAs. It also must be 100% agnostic wrt the technology used for
> the
> presentation (JSP, XSLT, etc.). Clearly not everybody has
> standardized
> on JSP.
>
> I think some of your concerns are valid (but not too important to
> somebody like me I have to say) but remain way too theoretical. The
> best approach to convince people would be to point to an
> implementation addressing them. Such an proof of concept could be a
> good basis for inclusion in a JSR.
>
> -Erik
>
Any proof-of-concept would have to come from those that are interally
familiar with the implementation. Perhaps some Jetspeed team members
might be willing to assist in producing such a proof. I really don't
think it necessary. I think the arguments and points made in the
thread speak for themselves. The current portlet spec completely
destroys the capabilities of client-side technologies. In fact, some
of the existing portlets do not even function properly due to the
interaction model being dictated by the spec. If you read through all
of the threads dealing with the issue you will find examples of all of
these things.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Erik Bruchez <er...@bruchez.org>.
Gerry,
You are starting a debate very similar to the one around JavaServer
Faces. Both JSRs strictly focus around a strictly server-side
framework as opposed to a client-side framework (or a combination of
both).
To the defense of JSR-168, I think that client-side technologies are
at best flaky, a situation that hasn't changed much in 4-5 years
now. Microsoft hasn't made one significant improvement to IE since
version 4. Mozilla has done better, but represents an almost
insignificant market share. There is just not much happening in that
arena today, partly because of IE's monopoly. The question of chosing
a technology common denominator is difficult.
The trend in the past few years has been to go back to server-side
technologies generating pretty basic HTML, JavaScript and CSS. Today,
the Web sites and Web apps with the best usability IMO are the ones
that try to minimize the use of fancy client-side technologies. In
theory diminishing the number of round-trips to the server is better,
but the reality is that round-trips work!
In addition, the JSR must allows for different types of clients, such
as PDAs. It also must be 100% agnostic wrt the technology used for the
presentation (JSP, XSLT, etc.). Clearly not everybody has standardized
on JSP.
I think some of your concerns are valid (but not too important to
somebody like me I have to say) but remain way too theoretical. The
best approach to convince people would be to point to an
implementation addressing them. Such an proof of concept could be a
good basis for inclusion in a JSR.
-Erik
Gerry Reno wrote:
> I just finished reading the article " Introducing the Portlet
> Specification, Part 1" in JavaWorld. I was hoping to find there some
> latitude in the portlet spec that would allow for a portlet interaction
> model such as I had proposed to the JSR-168 team in response to the
> public release of the spec and in these two threads:
> http://marc.theaimsgroup.com/?l=jetspeed-user&m=105850057414235&w=2
>
> http://marc.theaimsgroup.com/?l=jetspeed-user&m=105846310309122&w=2
>
> Unfortunately there appears to be no latitude in the spec. The JSR-168
> spec is supposed to permit creation of Enterprise Information Portals
> (EIP) using standardized portlets that are portable. This is good.
> But, I think that a lot of people have got themselves so caught up in
> the portlet lifecycle and the API and the storing of persistent portlet
> data and how do I create a ______ type portlet and all the rest that
> they are failing to look at a bigger picture of some of the
> human-factors and user-experience perspectives and expectations with
> regard to web enterprise information portals. From my perspective this
> is very important since JSR-168 is going to be declared *the* standard.
> The standard should provide enough flexibility to accomodate all the
> common types of paradigms and technologies to which users have come to
> use when utilizing the Web.
> The portlet spec as currently written is analogous to having a number
> of browsers open on your desktop and each one would represent a portlet
> and if you were to hit the reload button or minimize or maximize or
> submit a form from any of them, then all of them would reload their
> pages. Well this works great if you don't mind losing any client-side
> processing that is going on. The problem is that users are accustomed
> to having client-side processing and in fact expect a consistent
> context when interacting with client-side technologies. As it stands
> now, the portlet spec is dictating that every portlet mode or window
> state change causes an action request to be sent to the server. If you
> understand how the browser and pages and the document object model and
> browser client-side technologies work you immediately realize that
> constantly reloading pages is not a good thing.
> Ok, let's look at a real simple example. A user is interacting with
> an information rich JSR-168 portal. In the portal there is a media
> player portlet that allows the user to select from a list of available
> videos to view and there are other portlets on the page for various
> other information purposes. While the user is viewing a video
> presentation, one of these other portlets is doing something
> distracting and the user would like to minimize it so that the user can
> concentrate on the video presentation. Under the current JSR-168 spec
> the user's action to minimize this portlet results in a page request
> being sent back to the server which in turn results in the page being
> reloaded. What that does is destroy the original document object model
> (DOM) in the browser representing the original page and the subsequent
> creation of a new DOM representing the newly reloaded page. All
> running embedded client-side technologies such as applets, DHTML,
> javascript, Flash, SVG, etc. etc. are destroyed losing their contexts.
> The browser then redraws the reloaded page and all the portlets and
> initializes and starts all client-side scripts, modules, applets,
> objects, etc. once again. Well, for our user watching the video what
> happens is that the media player in the portlet is destroyed,
> recreated, initialized and starts over waiting for the user to make a
> video selection. Not exactly what the user would expect. Users are
> used to doing things like expanding and contracting lists, boxes and
> tables without seeing an expensive round trip to the server and a page
> reload. These are all things that are very easy to do on the client
> using DHTML, javascript, Flash, SVG or any other of the client-side
> technologies that can manipulate the DOM. In a broader perspective,
> under the current JSR-168 spec, all uses of client-side technologies
> are severely limited due to the interaction model dictated by the spec.
>
> Another issue is the user's perception of performance. I submit that
> a better model is one in which Java dovetails with client-side
> technologies to minimize round-trips to the server. Try testing a
> Jetspeed portal from a dial-up connection. If you are interacting with
> its portlets and using any of the buttons controlling portlet mode or
> window state, each button press results is a new page being served with
> the net experience being a portal that is painfully slow. What I
> notice a lot of the current Jetspeed sites doing is completely removing
> any of the portlet mode or window state buttons from the portlets and
> forcing the user into a rigid predetermined layout. This reduces the
> abilty of a user to cause a page reload but it defeats nearly all of
> the user preference flexibility of the portal.
> To create a portal model that will provide for a good user experience
> is going to require both server-side and client-side technologies
> working together. I would much rather see portlets implemented as
> either all iframes that can be controlled and reloaded individually or
> even better as something like CSS <div> elements that can dynamically
> be controlled on the client-side by DHTML, javascript, Flash, SVG, etc.
> for things like minimizing, maximizing, print-friendly, help, edit.
> That way the only thing that is going to cause a trip to the server is
> something like a form submit and even that should be done in a iframe
> so that the rest of the page doesn't reload.
> Please take some time to think about this spec and the type of portal
> behavior into which users will be locked. For a portal operating under
> my suggested model, when the user want to maximize a portlet, the
> portlet is nearly instanteously maximized with enhanced content and
> none of this is requiring a trip to the server. Additionally the user
> can now maximize, normalize, and minimize the portlet as many times as
> they like all without any requests being sent to the server. The
> portal can now even operate in an offline mode, the DOM integrity has
> been maintained so client-side technologies function as expected,
> portlets such as Jetspeed's IFramePortlet function properly, and the
> user is experiencing near instanteous response from the user interface
> and their overall experience will be much more satisfying.
>
> rgds,
> Gerry Reno
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Helmut Tammen <HT...@htsystemloesungen.de>.
Hi,
I came a little bit late to this discussion.
You should have had a look at the SAP Enterprise Portal
(http://www.iviewstudio.com). They already extensively work with iFrames.
Each portlet (they call them iViews) is enclosed in an iFrame.
And furthermore they have sophisticated client side features like
client-side eventing to send messages from one portlet (iView) to
another and the client data-bag to exchange data from one portlet to
another.
With client-side eventing a portlet (in an iFrame) for example can send
a request (data from a form) to the server and then inform another
portlet (in another iFrame) that it should update itself because the
data at the server has changed.
The data-bag for example can be used to fill the fields of a form in
portlet 1 upon a selection in portlet 2.
Another feature is the possibility to store the state of a portlet at
the client and restore it later. This can be used if the user filled a
lot of data into a form, then quickly goes to another portal page
without sending the form data to the server (for example to look at his
mailbox) and afterwards returns to the portlet with the form. After
returning to this portlet all the data is still available.
I haven´t worked with this feature yet but I was told that it´s possible.
These features together with the server-side framework make it possible
to build complex portal applications with portlets that interact with
each other.
If you are interested in it you can download the PDK (Portal Development
Kit) from http://www.iviewstudio.com. The PDK is a small version of the
Enterpise Portal which can be installed within tomcat. It encloses a lot
of examples an more detailed documentation of the mentioned features.
Unfortunatly it´s not Open Source. When I switched to Jetspeed (because
it is OSS) I missed these features.
regards
Helmut
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Erik Bruchez <er...@bruchez.org>.
Gerry,
You are starting a debate very similar to the one around JavaServer
Faces. Both JSRs strictly focus around a strictly server-side
framework as opposed to a client-side framework (or a combination of
both).
To the defense of JSR-168, I think that client-side technologies are
at best flaky, a situation that hasn't changed much in 4-5 years
now. Microsoft hasn't made one significant improvement to IE since
version 4. Mozilla has done better, but represents an almost
insignificant market share. There is just not much happening in that
arena today, partly because of IE's monopoly. The question of chosing
a technology common denominator is difficult.
The trend in the past few years has been to go back to server-side
technologies generating pretty basic HTML, JavaScript and CSS. Today,
the Web sites and Web apps with the best usability IMO are the ones
that try to minimize the use of fancy client-side technologies. In
theory diminishing the number of round-trips to the server is better,
but the reality is that round-trips work!
In addition, the JSR must allows for different types of clients, such
as PDAs. It also must be 100% agnostic wrt the technology used for the
presentation (JSP, XSLT, etc.). Clearly not everybody has standardized
on JSP.
I think some of your concerns are valid (but not too important to
somebody like me I have to say) but remain way too theoretical. The
best approach to convince people would be to point to an
implementation addressing them. Such an proof of concept could be a
good basis for inclusion in a JSR.
-Erik
Gerry Reno wrote:
> I just finished reading the article " Introducing the Portlet
> Specification, Part 1" in JavaWorld. I was hoping to find there some
> latitude in the portlet spec that would allow for a portlet interaction
> model such as I had proposed to the JSR-168 team in response to the
> public release of the spec and in these two threads:
> http://marc.theaimsgroup.com/?l=jetspeed-user&m=105850057414235&w=2
>
> http://marc.theaimsgroup.com/?l=jetspeed-user&m=105846310309122&w=2
>
> Unfortunately there appears to be no latitude in the spec. The JSR-168
> spec is supposed to permit creation of Enterprise Information Portals
> (EIP) using standardized portlets that are portable. This is good.
> But, I think that a lot of people have got themselves so caught up in
> the portlet lifecycle and the API and the storing of persistent portlet
> data and how do I create a ______ type portlet and all the rest that
> they are failing to look at a bigger picture of some of the
> human-factors and user-experience perspectives and expectations with
> regard to web enterprise information portals. From my perspective this
> is very important since JSR-168 is going to be declared *the* standard.
> The standard should provide enough flexibility to accomodate all the
> common types of paradigms and technologies to which users have come to
> use when utilizing the Web.
> The portlet spec as currently written is analogous to having a number
> of browsers open on your desktop and each one would represent a portlet
> and if you were to hit the reload button or minimize or maximize or
> submit a form from any of them, then all of them would reload their
> pages. Well this works great if you don't mind losing any client-side
> processing that is going on. The problem is that users are accustomed
> to having client-side processing and in fact expect a consistent
> context when interacting with client-side technologies. As it stands
> now, the portlet spec is dictating that every portlet mode or window
> state change causes an action request to be sent to the server. If you
> understand how the browser and pages and the document object model and
> browser client-side technologies work you immediately realize that
> constantly reloading pages is not a good thing.
> Ok, let's look at a real simple example. A user is interacting with
> an information rich JSR-168 portal. In the portal there is a media
> player portlet that allows the user to select from a list of available
> videos to view and there are other portlets on the page for various
> other information purposes. While the user is viewing a video
> presentation, one of these other portlets is doing something
> distracting and the user would like to minimize it so that the user can
> concentrate on the video presentation. Under the current JSR-168 spec
> the user's action to minimize this portlet results in a page request
> being sent back to the server which in turn results in the page being
> reloaded. What that does is destroy the original document object model
> (DOM) in the browser representing the original page and the subsequent
> creation of a new DOM representing the newly reloaded page. All
> running embedded client-side technologies such as applets, DHTML,
> javascript, Flash, SVG, etc. etc. are destroyed losing their contexts.
> The browser then redraws the reloaded page and all the portlets and
> initializes and starts all client-side scripts, modules, applets,
> objects, etc. once again. Well, for our user watching the video what
> happens is that the media player in the portlet is destroyed,
> recreated, initialized and starts over waiting for the user to make a
> video selection. Not exactly what the user would expect. Users are
> used to doing things like expanding and contracting lists, boxes and
> tables without seeing an expensive round trip to the server and a page
> reload. These are all things that are very easy to do on the client
> using DHTML, javascript, Flash, SVG or any other of the client-side
> technologies that can manipulate the DOM. In a broader perspective,
> under the current JSR-168 spec, all uses of client-side technologies
> are severely limited due to the interaction model dictated by the spec.
>
> Another issue is the user's perception of performance. I submit that
> a better model is one in which Java dovetails with client-side
> technologies to minimize round-trips to the server. Try testing a
> Jetspeed portal from a dial-up connection. If you are interacting with
> its portlets and using any of the buttons controlling portlet mode or
> window state, each button press results is a new page being served with
> the net experience being a portal that is painfully slow. What I
> notice a lot of the current Jetspeed sites doing is completely removing
> any of the portlet mode or window state buttons from the portlets and
> forcing the user into a rigid predetermined layout. This reduces the
> abilty of a user to cause a page reload but it defeats nearly all of
> the user preference flexibility of the portal.
> To create a portal model that will provide for a good user experience
> is going to require both server-side and client-side technologies
> working together. I would much rather see portlets implemented as
> either all iframes that can be controlled and reloaded individually or
> even better as something like CSS <div> elements that can dynamically
> be controlled on the client-side by DHTML, javascript, Flash, SVG, etc.
> for things like minimizing, maximizing, print-friendly, help, edit.
> That way the only thing that is going to cause a trip to the server is
> something like a form submit and even that should be done in a iframe
> so that the rest of the page doesn't reload.
> Please take some time to think about this spec and the type of portal
> behavior into which users will be locked. For a portal operating under
> my suggested model, when the user want to maximize a portlet, the
> portlet is nearly instanteously maximized with enhanced content and
> none of this is requiring a trip to the server. Additionally the user
> can now maximize, normalize, and minimize the portlet as many times as
> they like all without any requests being sent to the server. The
> portal can now even operate in an offline mode, the DOM integrity has
> been maintained so client-side technologies function as expected,
> portlets such as Jetspeed's IFramePortlet function properly, and the
> user is experiencing near instanteous response from the user interface
> and their overall experience will be much more satisfying.
>
> rgds,
> Gerry Reno
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Helmut Tammen <HT...@htsystemloesungen.de>.
Hi,
I came a little bit late to this discussion.
You should have had a look at the SAP Enterprise Portal
(http://www.iviewstudio.com). They already extensively work with iFrames.
Each portlet (they call them iViews) is enclosed in an iFrame.
And furthermore they have sophisticated client side features like
client-side eventing to send messages from one portlet (iView) to
another and the client data-bag to exchange data from one portlet to
another.
With client-side eventing a portlet (in an iFrame) for example can send
a request (data from a form) to the server and then inform another
portlet (in another iFrame) that it should update itself because the
data at the server has changed.
The data-bag for example can be used to fill the fields of a form in
portlet 1 upon a selection in portlet 2.
Another feature is the possibility to store the state of a portlet at
the client and restore it later. This can be used if the user filled a
lot of data into a form, then quickly goes to another portal page
without sending the form data to the server (for example to look at his
mailbox) and afterwards returns to the portlet with the form. After
returning to this portlet all the data is still available.
I haven´t worked with this feature yet but I was told that it´s possible.
These features together with the server-side framework make it possible
to build complex portal applications with portlets that interact with
each other.
If you are interested in it you can download the PDK (Portal Development
Kit) from http://www.iviewstudio.com. The PDK is a small version of the
Enterpise Portal which can be installed within tomcat. It encloses a lot
of examples an more detailed documentation of the mentioned features.
Unfortunatly it´s not Open Source. When I switched to Jetspeed (because
it is OSS) I missed these features.
regards
Helmut
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Marc Tremblay <ma...@tremblay.name>.
While I agree that allowing for the use of rich client side technologies
is highly desirable, we need to remember that not all user agents will
be able to support said technologies. I'm thinking specifically of the
myriad of WML devices out there. Since this is an initial spec, I'm
much happier that it is capable of working with user agents of limited
ability than if such user agents were forgotten altogether or simply
tacked on at the end.
Let's get a foundation in place first, then we can tweak it. It reminds
me of the EJB 1.0 spec whose greatest purpose, IMO, was to be the
foundation for later revisions which were actually usable.
-- Marc
On Tue, 2003-08-05 at 19:47, Gerry Reno wrote:
> I just finished reading the article " Introducing the Portlet
> Specification, Part 1" in JavaWorld. I was hoping to find there some
> latitude in the portlet spec that would allow for a portlet interaction
> model such as I had proposed to the JSR-168 team in response to the
> public release of the spec and in these two threads:
> http://marc.theaimsgroup.com/?l=jetspeed-user&m=105850057414235&w=2
>
> http://marc.theaimsgroup.com/?l=jetspeed-user&m=105846310309122&w=2
>
> Unfortunately there appears to be no latitude in the spec. The JSR-168
> spec is supposed to permit creation of Enterprise Information Portals
> (EIP) using standardized portlets that are portable. This is good.
> But, I think that a lot of people have got themselves so caught up in
> the portlet lifecycle and the API and the storing of persistent portlet
> data and how do I create a ______ type portlet and all the rest that
> they are failing to look at a bigger picture of some of the
> human-factors and user-experience perspectives and expectations with
> regard to web enterprise information portals. From my perspective this
> is very important since JSR-168 is going to be declared *the* standard.
> The standard should provide enough flexibility to accomodate all the
> common types of paradigms and technologies to which users have come to
> use when utilizing the Web.
> The portlet spec as currently written is analogous to having a number
> of browsers open on your desktop and each one would represent a portlet
> and if you were to hit the reload button or minimize or maximize or
> submit a form from any of them, then all of them would reload their
> pages. Well this works great if you don't mind losing any client-side
> processing that is going on. The problem is that users are accustomed
> to having client-side processing and in fact expect a consistent
> context when interacting with client-side technologies. As it stands
> now, the portlet spec is dictating that every portlet mode or window
> state change causes an action request to be sent to the server. If you
> understand how the browser and pages and the document object model and
> browser client-side technologies work you immediately realize that
> constantly reloading pages is not a good thing.
> Ok, let's look at a real simple example. A user is interacting with
> an information rich JSR-168 portal. In the portal there is a media
> player portlet that allows the user to select from a list of available
> videos to view and there are other portlets on the page for various
> other information purposes. While the user is viewing a video
> presentation, one of these other portlets is doing something
> distracting and the user would like to minimize it so that the user can
> concentrate on the video presentation. Under the current JSR-168 spec
> the user's action to minimize this portlet results in a page request
> being sent back to the server which in turn results in the page being
> reloaded. What that does is destroy the original document object model
> (DOM) in the browser representing the original page and the subsequent
> creation of a new DOM representing the newly reloaded page. All
> running embedded client-side technologies such as applets, DHTML,
> javascript, Flash, SVG, etc. etc. are destroyed losing their contexts.
> The browser then redraws the reloaded page and all the portlets and
> initializes and starts all client-side scripts, modules, applets,
> objects, etc. once again. Well, for our user watching the video what
> happens is that the media player in the portlet is destroyed,
> recreated, initialized and starts over waiting for the user to make a
> video selection. Not exactly what the user would expect. Users are
> used to doing things like expanding and contracting lists, boxes and
> tables without seeing an expensive round trip to the server and a page
> reload. These are all things that are very easy to do on the client
> using DHTML, javascript, Flash, SVG or any other of the client-side
> technologies that can manipulate the DOM. In a broader perspective,
> under the current JSR-168 spec, all uses of client-side technologies
> are severely limited due to the interaction model dictated by the spec.
>
> Another issue is the user's perception of performance. I submit that
> a better model is one in which Java dovetails with client-side
> technologies to minimize round-trips to the server. Try testing a
> Jetspeed portal from a dial-up connection. If you are interacting with
> its portlets and using any of the buttons controlling portlet mode or
> window state, each button press results is a new page being served with
> the net experience being a portal that is painfully slow. What I
> notice a lot of the current Jetspeed sites doing is completely removing
> any of the portlet mode or window state buttons from the portlets and
> forcing the user into a rigid predetermined layout. This reduces the
> abilty of a user to cause a page reload but it defeats nearly all of
> the user preference flexibility of the portal.
> To create a portal model that will provide for a good user experience
> is going to require both server-side and client-side technologies
> working together. I would much rather see portlets implemented as
> either all iframes that can be controlled and reloaded individually or
> even better as something like CSS <div> elements that can dynamically
> be controlled on the client-side by DHTML, javascript, Flash, SVG, etc.
> for things like minimizing, maximizing, print-friendly, help, edit.
> That way the only thing that is going to cause a trip to the server is
> something like a form submit and even that should be done in a iframe
> so that the rest of the page doesn't reload.
> Please take some time to think about this spec and the type of portal
> behavior into which users will be locked. For a portal operating under
> my suggested model, when the user want to maximize a portlet, the
> portlet is nearly instanteously maximized with enhanced content and
> none of this is requiring a trip to the server. Additionally the user
> can now maximize, normalize, and minimize the portlet as many times as
> they like all without any requests being sent to the server. The
> portal can now even operate in an offline mode, the DOM integrity has
> been maintained so client-side technologies function as expected,
> portlets such as Jetspeed's IFramePortlet function properly, and the
> user is experiencing near instanteous response from the user interface
> and their overall experience will be much more satisfying.
>
> rgds,
> Gerry Reno
>
>
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! SiteBuilder - Free, easy-to-use web site design software
> http://sitebuilder.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi David,
> On Tuesday, August 5, 2003, at 06:47 PM, Gerry Reno wrote:
> > From my perspective this
> > is very important since JSR-168 is going to be declared *the*
> standard.
> > The standard should provide enough flexibility to accomodate all
> the
> > common types of paradigms and technologies to which users have come
> to
> > use when utilizing the Web.
> > The portlet spec as currently written is analogous to having a
> number
> > of browsers open on your desktop and each one would represent a
> portlet
> > and if you were to hit the reload button or minimize or maximize or
> > submit a form from any of them, then all of them would reload their
> > pages. Well this works great if you don't mind losing any
> client-side
> > processing that is going on. The problem is that users are
> accustomed
> > to having client-side processing and in fact expect a consistent
> > context when interacting with client-side technologies. As it
> stands
> > now, the portlet spec is dictating that every portlet mode or
> window
> > state change causes an action request to be sent to the server. If
> you
> > understand how the browser and pages and the document object model
> and
> > browser client-side technologies work you immediately realize that
> > constantly reloading pages is not a good thing.
>
--- David Sean Taylor <da...@bluesunrise.com> wrote:
>
> With the portlet api, you are free to handle client-side programming,
>
> inside the scripts and content generated by your portlet.
> However portal-level events such as minimize and maximize, or a
> portlet
> action, must be passed back to the portal so that the
> targeted portlet is notified of the event. Portlets, like servlets,
> are
> server-side objects and that is what the Java specification focuses
> on.
>
> Im thinking about your maximize example. Wouldn't most cases require
> different or more content in maximized mode, requiring a trip back to
>
> the server?
> Same for print friendly mode.
This is what I am talking about when I refer to client-side
technologies being severely restricted. Any client-side technologies
are going to be limited by the fact that they will live only until the
next button press on the portal and then they will be destroyed and
recreated with the next page load. For client-side technologies it's
as a famous catcher once said, "It's deja-vu all over again".
As far as the maximize example, if you remember from some of my other
threads that what is expensive is server round-trips. My preference
would be to see that all the content, both normalized and maximized
markup is sent to the browser in the initial request and then window
state changes only cause that content to be revealed or hidden as
appropriate. The content for the normal display can be sent with the
additional content for maximized view being loaded in the background so
that there is no delay in the presentation of the portal page to the
user. As far as print-friendly, you just go from a CSS attribute of
'media=screen' to 'media=print'. You can just manipulate the DOM to
cause this to happen! You don't need to go to the server.
>
> Your point about reloading and losing state of the other portlets is
>
> well taken.
> Even IFrame portlets require state management and rewriting.
> I try to steer clear of applets when working with portlets.
> I do think these issues need to be addressed in future versions of
> the
> spec.
The time to address these issues is now, not later. The basic model
for portable portlets is being established right now. It isn't going
to be possible to 'extend' this model later to accomodate the type of
interaction that I'm proposing. The fundamental model needs to be
established correctly, right now, in order to be able to extend it
later. The reason that you are steering clear of good client-side
technologies such as applets is because the current spec prevents you
from using them in any meaningful way.
>
> You also spoke about when a form is submitted from within an IFrame.
> In Jetspeed today, we are capable of returning only the content of
> the
> particular portlet back to the IFrame.
> The Portlet API is restrictive here, requiring that all portlets
> return
> content per request
> Jetspeed could add an extended mode to support this, but then your
> portlet may not be portable.
With the way in which the portlets operate currently, I'm finding
myself driven towards doing everything inside IFrames with a reload
button on them in order to be able to utilize anything with regard to
client-side technologies. This has been my same experience with jsf.
I find myself only using jsf inside of an iframe so as to be able to
maintain the context of the main page and not have everything
constantly reloading and destroying the client-side technology
contexts.
>
> I'd like to say that in general I agree with what you are saying
> regarding the user experience problems with portlets and constantly
> reloading everything.
> Im still trying to figure out if its really applicable to a Java
> Portlet specification.
> My gut feeling is that it should be, Im just not sure how yet.
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> +01 707 773-4646
>
It is definitely applicable to the portlet spec which is dictating a
rigid user interaction model that is server-only centric. And I think
one that is ultimately going to be rejected by users once they gain
experience with using it.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi David,
> On Tuesday, August 5, 2003, at 06:47 PM, Gerry Reno wrote:
> > From my perspective this
> > is very important since JSR-168 is going to be declared *the*
> standard.
> > The standard should provide enough flexibility to accomodate all
> the
> > common types of paradigms and technologies to which users have come
> to
> > use when utilizing the Web.
> > The portlet spec as currently written is analogous to having a
> number
> > of browsers open on your desktop and each one would represent a
> portlet
> > and if you were to hit the reload button or minimize or maximize or
> > submit a form from any of them, then all of them would reload their
> > pages. Well this works great if you don't mind losing any
> client-side
> > processing that is going on. The problem is that users are
> accustomed
> > to having client-side processing and in fact expect a consistent
> > context when interacting with client-side technologies. As it
> stands
> > now, the portlet spec is dictating that every portlet mode or
> window
> > state change causes an action request to be sent to the server. If
> you
> > understand how the browser and pages and the document object model
> and
> > browser client-side technologies work you immediately realize that
> > constantly reloading pages is not a good thing.
>
--- David Sean Taylor <da...@bluesunrise.com> wrote:
>
> With the portlet api, you are free to handle client-side programming,
>
> inside the scripts and content generated by your portlet.
> However portal-level events such as minimize and maximize, or a
> portlet
> action, must be passed back to the portal so that the
> targeted portlet is notified of the event. Portlets, like servlets,
> are
> server-side objects and that is what the Java specification focuses
> on.
>
> Im thinking about your maximize example. Wouldn't most cases require
> different or more content in maximized mode, requiring a trip back to
>
> the server?
> Same for print friendly mode.
This is what I am talking about when I refer to client-side
technologies being severely restricted. Any client-side technologies
are going to be limited by the fact that they will live only until the
next button press on the portal and then they will be destroyed and
recreated with the next page load. For client-side technologies it's
as a famous catcher once said, "It's deja-vu all over again".
As far as the maximize example, if you remember from some of my other
threads that what is expensive is server round-trips. My preference
would be to see that all the content, both normalized and maximized
markup is sent to the browser in the initial request and then window
state changes only cause that content to be revealed or hidden as
appropriate. The content for the normal display can be sent with the
additional content for maximized view being loaded in the background so
that there is no delay in the presentation of the portal page to the
user. As far as print-friendly, you just go from a CSS attribute of
'media=screen' to 'media=print'. You can just manipulate the DOM to
cause this to happen! You don't need to go to the server.
>
> Your point about reloading and losing state of the other portlets is
>
> well taken.
> Even IFrame portlets require state management and rewriting.
> I try to steer clear of applets when working with portlets.
> I do think these issues need to be addressed in future versions of
> the
> spec.
The time to address these issues is now, not later. The basic model
for portable portlets is being established right now. It isn't going
to be possible to 'extend' this model later to accomodate the type of
interaction that I'm proposing. The fundamental model needs to be
established correctly, right now, in order to be able to extend it
later. The reason that you are steering clear of good client-side
technologies such as applets is because the current spec prevents you
from using them in any meaningful way.
>
> You also spoke about when a form is submitted from within an IFrame.
> In Jetspeed today, we are capable of returning only the content of
> the
> particular portlet back to the IFrame.
> The Portlet API is restrictive here, requiring that all portlets
> return
> content per request
> Jetspeed could add an extended mode to support this, but then your
> portlet may not be portable.
With the way in which the portlets operate currently, I'm finding
myself driven towards doing everything inside IFrames with a reload
button on them in order to be able to utilize anything with regard to
client-side technologies. This has been my same experience with jsf.
I find myself only using jsf inside of an iframe so as to be able to
maintain the context of the main page and not have everything
constantly reloading and destroying the client-side technology
contexts.
>
> I'd like to say that in general I agree with what you are saying
> regarding the user experience problems with portlets and constantly
> reloading everything.
> Im still trying to figure out if its really applicable to a Java
> Portlet specification.
> My gut feeling is that it should be, Im just not sure how yet.
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> +01 707 773-4646
>
It is definitely applicable to the portlet spec which is dictating a
rigid user interaction model that is server-only centric. And I think
one that is ultimately going to be rejected by users once they gain
experience with using it.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi David,
> On Tuesday, August 5, 2003, at 06:47 PM, Gerry Reno wrote:
> > From my perspective this
> > is very important since JSR-168 is going to be declared *the*
> standard.
> > The standard should provide enough flexibility to accomodate all
> the
> > common types of paradigms and technologies to which users have come
> to
> > use when utilizing the Web.
> > The portlet spec as currently written is analogous to having a
> number
> > of browsers open on your desktop and each one would represent a
> portlet
> > and if you were to hit the reload button or minimize or maximize or
> > submit a form from any of them, then all of them would reload their
> > pages. Well this works great if you don't mind losing any
> client-side
> > processing that is going on. The problem is that users are
> accustomed
> > to having client-side processing and in fact expect a consistent
> > context when interacting with client-side technologies. As it
> stands
> > now, the portlet spec is dictating that every portlet mode or
> window
> > state change causes an action request to be sent to the server. If
> you
> > understand how the browser and pages and the document object model
> and
> > browser client-side technologies work you immediately realize that
> > constantly reloading pages is not a good thing.
>
--- David Sean Taylor <da...@bluesunrise.com> wrote:
>
> With the portlet api, you are free to handle client-side programming,
>
> inside the scripts and content generated by your portlet.
> However portal-level events such as minimize and maximize, or a
> portlet
> action, must be passed back to the portal so that the
> targeted portlet is notified of the event. Portlets, like servlets,
> are
> server-side objects and that is what the Java specification focuses
> on.
>
> Im thinking about your maximize example. Wouldn't most cases require
> different or more content in maximized mode, requiring a trip back to
>
> the server?
> Same for print friendly mode.
This is what I am talking about when I refer to client-side
technologies being severely restricted. Any client-side technologies
are going to be limited by the fact that they will live only until the
next button press on the portal and then they will be destroyed and
recreated with the next page load. For client-side technologies it's
as a famous catcher once said, "It's deja-vu all over again".
As far as the maximize example, if you remember from some of my other
threads that what is expensive is server round-trips. My preference
would be to see that all the content, both normalized and maximized
markup is sent to the browser in the initial request and then window
state changes only cause that content to be revealed or hidden as
appropriate. The content for the normal display can be sent with the
additional content for maximized view being loaded in the background so
that there is no delay in the presentation of the portal page to the
user. As far as print-friendly, you just go from a CSS attribute of
'media=screen' to 'media=print'. You can just manipulate the DOM to
cause this to happen! You don't need to go to the server.
>
> Your point about reloading and losing state of the other portlets is
>
> well taken.
> Even IFrame portlets require state management and rewriting.
> I try to steer clear of applets when working with portlets.
> I do think these issues need to be addressed in future versions of
> the
> spec.
The time to address these issues is now, not later. The basic model
for portable portlets is being established right now. It isn't going
to be possible to 'extend' this model later to accomodate the type of
interaction that I'm proposing. The fundamental model needs to be
established correctly, right now, in order to be able to extend it
later. The reason that you are steering clear of good client-side
technologies such as applets is because the current spec prevents you
from using them in any meaningful way.
>
> You also spoke about when a form is submitted from within an IFrame.
> In Jetspeed today, we are capable of returning only the content of
> the
> particular portlet back to the IFrame.
> The Portlet API is restrictive here, requiring that all portlets
> return
> content per request
> Jetspeed could add an extended mode to support this, but then your
> portlet may not be portable.
With the way in which the portlets operate currently, I'm finding
myself driven towards doing everything inside IFrames with a reload
button on them in order to be able to utilize anything with regard to
client-side technologies. This has been my same experience with jsf.
I find myself only using jsf inside of an iframe so as to be able to
maintain the context of the main page and not have everything
constantly reloading and destroying the client-side technology
contexts.
>
> I'd like to say that in general I agree with what you are saying
> regarding the user experience problems with portlets and constantly
> reloading everything.
> Im still trying to figure out if its really applicable to a Java
> Portlet specification.
> My gut feeling is that it should be, Im just not sure how yet.
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> +01 707 773-4646
>
It is definitely applicable to the portlet spec which is dictating a
rigid user interaction model that is server-only centric. And I think
one that is ultimately going to be rejected by users once they gain
experience with using it.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: JSR-168 Article Part 1 in JavaWorld
Posted by Gerry Reno <gr...@yahoo.com>.
Hi David,
> On Tuesday, August 5, 2003, at 06:47 PM, Gerry Reno wrote:
> > From my perspective this
> > is very important since JSR-168 is going to be declared *the*
> standard.
> > The standard should provide enough flexibility to accomodate all
> the
> > common types of paradigms and technologies to which users have come
> to
> > use when utilizing the Web.
> > The portlet spec as currently written is analogous to having a
> number
> > of browsers open on your desktop and each one would represent a
> portlet
> > and if you were to hit the reload button or minimize or maximize or
> > submit a form from any of them, then all of them would reload their
> > pages. Well this works great if you don't mind losing any
> client-side
> > processing that is going on. The problem is that users are
> accustomed
> > to having client-side processing and in fact expect a consistent
> > context when interacting with client-side technologies. As it
> stands
> > now, the portlet spec is dictating that every portlet mode or
> window
> > state change causes an action request to be sent to the server. If
> you
> > understand how the browser and pages and the document object model
> and
> > browser client-side technologies work you immediately realize that
> > constantly reloading pages is not a good thing.
>
--- David Sean Taylor <da...@bluesunrise.com> wrote:
>
> With the portlet api, you are free to handle client-side programming,
>
> inside the scripts and content generated by your portlet.
> However portal-level events such as minimize and maximize, or a
> portlet
> action, must be passed back to the portal so that the
> targeted portlet is notified of the event. Portlets, like servlets,
> are
> server-side objects and that is what the Java specification focuses
> on.
>
> Im thinking about your maximize example. Wouldn't most cases require
> different or more content in maximized mode, requiring a trip back to
>
> the server?
> Same for print friendly mode.
This is what I am talking about when I refer to client-side
technologies being severely restricted. Any client-side technologies
are going to be limited by the fact that they will live only until the
next button press on the portal and then they will be destroyed and
recreated with the next page load. For client-side technologies it's
as a famous catcher once said, "It's deja-vu all over again".
As far as the maximize example, if you remember from some of my other
threads that what is expensive is server round-trips. My preference
would be to see that all the content, both normalized and maximized
markup is sent to the browser in the initial request and then window
state changes only cause that content to be revealed or hidden as
appropriate. The content for the normal display can be sent with the
additional content for maximized view being loaded in the background so
that there is no delay in the presentation of the portal page to the
user. As far as print-friendly, you just go from a CSS attribute of
'media=screen' to 'media=print'. You can just manipulate the DOM to
cause this to happen! You don't need to go to the server.
>
> Your point about reloading and losing state of the other portlets is
>
> well taken.
> Even IFrame portlets require state management and rewriting.
> I try to steer clear of applets when working with portlets.
> I do think these issues need to be addressed in future versions of
> the
> spec.
The time to address these issues is now, not later. The basic model
for portable portlets is being established right now. It isn't going
to be possible to 'extend' this model later to accomodate the type of
interaction that I'm proposing. The fundamental model needs to be
established correctly, right now, in order to be able to extend it
later. The reason that you are steering clear of good client-side
technologies such as applets is because the current spec prevents you
from using them in any meaningful way.
>
> You also spoke about when a form is submitted from within an IFrame.
> In Jetspeed today, we are capable of returning only the content of
> the
> particular portlet back to the IFrame.
> The Portlet API is restrictive here, requiring that all portlets
> return
> content per request
> Jetspeed could add an extended mode to support this, but then your
> portlet may not be portable.
With the way in which the portlets operate currently, I'm finding
myself driven towards doing everything inside IFrames with a reload
button on them in order to be able to utilize anything with regard to
client-side technologies. This has been my same experience with jsf.
I find myself only using jsf inside of an iframe so as to be able to
maintain the context of the main page and not have everything
constantly reloading and destroying the client-side technology
contexts.
>
> I'd like to say that in general I agree with what you are saying
> regarding the user experience problems with portlets and constantly
> reloading everything.
> Im still trying to figure out if its really applicable to a Java
> Portlet specification.
> My gut feeling is that it should be, Im just not sure how yet.
>
> --
> David Sean Taylor
> Bluesunrise Software
> david@bluesunrise.com
> +01 707 773-4646
>
It is definitely applicable to the portlet spec which is dictating a
rigid user interaction model that is server-only centric. And I think
one that is ultimately going to be rejected by users once they gain
experience with using it.
rgds,
Gerry Reno
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Re: JSR-168 Article Part 1 in JavaWorld
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Tuesday, August 5, 2003, at 06:47 PM, Gerry Reno wrote:
> From my perspective this
> is very important since JSR-168 is going to be declared *the* standard.
> The standard should provide enough flexibility to accomodate all the
> common types of paradigms and technologies to which users have come to
> use when utilizing the Web.
> The portlet spec as currently written is analogous to having a number
> of browsers open on your desktop and each one would represent a portlet
> and if you were to hit the reload button or minimize or maximize or
> submit a form from any of them, then all of them would reload their
> pages. Well this works great if you don't mind losing any client-side
> processing that is going on. The problem is that users are accustomed
> to having client-side processing and in fact expect a consistent
> context when interacting with client-side technologies. As it stands
> now, the portlet spec is dictating that every portlet mode or window
> state change causes an action request to be sent to the server. If you
> understand how the browser and pages and the document object model and
> browser client-side technologies work you immediately realize that
> constantly reloading pages is not a good thing.
With the portlet api, you are free to handle client-side programming,
inside the scripts and content generated by your portlet.
However portal-level events such as minimize and maximize, or a portlet
action, must be passed back to the portal so that the
targeted portlet is notified of the event. Portlets, like servlets, are
server-side objects and that is what the Java specification focuses on.
Im thinking about your maximize example. Wouldn't most cases require
different or more content in maximized mode, requiring a trip back to
the server?
Same for print friendly mode.
Your point about reloading and losing state of the other portlets is
well taken.
Even IFrame portlets require state management and rewriting.
I try to steer clear of applets when working with portlets.
I do think these issues need to be addressed in future versions of the
spec.
You also spoke about when a form is submitted from within an IFrame.
In Jetspeed today, we are capable of returning only the content of the
particular portlet back to the IFrame.
The Portlet API is restrictive here, requiring that all portlets return
content per request
Jetspeed could add an extended mode to support this, but then your
portlet may not be portable.
I'd like to say that in general I agree with what you are saying
regarding the user experience problems with portlets and constantly
reloading everything.
Im still trying to figure out if its really applicable to a Java
Portlet specification.
My gut feeling is that it should be, Im just not sure how yet.
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
Re: JSR-168 Article Part 1 in JavaWorld
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Tuesday, August 5, 2003, at 06:47 PM, Gerry Reno wrote:
> From my perspective this
> is very important since JSR-168 is going to be declared *the* standard.
> The standard should provide enough flexibility to accomodate all the
> common types of paradigms and technologies to which users have come to
> use when utilizing the Web.
> The portlet spec as currently written is analogous to having a number
> of browsers open on your desktop and each one would represent a portlet
> and if you were to hit the reload button or minimize or maximize or
> submit a form from any of them, then all of them would reload their
> pages. Well this works great if you don't mind losing any client-side
> processing that is going on. The problem is that users are accustomed
> to having client-side processing and in fact expect a consistent
> context when interacting with client-side technologies. As it stands
> now, the portlet spec is dictating that every portlet mode or window
> state change causes an action request to be sent to the server. If you
> understand how the browser and pages and the document object model and
> browser client-side technologies work you immediately realize that
> constantly reloading pages is not a good thing.
With the portlet api, you are free to handle client-side programming,
inside the scripts and content generated by your portlet.
However portal-level events such as minimize and maximize, or a portlet
action, must be passed back to the portal so that the
targeted portlet is notified of the event. Portlets, like servlets, are
server-side objects and that is what the Java specification focuses on.
Im thinking about your maximize example. Wouldn't most cases require
different or more content in maximized mode, requiring a trip back to
the server?
Same for print friendly mode.
Your point about reloading and losing state of the other portlets is
well taken.
Even IFrame portlets require state management and rewriting.
I try to steer clear of applets when working with portlets.
I do think these issues need to be addressed in future versions of the
spec.
You also spoke about when a form is submitted from within an IFrame.
In Jetspeed today, we are capable of returning only the content of the
particular portlet back to the IFrame.
The Portlet API is restrictive here, requiring that all portlets return
content per request
Jetspeed could add an extended mode to support this, but then your
portlet may not be portable.
I'd like to say that in general I agree with what you are saying
regarding the user experience problems with portlets and constantly
reloading everything.
Im still trying to figure out if its really applicable to a Java
Portlet specification.
My gut feeling is that it should be, Im just not sure how yet.
--
David Sean Taylor
Bluesunrise Software
david@bluesunrise.com
+01 707 773-4646