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 Tue, 01 Apr 2003 15:10:38 GMT
> 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....

Sounds good.  I will look deeper into you original bug and source code.

> 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...).

At first, the overhead was a concern, but I talked to someone about and he told me I really
needn't since we are just asking the file system if a file exists as opposed to actually loading
the file.  I did think about caching file paths, but then we have to address the issue of
someone changing skin directory while the container is running.  However, we could use the
current directory as an indicator, and if it changes we know to re-check as the registry must
have changed.


*===================================*
* Scott T Weaver                    *
* Jakarta Jetspeed Portal Project   *
* weaver@apache.org                 *
*===================================*
  


> -----Original Message-----
> From: Aurelien Pernoud [mailto:apernoud@sopragroup.com]
> Sent: Tuesday, April 01, 2003 3:05 AM
> To: 'Jetspeed Developers List'
> Subject: RE: Jespeed Skins Alternatives
> 
> 
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message