Rapha�l Luta wrote:
>
> 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 :(
> >
ug.... REALLY sorry for the late reply. :( WAY! too busy :(
> 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.
> 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?
> - 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.
> 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)
Right.... this is why we should use Cocoon and stylesheets.
> 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.
yes... but we can use multiple sets too :)
> 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.
yup
> 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.
yes. I know. I will work on a proposal for this.
> > 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.
Yes. I know. But the tree traversal is basically multiple nested
controllers. What I want to do is still provide this but take the
controllers and then nest those. The sets would be separate. This way
you can provide multiple user interfaces to the same content. This is
also easier to implement in a customizer.
> 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
The problem with this is that you need to take a .psml file and provide
a COMPLETE UI for this. Right now I want to take this .psml file and
make some assumptions (that it uses a 2 column layout) and then build
from there. We can add more complicated layouts later.
> 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).
This technically is possible with some UI tricks. IE selecting the
controller when you add a Portlet. I still don't like it... especially
still for the wAP issue.
> 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.
I didn't like this. I don't think we should have inheritance. If it is
required we can inherit when you nest in the page-layout section.
> - 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)
Yes you can... :)... I didn't provide an example but you can nest
controllers. :)
--
Kevin A Burton (e-mail: [EMAIL PROTECTED], UIN: 73488596, ZKey:
burtonator)
http://relativity.yi.org
Message to SUN: "Please Open Source Java!"
To fight and conquer in all your battles is not supreme excellence;
supreme
excellence consists in breaking the enemy's resistance without fighting.
- Sun Tzu, 300 B.C.
--
--------------------------------------------------------------
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]
