"Kevin A. Burton" wrote:
>
> Rapha�l Luta wrote:
> >
> > Now that we have PortletSet(s) and panes, I think the current content generation
> > model is not really well-suited handling complex portlet layouts:
> > basically, the controller has to calculate the complete layout from the
> > individual portlets info, which can get quite hairy if we enable of lot of
> > skin and layout customizations in the portlet markup.
> >
> > My proposal is to change the way the classes work together to better
> > mirror standard java.awt layout machanism.
> >
> > Basically, I propose to base the layout process on the PortletSet which would
> > be modified to implement the Portlet interface.
> > The Controller would be associated to a PortletSet just like a LayoutManager
> > is associated to a Container in awt.
> > The PortletCntrol would be used for all Portlet (including PortletSet)
> > except that the default control for a PortletSet is transparent (but may be
> > caching...)
> >
> > Advantages:
> > - more intuitive mechanism since it's closer to the well-known AWT layout
> > system
> > - more regular because if PortletSer are portlets, they can have their
> > PortletConfig too
> > - allows for simpler controller implementation, with XMLController,
> > PaneController, RowController and ColumnController, we can do nearly anything.
>
> So is this just for more control over presentation? Or to fix a bug?
>
More control and providing hooks for advanced functionalities (like
CachingPortlets...)
> +1 if someone wants to do a gridbag layout. The only thing is that I
> think they should still be suggestions so that we can have a
> FlatPortletController that doesn't use a table or anything and then we
> can have portlets on a Palm V.
>
This requires the system to be client aware either by substituing
default controllers by client-specific controllers or by having the
controllers implement a different layout logic based on the client
In either case, I don't see much difficulty in getting the functionality,
possibly by reusing Cocoon soon to be capability map.
> The other thing is the white space at the bottom. This has been
> bothering me. The problem with using the AWT Layout model is that we
> don't know how high a Portlet is going to be until it is rendered. The
> only problem I can see right now is that towards the end of Jetspeed's
> page there is a lot of white space. In Jetspeed 1.0 and earlier this
> was even across the bottom. This was because the size was was the same
> across all Portlets.
>
I fail to understand the issue. There's no good way to handle HTML layout
at the server side, since we don't know the window size of the client browser.
Why should we try to control bottom white space in the layout
without this information since it's so much dependent on these parameters ?
(I run with a 1600x1024 display and I don't see a lot of whitespace for
sure...)
--
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]
