burtonator wrote:
>
> I have been working on WAP and user customization in Jetspeed. The
> problem I keep running into is that our PSML implementation is too
> focused around presentation (really not presentation... more like
> controller layout).
>
> If you connect to Jetspeed via WAP, you need to give a PSML
> implementation of this to the client via a WAPPortletController. You
> also want a similar layout when you connect via another media like
> Netscape or IE. The layout/controllers/controls for this needs to be
> implemented different for each media type. If we have nested <portlets>
> this becomes really kludgy to implement :(
>
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).
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).
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).
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.
- 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 ).
Advantages:
* this is a smart system, transparent for the user
Disadvantages:
* somewhat more difficult to implement
* may cause multi-access compatibility problem (for example, due to the small
screen size on WAP devices, it's a good idea to use short titles in WML-mode
whereas the HTML mode can accomodate larger ones)
I tried both, I have no definite opinion on which to choose.
Note: WML has some restrictions on the layout process due to WML stack size
limits, etc... This means what can be represented as a single composite
document HTML, must be represented in several linked stacks in WML.
ex:
<portlets name="p1">
<portlets name="p2">
<entry/>
<entry/>
</protlets>
<portlets name="p3"/>
<portlets name="p4"/>
</portlets>
with RowColumn controllers used for all portlets would represent all the
portlet contents on a single screen.
In WML, we would have:
request portal view -> <top level portlets WML stack listing subportlets>
sub-portlets selection -> <sub-portlets WML stack listing all subentries>
entry selection -> <WML stack displaying entry content>
...
Nested portlets element are an asset in such a situation.
However this is not currently very easy to do in Jetspeed, because we lack
portlets GUID which would allow us to easily link the different steps.
Generating IDs for each PSML elements is IMO a top priority for the engine
evolution as a lot of features will be dependent of these.
> The other issue is the Customizer. When I load the customizer I really
> have no way to give the user a nice presentation designer. You would
> have to reverse Engineer PSML to figure out what page-layout they want.
>
There are definitely issues. What I imagined is something like a tree
traversal algorithm.
Use case:
My current PSML file is the one described above.
User -> Customizer
I want to add a new entry Fetch current PSML file
Get handle on p1 controller
Get parameters needed by controller
<- Ask user: in which column (1,2,3 or new)
Case 1:
I choose column 1 -> Get handle on p2 controller
Get parameters needed by controller
<- Ask user: in which row (1,2,3)
I choose row 3 -> Insert entry in portlets element p2
Case 2:
I want a new Column after 3 -> Insert a new portlets p5 after p4
Affect default controller to p5
Insert entry in p5 with default layout
How to build a GUI with this ? Easy :
- fetch user PSML file
- substitute all entry/@name with entry/@name="CuromizerEntry"
and set all elements with control="CustomizerControl"
via an XSLT transform
- instanciate and getContent().
the CustomizerEntry needs to do nothing only outputs some text (this is needed
to actually build a layout similar to the one the user has on its portal)
the CustomizerControl acts as a clickable zone to link to the properties edition
of the element (if it's a portlets element, edit the controller properties or
change controller).
How do I add an enrty:
click on the portlets element you want to put your entry into and fill the necessary
layout information required by the controller
How do I add a portlets:
same as above.
> I did some creative thinking and I might have a new design that could
> fix this.
>
> <portlets>
>
> <set name="first">
> <entry type="ref" parent="Slashdot"/>
> </set>
>
> <set name="second">
> <entry type="ref" parent="CNN"/>
> </set>
>
> <page-layout media="default">
> <controller name="" set="first"/>
> </page-layout>
>
> <page-layout media="wap">
> <controller name="WAPPortletController" set="first, second"/>
> </page-layout>
>
> </portlets>
>
I don't see the advantage of this markup other multiple PSML files.
Plus,
- this lose all property inheritance between sets.
- this restricts the layout to be handled by a single controller ->
adds compexity to the controller if we want to achieve nice results (good
luck for writing a single controller managing embedded card-stacked portlets
as the "RSS sources" pane in the example turbine.psml)
--
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]
