portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aurelien Pernoud" <apern...@sopragroup.com>
Subject RE: Jespeed Skins Alternatives
Date Tue, 01 Apr 2003 08:05:09 GMT

I simply *Love* this, cause then in the registry you only have to point to a
css-entry skin (in your example "my-skin" and "another-skin") and everything
is done !

For backward compatibility this is gonna be a little trickier, as the old
one checked for every css entry in the registry, and then apply it. While
working on adding skins on left and right of portlets (bug 18188), I think I
managed to keep older skins working (I tried all the one that came with
jetspeed in fact, and they still worked).

I could do my work again, going with your idea of default naming stuff for
left portlet, right portlet, top-left, top-right, etc... And then only one
change to the registry is needed (the one above). I think I can still keep
backward compatiblity. Then we could add the changes for the default-image
directory too.

What you think if we integrate both bugs in one ? Cause I saw you told me
you'd like the changes I made to controller on another controller, but if
you look further into them, they're not changing the way controller works, I
just added some changes to "preview" portlets border with the new skin
features when in the controller....

I'll have some time to work on this this week, waiting for your thoughts.
Maybe the all part for the image-directory should be done really properly,
cause checking if a image is present in a directory (with a File() call)
should use a cache (to prevent mutliple unused disk access...).

Aurelien

Weaver, Scott a écrit :

> Hi Kevin,
>
> If you haven't already, check out bug id:
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18208
>
> It's an update from my original post and I think it addressed
> a lot of your concerns regarding images.
>
>
> You have made great points concerning the current complexity
> of the skin registry.  I am all for eliminating the obscurity
> within the css class naming definitions.  Also, I think we
> should make greater use of the contextual selector abilities within
> css:
>
> VERY simple example
>
> .TitleStyleClass { default stuff }
>
> (Different or same style sheet)
>
> .my-skin .TitleStyleClass { whatever}
>
> (Also, different or same style sheet)
>
> .another-skin .TitleStyleClass { something else }
>
> Then each portlet's content could be enclosed by :
> <div class="$skin.Name">
>   <span class="TitleStyleClass">Portlet Title</span>
>
> </div>
>
>
> A very simplistic end page would be
>
> <div class="my-skin">
>   <!-- I override all settings within .TitleStyleClass
>     - with the values from .my-skin .TitleStyleClass
>     - anything not overridden, cascades down from
>     - .TitleStyleClass.
>   -->
>   <span class="TitleStyleClass">Portlet Title</span>
>
> </div>
>
> <div class="another-skin">
>   <!-- I override all settings within .TitleStyleClass
>     - with the values from .another-skin .TitleStyleClass
>     - anything not overridden, cascades down from
>     - .TitleStyleClass.
>   -->
>   <span class="TitleStyleClass">Portlet Title</span>
>
> </div>
>
> Using this approach, you can have multiple skins, each with
> individual csses assigned to a single portlet page.  If we
> used a standardized directory structure, like you suggested,
> for skins, no entries should need to be made to the registry.
>  An event bigger plus is that you can have, for the most
> part, HTML page designers whip up style sheets left and right
> with out having worry about them needing to understand the
> subtleties of the skin registry.  Just educate them about the
> naming convention and directory structure and everybody's happy ;)
>
> Backward compatibility is the only thing we would need to
> address before we could move forward.
>
>
> *===================================*
> * Scott T Weaver                    *
> * Jakarta Jetspeed Portal Project   *
> * weaver@apache.org                 *
> *===================================*


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Mime
View raw message