Hi Raphael, http://216.68.253.181/integration/portal login example/example
If you go into customize and play with the themes and the skins you will see how they are different. > 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. And > I'm not sure I understand why you would need to skins in addition > to themes. aren't they redundant ? A theme controls the site/page wide look by providing a style sheet, banners, images, and a theme-relevant presentation of individual navigation features, if required. A skin is the "decoration" of the portlet window which includes things like the portlet border and the title bar. > > This is fine for me, I don't know if anybody ever used J1 > > capability to apply skins at an individual portlet/portletset > level. We do and this approach still supports it. > 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. I think it is important that theme be concerned with the "look" of the navigation. For example, if you have a tab navigation that uses images that match only to a single theme, we need to facilitate that. I like the idea of separation of concerns, but sometimes to strict of an adherence to it overcomplicates things. Just my opinion ;) > 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. Then we should look at tying that information in at the page level. *===================================* * Scott T Weaver������������������� * * Jakarta Jetspeed Portal Project�� * * [EMAIL PROTECTED] * *===================================* � > -----Original Message----- > From: Luta, Raphael (VUN) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 19, 2003 6:05 AM > To: 'Jetspeed Developers List' > Subject: RE : [J2] New Page API committed to CVS > > > [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]
