burtonator wrote:
>
> ug.... REALLY sorry for the late reply. :( WAY! too busy :(
>
At last... :)
> > 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.
>
No, there're not dependant for their functionality on any output format, a column is
always a column whether it's rendered in HTML, PDF, SVG or Flash, same for grids,
etc...
The issue with WML 1.1 is that it allows very limited presentation options but WML
1.2
is already changing this (introduced <table> last time I checked...).
Writing a WAPPortletController implies that there can't be 2 WAP controller
coexisting,
just like writing an HTMLPortletController would mean there should be only one
controller for HTML. This doesn't make sense to me.
> > 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.
>
Hmm, Kevin, this works with the current CVS image...
Check the supportsType() methods in Portlet and PortletController, the Porfiler and
the CapabilityMap... ;)
> > 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.
>
This is exactly equivalent since the Profiler handles the request -> resource
mapping.
If you prefer we can have <user>_view1.psml and <user>_view2.psml. The porfiler would
just happen to chose view1 for HTML and view2 for WML. Handling all the options in
the
same file doesn't change anything fundamental just implementation issues
(like reloading, parsing, etc...)
> > 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?
>
Don't understand this question. Can you provide a use case so that I can grasp the
issue ?
> > - 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.
>
This is already handled by the PortletSetFactory in CVS. So what you're saying there,
is that there are no differences in functionality between our 2 approaches... ;)
> > 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.
>
Cocoon allows for easy implementation of WML, HTML, etc... rendering but doesn't
address, per se, the WML constraint space (like redefining titles, limiting output
size, etc...)
> > 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 :)
>
Defintely.
> > 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.
>
If I understand this cortrectly, most of our differences come from a different
PorteltController vision. For me a PortletController is defined by its layout
strategy, whatever the output format. We even use a 2 step layout process where
controllers would organise portlets using an internal layout xschema and then a
serializer would output this in the correct format.
> > 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.
>
As long as we can build more complicated issue, I don't see why we can't pre-set
some options to simplify the initial implementation, but I'd hate to see some layout
assumptions in the customizer API...
> > 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.
>
Selecting a default controller is not the most difficult task. Could you explain
more what issue you're considering for WAP ? Also, please don't forget that we'll
want to support otrher formats than HTML and WML, we don't want to restrict the
multi-format solution because of WAP constraints.
> > > 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.
>
I don't see how you can properly implement skinning without inheritance.
Skinning and maybe ACLs are the only properties where inheritance makes
sense.
> > - 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. :)
>
This is definitely not evident from your markup example ! Can you provide us
a *complete* example or schema (with layout, skin, metadata properties and
complex layout output), just for the sake of discussion ? ;P
--
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]
