portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weaver, Scott" <Swea...@rippe.com>
Subject RE: Jespeed Skins Alternatives
Date Mon, 31 Mar 2003 20:38:11 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message