Re: Jespeed Skins Alternatives

[John Christopher <jo...@animalsinneed.net>]

That is a great idea, I hadn't thought about the contextual abilities of css 
for this manner. I have been working with Kevin on our css stuff and I(We) 
both agree that styling the portal should be a simple thing. Although we both 
have gotten into the details of working with jetspeed, our end goal is to 
have a web person be able to follow our class naming schema and create or
integrate a portlet into our portal.

John

On Monday 31 March 2003 12:38, Weaver, Scott wrote:
> 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


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