Hi John,
Here is an working example I put together yesterday.� I'm using very minimal style sheet with a customized control template. The nice thing is the control template does not have one single table in it, only <div> (layer) tags. The control template is used in place of the essential.vm control.
The style.css gives a nice, clean example of how a combination of contextual selectors and the css cascade work very well. IMOHO, it is straight forawrd and easy to understand.
And now for the coup de gras, this is all that I have in the registry for the skin:
<skin-entry name="PureCSSSkin" hidden="false">
<property name="image.paths" value="rk/icons-3D1,rk/dark-blue-outline-tab" hidden="false"/>
</skin-entry>
*===================================*
* Scott T Weaver *
* Jakarta Jetspeed Portal Project *
* [EMAIL PROTECTED] *
*===================================*
> -----Original Message-----
> From: John Christopher [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 01, 2003 12:50 AM
> To: Jetspeed Users List
> Subject: Re: Jespeed Skins Alternatives
>
> 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 *
> > * [EMAIL PROTECTED] *
> > *===================================*
> >
> >
> > > -----Original Message-----
> > > From: Earl Shultz [mailto:[EMAIL PROTECTED]]
> > > Sent: Monday, March 31, 2003 2:38 PM
> > > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > > 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="" /></TD>
> > > <TD>
> > > <TABLE class="Portal-Header-Navbar" cellspacing="0"
> > > cellpadding="0">
> > > <TR>
> > > <TD class="Portal-Header-Navbar-Button">
> > > <!-- CUSTOMIZE HTML BUTTON -->
> > > <A
> > > HREF="">
> > > <IMG BORDER="0" ALT="Customize HTML"
> > > SRC="" />
> > > </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="" />
> > > #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="">
> > > 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: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
