[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jetspeed-user
Subject:    RE: Jespeed Skins Alternatives
From:       "Weaver, Scott" <Sweaver () rippe ! com>
Date:       2003-03-31 20:38:11
[Download RAW message or body]


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                 *
*===================================*
  


> -----Original Message-----
> From: Earl Shultz [mailto:shultze@midknightoil.com]
> Sent: Monday, March 31, 2003 2:38 PM
> To: jetspeed-dev@jakarta.apache.org; jetspeed-user@jakarta.apache.org
> Subject: Jespeed Skins Alternatives
> 
> I seldom post but this posting touched home on some development I have
> already addressed.  I see a need to ensure that some aspects of style
> control be carried over or included in future revision.  Specifically let
> me list my major concerns:
> 
> First, Jetspeeds default.css includes a very cryptic list of class
> references for style control.  Most are inherent to the control of the
> Jetspeed appearance but most of the existing classes are very obscure and
> it is not immediately apparent what they control. As a result I have been
> pruning existing classes and establishing a clearer hierarchy.  Below is
> an example snippet however I realize this is completely up to the
> developer for control.  I mention it simply so that you might consider
> establishing clearer naming conventions for Jetspeed specific classes.
> One important note however is that I am establishing individual CSS
> documents for each skin.
> 
> ######  default.css SAMPLE
> 
> .Portal { }
> .Portal-Header {
> background-color: #000000;
> }
> .Portal-Header-Logo {
> text-align: left;
> vertical-align: top;
> width: 100%;
> }
> .Portal-Header-Navbar {
> margin: 0px 0px 0px 0px;
> padding: 0px 0px 0px 0px;
> border: 0px;
> text-align: right;
> }
> .Portal-Header-Navbar-Button {
> border: none;
> text-align: right;
> }
> .Portal-Header-Buttonbar {
> padding: 5px 0px 0px 0px;
> border: none;
> text-align: right;
> 	}
> .Portal-Header-Buttonbar-Button {
> border: 0px;
> text-align: right;
> 	}
> .Portal-Header-Authentication {
> background-color: #87ACD6;
> text-align: right;
> }
> .Portal-Header-Authentication-Field {
> padding: 1px 1px 1px 1px;
> color: #000000;
> font-family: Arial, Verdana, Helvetica;
> font-size: 80%;
> font-weight: 600;
> text-align: right;
> }
> .Portal-Menu { }
> .Portal-Portlet-Titlebar
> {
> padding: 0px 0px 3px 3px;
> border: 1px 1px 1px 1px solid #000000;
> 	background-image: url(../../images/blue-gold/scanline_light.gif);
> 	background-repeat: repeat-x;
> color: #000000;
> font-weight: 900;
> }
> .Portal-Portlet-Titlebar-Actions
> {
> background-color: #CCCC99;
> padding: 2px 3px 1px 3px;
> border: 1px 0px 1px 1px solid #000000;
> }
> .Portal-Portlet { }
> .Portal-Footer {
> background-color: #87ACD6;
> color: #000000;
> font-family: Arial, Verdana, Helvetica;
> font-size: 90%;
> font-weight: 400;
> text-align: center;
> }
> 
> Second, There has been a bit of discussion as to addressing only .gif
> images.  Scott's proposal is far more ideal as it allows any web image
> format.  I support that recommendation completely as jpgs are necessary
> for compressed photo quality images.  I believe actions are a small part
> of image control in a skin.  The ability to control the users complete
> experience through a skin is limitless.  One difference to my
> implementation is that not only do I allow the skin to control the
> appearance of certain aspects of the portal but I have built beneath the
> images directory individual directories for each Skin theme.
> (images/gold-black/default.css or images/blue-gold/default.css).  Inside
> each directory I can have a completely unique library of images so that
> even down to the logo, navigation, action images, etc... I can change the
> complete appearance of the site beyond just background colors, borders,
> etc...
> 
> I have eliminated most references to style within the skins.xreg, instead
> we have established effective style through CSS documents and we refer to
> a library of class references to handle the page presentation from the vm
> or jsp pages.
> 
> ######  Skin.xreg
> 
> <skin-entry name="gold-black" hidden="false">
> <property name="skin-name" value="gold-black" hidden="true"/>
> <property name="title-style-class" value="TitleStyleClass"
> hidden="false"/>
> <property name="highlight-title-style-class"
> value="HighlightTitleStyleClass" hidden="false"/>
> <property name="controller-style-class"
> value="ControllerStyleClass" hidden="false"/>
> <property name="portlet-style-class" value="PortletStyleClass"
> hidden="false"/>
> <property name="content-style-class" value="ContentStyleClass"
> hidden="false"/>
> <property name="tab-style-class" value="TabStyleClass"
> hidden="false"/>
> <property name="tab-title-style-class"
> value="TabTitleStyleClass" hidden="false"/>
> <property name="tab-content-style-class"
> value="TabContentStyleClass" hidden="false"/>
> </skin-entry>
> 
> 
> These CSS classes are then referenced by the associated VM documents such
> as top.vm or top.jsp... An example follows:
> 
> ######  top.vm
> 
> <div>
> #if ($!{data.profile.document.portlets.skin.name} != "null")
> #set ($skinName = "$!{data.profile.document.portlets.skin.name}")
> #else
> #set ($skinName =
> $config.getString("services.PortalToolkit.default.skin"))
> #end
> #if ($data.User.hasLoggedIn())
> <TABLE>
> <TR>
> <TD class="Portal-Header-Logo"><IMG
> SRC="images/$skinName/fnmoc_home_banner_metoc.jpg" /></TD>
> <TD>
> <TABLE class="Portal-Header-Navbar" cellspacing="0"
> cellpadding="0">
> <TR>
> <TD class="Portal-Header-Navbar-Button">
> <!-- CUSTOMIZE HTML BUTTON -->
> <A
> HREF="$link.setAction("controls.Customize")?reset=on&level=top">
> <IMG BORDER="0" ALT="Customize HTML"
> SRC="images/$skinName/edit_html.jpg" />
> </A>
> </TD>
> 
> 
> Likewise the css can be unique for each skin as follows in the
> layouts\html\default.vm:
> 
> ######  default.vm
> 
> <HTML>
> <HEAD>
> <base href="$clink.External" />
> #if ($!{data.profile.document.portlets.skin.name} != "null")
> #set ($skinName = "$!{data.profile.document.portlets.skin.name}")
> #else
> #set ($skinName =
> $config.getString("services.PortalToolkit.default.skin"))
> #end
> <link href="$clink.setURI("css/$skinName/default.css").Absolute"
> type="text/css" rel="stylesheet" />
> #set ($titlePrefix = $config.getString("portalpage.title_prefix"))
> <title>#if ($titlePrefix)$titlePrefix
> #end$!{data.profile.document.portlets.getMetaInfo().title}</title>
> </HEAD>
> 
> 
> I am happy to see that Skins are an issue warranting futher development by
> the Jetspeed developers.  The old addage "Better to Look Good than to Feel
> Good" has a great deal of merit to the public.  People will always favor
> aesthics over functionality when it comes to end users. But Fuctionality
> coupled closely with aesthetics is always destined for a successful
> future.
> 
> If you have any other questions regarding anything I have mentioned please
> feel free to contact me.  Thank you for your consideration.
> 
> V/R,
> 
> 
> Kevin Shultz
> 
> "The difference between 'involvement' and 'commitment' is like an eggs-
> and-ham breakfast:
> the chicken was 'involved' - the pig was 'committed'."
> - unknown
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org



[prev in list] [next in list] [prev in thread] [next in thread]