[sorry for the late answer, I've been forced offline for the last
few days...]

De : Weaver, Scott [mailto:[EMAIL PROTECTED]
> Envoy� : mercredi 13 ao�t 2003 17:16
> � : 'Jetspeed Developers List'
> Objet : RE: [J2] New Page API committed to CVS
>
>
> Hi Raphael,
>
> I have been looking at the Page api and so far it looks
> great.  The one concern I have is I see some mention of a
> skin registry.  IMOHO, I don't think we need a skin registry.
>  In fact I did away with it in my custom J1 implementation
> and replaced it with a theme/skin combination very similar to IBM WPS.
>

No problem. I've mostly kept the original skin/decorator model
of J1 for ease of migration, but I agree that it may not be the
most optimal setup.

Also to clear up some ideas, the mention of Registry besically
means for me a way to look up a named object from a list of
available objects. It does not imply that there are any
characteristics other than a name and a path stored within the
registry (as it's the case in the current J1 skin registry
implementation)

> The Theme controls the style sheet that is used and also
> contains its own centralized repository of resources like
> images, flash, html and has a built-in look up mechanism for
> finding these resources.  The theme also contains its own set
> of controls (jsp/velocity templates) for tab layouts, menu
> layouts, along with a "default" template with is the actual
> encompassing page's HTML.  The theme designer can easily add
> fragments to his or her custom theme without having to modify
> the default fragments that come with Jetspeed.
>

Would that be correct then to say that "theme" is a page-wide
property and cannot be applied on an individual fragment ?
That would mean that I remove the skin attribute/property from
fragment and leave it only defined in the page object.

This is fine for me, I don't know if anybody ever used J1
capability to apply skins at an individual portlet/portletset
level.

However, I'm not sure I like the fact that the default HTML
layout is considered part of the "theme" as I would think
site global navigation (controlled by the HTML layout) and
portal cosmetics should be separate concerns.

Additionnal questions, how do you look up the available themes
to allow a user to select a theme in a customization process ?

> Lookups are done in a most-specific to most-general manner
> using a modified version of the template locator from J1. 
> This means that the themes are entirely localized and can be
> easily made to support multiple content-types by simply
> having fragments and resources in the correct folders.
>
> You can also define images and fragments within the base
> "themes" "themes/en" and "themes/en/html" directories which
> will be used by the lookup mechanism if the resource(s) could
> not be found in a specific theme.
>

OK for J1, how do you this ported to J2 given that we don't tie
to Turbine ? a Theme taglib ?
Also note that in J2, a portal page may exist without a
corresponding PSML page (using siomply the portlet taglib) so the
theme feature needs to be exposed to the global web layout.

> <snip>
>
> Skins work essentially the same way except for the fact that
> they "should" use as much information provided by theme as
> possible, like the images for action buttons, etc.
>
> What is really nice is that a theme can define resources for
> the skin(s) to use so that the skin always match the color
> scheme/look and feel of the "enclosing" theme.  For example,
> if you have a title bar background image for your skin called
> skin1bkimage.gif.  A theme with a green color scheme could
> contain a skin1bkimage.gif that is green and another theme
> with a blue color could have a skin1bkimage.gif that is blue.
>  At this point the skin fragments retrieve the image resource
> named "skin1bkimage" from the theme that encloses it so you
> can easily have skins that always match the current theme by
> simply creating the right images and putting them into the
> respective theme.
>

I'm not sure I understand why you would need to skins in addition
to themes. aren't they redundant ?

--
Rapha�l Luta - [EMAIL PROTECTED]
Jakarta Jetspeed - Enterprise Portal in Java
http://jakarta.apache.org/jetspeed/

**********************************************
Vivendi Universal - HTTP://www.vivendiUniversal.com:
The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material of Vivendi Universal which is for the exclusive use of the
individual designated above as the recipient. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact immediately
the sender by returning e-mail and delete the material from any computer.
If you are not the specified recipient, you are hereby notified that all
disclosure, reproduction, distribution or action taken on the basis of this
message is prohibited.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to