portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mohan K R" <kmoh....@gmail.com>
Subject Re: [M2 build design] Refactoring
Date Tue, 28 Aug 2007 13:39:48 GMT
On 8/27/07, Ate Douma <ate@douma.nu> wrote:
> David Sean Taylor wrote:
> > Scott,
> >
> > Nesting is an absolute requirement.
> +1
> Same goes for a (inline) layout-customizer solution.
> > We ripped out the content-server a while back
> >
> > I don't really care what technology (portlets, templates, JSP, Velocity
> > ..) is used to implement them.
> My preference is that we (at least) allow to use portlets as main entry
> point for layout rendering.
> Being able to render and manage the layout through our core technology
> (portlets) is in my opinion important to maintain, both for support as well
> as
> presentation/communication purposes.
> Allowing additional layout (technology) solutions on the other hand would
> be great of course (as long as it integrates well and is easy to maintain).
> A new "layout and decoration api" as I proposed earlier in another mail
> might be a good starting point to provide a better abstraction for this.
> > I think the main thing we need to consider with layouts is:
> >
> > * making layouts very easy to deploy to the system
> > * making layouts extensible. I don't want to create a new portlet just
> > to go from 3 column 33,33,33 to 25,50,25
> Which isn't needed anyway, you can configure/override that using psml
> fragment properties although those cannot be set through the inline layout
> customizer.
> > * making layouts completely editable from the customizer (like the
> > Desktop supports, but not quite with the portal)
> >
> > I think the main problem with portlet based layouts is that it doesn't
> > extend well.
> > Say I want to create my own layout, I have to get the jar dependencies
> > from the base jetspeed, and build my own layout war
> > I guess that is OK if I am writing my own layout algorithms, but I have
> > found that I usually just need to extend the base layouts
> >
> > Another possible issue I see is that the customization code is directly
> > built into the layouts due to the fact that we wanted "edit in place"
> >
> > We also need to discuss how people will map the old layouts to new
> layouts
> Yes.
> In my view, we should strive to be at least backwards compatible on
> layouts for the 2.2 release.
> We are already going to change a lot in 2.2 which might result in quite a
> few upgrade issues.
> Layouts and decorations are likely the most customized elements of a
> custom portal, so lets try to keep the pain minimal in that area.
> Deprecating our current layout solution (if need be) would be an
> alternative allowing end users time to upgrade until at least release >=
> 2.3.

Can't we preserve the current layout implementation and still provide a
*new* layout solution that is independent and not the default, so existing
layout would still function?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message