burtonator wrote:
>
> Neeme Praks wrote:
> <snip>
> > > We are still in a place where this isn't totally possible. We need to
> > > build in the 'introspection'/profiler support.
> >
> > how about defining a strategy in code and leave the actual
> > implementation of the strategy to XSLT stylesheet? Then could select
> > appropriate stylesheet depending on media. I believe Rapha�l already
> > mentioned something like this?
>
> I see what you are saying.... it won't really work:
>
> If the user connects with a uplevel client IE/Netscape they can
> configure their uplevel portal. In this situation there is NO reason
> they can't also configure their WAP version too. 'Preview' wouldn't
> really work but they could sure configure a Portal :)
>
We all agree there, all the portal configuration can be done through the
heavy-weight HTML client.
> If we just used XSLT to provide a single PSML file we can't provide
> multiple media Portals. Jetspeed will use Cocoon and for each media it
> will use another stylesheet and this will write a PSML file specific to
> the current device. When they connect with another device they won't
> have a correct Portal layout. In this config we need to support
> multiple devices within one PSML file.
>
I don't know which Cocoon you're refering to, but since you "use" Cocoon I'd
guess it's Cocoon 1.
Anyway, if I take the current situation (ie Turbine+Profiler):
for any given input URL, the profiler can choose the correct PSML resource
file based on user-agent capability. This is indepedant of the stylesheet
selection in Cocoon. The first step choses the content, the second choses
the style.
In the future model (Cocoon 2 - sitemap driven):
the sitemap will select both the PSML content and the stylesheet so there's no
problem here either.
> > But besides checking portlet capabilities, there should also be a way of
> > checking what the user wants. If he wants to see this set of portlets in
> > his phone or not. You cannot just assume that the user will want to see
> > the same portlets as in HTML, use contexts are very different.
>
> Yes... I know. But by default we might want to allow this if it
> supports both media. Then when they see this they can remove it.
>
I think it's best to have the user volontary chose want he wants on its mobile
portal. If you think in term of functionalities:
My portal has a different use depending on my current context: when I'm home, I'd
rather like some entertainment and hobbies-related stuff; when I'm in the office
in "normal" mode I want both business tools access and some Internet news to keep
me informed; when I'm working in "overdrive" mode, I only want urgent and to the
point business information; when I'm out of office, I only want urgent and short
stuff I can view on my phone.
What this means is that I need several portal home pages I configure once and which
I can select as current home page based on my current context. Access capability is
one of the elements of context.
If I try to design something to fulfill this need, I'd say we need par user :
- a list of portal screen definitions (<=> PSML files)
- a list of contexts (either user defined or system defined)
- a customizable binding between contexts and portal screens
When I customize a portal screen, I first chose a context for which I'm
customizing. This may (or may not) restrict the number of available content I can
put in my screen for technical reasons (you're in a mobile context, only WML
resources are selected) or functional reasons (you're in a privileged context, you
get access to some secured content).
When I consult my portal, either the system can automatically guess which context
use (you're using a WML only device and have only one screen binded to WML aware
context) or let chose which one I want (for example a drop down menu in the
navigation listing all configured screens in HTML).
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
