> -----Original Message-----
> From: burtonator [mailto:[EMAIL PROTECTED]]
> Sent: Monday, July 03, 2000 10:19 PM
[snip]
> > Actually, in my PSML vision, there's no
> WAPPortletController. A PortletController
> > is defined by the layout strategy it implements, ie whether
> it organizes portlets
> > in a sequence (RowColumnController), grid (GridController),
> stack (CardController)
> > or just output the raw sequence (FlowController).
>
> Yes. The problem is that the above controllers all assume HTML. the
> WAPPortletController should work with WAP decks.
>
> > Such an organisation is *not* dependent on the output
> format, ie the CardController
> > should be able to work in HTML, PDF, SVG, Flash, WML...
> However, depending on the
> > output media, your controller may have its functionalities
> severely reduced (WML
> > is very restrictive in this sense).
>
> 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?
> > So how do we handle multi-access, I see 2 implementations strategy :
> > - first one, we use internally different PSML files for
> describing the user view
> > for a given format (ex luta.psml for default,
> luta_wml.psml for WAP accesss,
> > luta_PDF.psml for printed report, etc...)
> > The user would then specifically subscribe a portlet in a
> given environment (ie
> > you would have "Add this portlet to WAP", "Add this
> portlet to.." links).
>
> -1. I don't like this. This means that the files have to become part
> of the protocol. I would rather just specify media types in the
> <USER>.PSML.
>
> > Advantages:
> > * This provides the best control over the features
> available in a given
> > format, we can use different controllers, layouts, etc...
> specifically adapted.
> > * This is very easily implemented, just write a Profiler
> >
> > Disadvantages:
> > * there's an aadditional user action required for
> subscribing/unsubscribing a
> > portlet for different output format.
>
> Right. This is why I want to uses <set>s in my updated
> proposal. It is
> almost impossible to write a subscription engine without this. How do
> you organize sets without some really bad AI trying to figure
> this out?
well some more food for thought: let's say that I have several top level
portletsets that represent different services:
* email
* contacts
* calendar
* alerts
* events
* etc...
In html, I render a toolbar for these services at the top:
email | contacts | calendar | alerts | events | etc...
However, for WAP, I also want to include some other services that are
"hidden" in the portal (they don't have a entry in the top toolbar). So,
lets say that for WAP, I want the following menu:
* email
* contacts
* calendar
* alerts
* reminders
* taskpad
* etc...
Note that I added reminders and taskpad, and removed events. So how
would I describe this situation in PSML?
Something like this?:
<portlets user="neeme">
<portlets name="email">
<media>WAP</media>
<media>HTML</media>
....
</portlets>
<portlets name="contacts">
<media>WAP</media>
<media>HTML</media>
....
</portlets>
<portlets name="calendar">
<media>WAP</media>
<media>HTML</media>
....
</portlets>
<portlets name="alerts">
<media>WAP</media>
<media>HTML</media>
....
</portlets>
<portlets name="events">
<media>HTML</media>
....
</portlets>
<portlets name="reminders">
<media>WAP</media>
....
</portlets>
<portlets name="taskpad">
<media>WAP</media>
....
</portlets>
</portlets>
(BTW, how about renaming <portlets> tag into <portletset>? It would be
more consistent with the code.)
> > - second, the same PSML file is used for all views. In this
> case, the factory
> > would filter at instanciation the portlets and
> controllers than can produce
> > content in the requested format. If a controller was
> selected by a user, but
> > unable to rendre content in the required format (ex, WML)
> then the factory
> > would use a default controller adapted to the format (
> for example Flow ).
>
> Right. You can accomplish this better with my scenario. You
> can have a
> set of Portlets that only support HTML and ones that only support WML.
> Then you can have different controllers use these different sets. If
> the sets were done incorrectly (an HTML only portlet in a WML
> set) then the controller would just ignore this.
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.
[snip]
I have also been thinking about WML issues lately, I'm putting together
a XML schema for our own site that would describe the page layout in a
media-scalable way: so we could afterwards generate array of media
formats from this: HTML, WML, Flash, etc.
(This is also the reason why I have been quite quiet lately, I still
have on my TODO list some replies to this list... But probably they will
happen next week...)
At some point I almost gave up... looking at the WML spec, I felt that
maybe I would be better off by simply doing different source files for
different devices. But finally I still managed settle on quite
reasonable schema. And I always have the option of creating a new set of
files when I actually start coding the WML site...
Neeme
--
--------------------------------------------------------------
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]
