El jue, 27-10-2005 a las 15:41 +0100, Kevin escribió:
> Thanks Thorsten more inline
>
> On Wed, 2005-10-26 at 23:57 +0200, Thorsten Scherler wrote:
> > El mié, 26-10-2005 a las 18:20 +0100, Kevin escribió:
> > > Thought I'd have another go at what I called "theme switching" but this
> > > time with the pelt skin/view using corner images and doing things within
> > > Forrest. No Perl script to (a) generate the stylesheets from data
> > > structures and (b) use another Perl script to generate a library of sets
> > > of corner images in different color themes. Each alternate stylesheet
> > > needs it's own set of themed corner images.
> > >
> > > I was sucessful in using Forrest to solve the two parts of the problem
> > > (a) & (b) above. They work independantly but not together. I have tried
> > > but *failed* in this and understanding what I can do with Forrest.
> > >
> > > Here are my ideas so far:
> > >
> > > (a)
> > > themeconfig.xml:
> > > <themeconfig>
> > > <themes>
> > > <theme name="pelt.hot">
> > > <color name="header" value="#294563"/>
> > > <color name="tab-selected" value="#4a6d8c" link="#0F3660"
> > > vlink="#0F3660" hlink="#000066"/>
> > > ...
> > > <!-- like skinconf but change ^^^^ to hot shades of red -->
> > > </theme>
> > > <theme name="pelt.cool">
> > > <color name="header" value="#294563"/>
> > > <color name="tab-selected" value="#00ff00" link="#0F3660"
> > > vlink="#0F3660" hlink="#000066"/>
> > > ...
> > > <!-- like skinconf but change ^^^^ to cool shades of blue -->
> > > </theme>
> > > </themes>
> > > </themeconfig>
> > >
> > > Requests in the form of **skin/view.theme.css ie:
> > > skin/pelt.hot.css
> > > skin/pelt.cool.css
> > >
> >
> > Hmm, maybe I have a certain understanding of themes.
> > A theme is a presentation layer that provides an aggregation of
> > a) theme structure information (*.fv)
> > b) theme style information (*.css & *.png|jpg|gif|...)
> > c) theme functionality (*.js & *.ft)
>
> I agree with your point of view :)
>
> > What you describe is not actually theme but color-theme switching (b.).
> > I added a branding-theme-profiler.ft which is doing this, but you cannot
> > yet switch the colors dynamically (via jscript which is switching b.).
> > You can do the exact thing you describe above by adding it more then
> > once. BTW it is in v2 but also can be used in v1.
>
> What stylesheet does branding-theme-profiler.ft dynamically create,
> I guess profile.css?
No, till now it produces the css inline. I am looking for a way that
contracts are standalone. This way it would be possible to request a
contract via url (see status mail).
> > The important property to define which theme the color belong to is
> > <forrest:property
> > name="branding-theme-profiler-theme">pelt.hot</forrest:property>
> >
> > Your example in a structurer definition:
> > <forrest:contract name="branding-theme-profiler">
> > <forrest:properties contract="branding-theme-profiler">
> > <forrest:property
> > name="branding-theme-profiler-theme">pelt.hot</forrest:property>
> > <forrest:property name="branding-theme-profiler">
> > <color name="header" value="#ff0000"/>
> > <!-- more colors -->
> > </forrest:property>
> > </forrest:properties>
> > </forrest:contract>
> > <forrest:contract name="branding-theme-profiler">
> > <forrest:properties contract="branding-theme-profiler">
> > <forrest:property
> > name="branding-theme-profiler-theme">pelt.cool</forrest:property>
> > <forrest:property name="branding-theme-profiler">
> > <color name="header" value="#00ff00"/>
> > <!-- more colors -->
> > </forrest:property>
> > </forrest:properties>
> > </forrest:contract>
>
> In forrest.properties:
> project.theme=pelt.hot
>
> So I need a pelt.hot.fv file? Every instance of (b) "theme style"
> will require a different view?
no
>
> Perhaps?
>
> project.theme=pelt
> project.theme.style=pelt.hot
> project.theme-extension=.fv
>
> And use project.theme.style
> <forrest:property
> name="branding-theme-profiler-theme-style">pelt.hot</forrest:property>
>
> I'm making a bad guess?
Hmm, I think I do not understand.
The branding-theme-profiler.ft is adding inline e.g.
<style title="Pelt" media="screen" type="text/css" rel="alternate
stylesheet">
#page .breadtrail {
background: #cedfef;
color: #0F3660;
}
//...
</style>
when used like
<forrest:contract name="branding-theme-profiler">
<forrest:properties contract="branding-theme-profiler">
<forrest:property
name="branding-theme-profiler-theme">pelt</forrest:property>
...
It is independent from any value in forrest.properties. It is controlled
by the pelt.fv. If you use the contract more then once in the pelt.fv
then you can add colors themes like you want.
> > A "real" theme switcher would change a/b/c. The browser based solution
> > described in the other mail is *not* doing this either (it is switching
> > only b as well).
> >
> > A "real" color-theme switcher should also provide a possibility to
> > change each color with a WEB-GUI.
>
> Yes I understand what you say.
That is right now a wish list. ;-)
>
> > > will be matched in resouces.xmap [1] and call template
> > > 'view.theme.css.xslt' with a theme parameter ie: theme =
> > > 'pelt.hot' or 'pelt.cool' and the style sheets will
> > > be generated.
> > >
> > > view.theme.css.xslt is like profile.css.xslt but using
> > > themeconfig.xml data and dealing with corner images.
> >
> > Why is this a file for its own and not a contract? Why are you not using
> > the branding-theme-profiler.ft?
>
> view.theme.css.xslt generates all stylesheets based on all available
> instances of (b) "theme style" ie: 'pelt.hot', pelt.cool ... pelt.common
> (default). Now I think you mean these are called views?
>
> My pelt.fv:
> <forrest:css url="pelt.common.css" media="screen" rel="stylesheet"
> type="text/css"/>
> <forrest:css url="pelt.hot.css" media="screen" rel="alternate
> stylesheet" type="text/css" title="pelt.hot"/>
> <forrest:css url="pelt.cool.css" media="screen" rel="alternate
> stylesheet" type="text/css" title="pelt.cool"/>
>
> I can see branding-theme-profiler.ft provides the same information
> as my themeconfig.xml idea. But what does it do with colors, create
> profile.css as before and user would have to:
>
> pelt.hot.fv:
> <forrest:css url="pelt.basic.css" media="screen" title="Pelt"/>
> <forrest:css url="pelt.screen.css" media="screen" title="Pelt"/>
> <forrest:css url="profile.css" media="screen" title="Pelt"/>
No, please see
http://svn.apache.org/viewcvs.cgi/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themer/resources/themes/pelt.fv?rev=328340&view=markup
> > > (b)
> > > As each alternate stylesheet uses a differnet set of colors
> > > matching a url in all style sheets of the form
> > >
> > > #header .round-top-left-small {
> > > background: url(images/rc-t-l-5-1header-2searchbox-3searchbox.png) 0 0
> > > no-repeat}
> > >
> > > won't work as header/searchbox will need to come from a different
> > > color theme in each style sheet
> >
> > It depends with the current implementation you are certainly right, but
> > we need to change that in v2. It has to be possible to generate this via
> > a contract.
> >
> > > So 'view.theme.css.xslt' inserts the hex color values from
> > > themeconfig.xml rather than names ie:
> > >
> > > #header .round-top-left-small {
> > > background: url(images/rc-t-l-5-X294563-X4a6d8c-X4a6d8c.png) 0 0 no-
> > > repeat;}
> > >
> > > Requests in the form skin/images**/*c-*-*-*-X*-X*-X*.png
> > > will be matched in resources.xmap [2] and call 'rcX.svg.xslt'
> > > etc. modified to use hex values.
> >
> > ok. That is maybe the part that I was missing. :) By passing the hex
> > values it would be *a lot* more flexible and could be used in different
> > color-themes. Nice.
> >
> > > Problem
> > > =======
> > >
> > > Run "forrest site" and the link crawler matches the style sheet
> > > requests in the view file
> > > pelt.hot.css
> > > pelt.cool.css
> > > and they are generated correctly. Game Over :(
> > >
> > > Doh! I was expecting the link crawler to then parse the url corner
> > > image requests and generated the png from svg as normal.
> >
> > > I can't understand this. If a static css file is requested it goes
> > > through pipelines and serialized and the corner image links are
> > > crawled and generated? Why can't I do this with a generated css?
> >
> > Hmm, maybe it is because the css is resulting from a xsl-transformation
> > and only visible in the build/ and not in the src/ ¿?
>
> Could you say more on this. How to get xsl-transformation visible under
> src tree?
I do not know the crawler too much, sorry. Maybe someone else can speak
up on that.
> Using the existing system moving corner image from
> pelt.screen.css:
>
> /*background: url("images/tab-left.gif") no-repeat left top;*/
> #nav-main li a {
> float: left;
> ...
> background-image: url(images/rc-t-l-5-1header-2tab-unselected-3tab-
> unselected.png);
> ...
> }
>
> to template profile.css.xslt or what new branding-theme-profiler.ft uses
> would show the problem. No need to use the hex version as it is a static
> color choice view. So profile.css should be generated plus the tab-left
> png.
see
http://svn.apache.org/viewcvs.cgi/forrest/trunk/whiteboard/plugins/org.apache.forrest.plugin.output.themer/resources/themes/pelt/html/branding-theme-profiler.ft?view=markup
we do not use any profile.css.xslt anymore that is within the contract.
Due to this fact the transformation is done and the resulting css get
injected inline. This inline css is available for the bot while crawling
(but I actually have not test this yet). To the hex problematic I am
afraid that this special part of forrest is still married to the
skinconf, which means it the color scheme of the skinconf would be
taken. To overcome it we should use your suggestion of hex colors.
> > > I must be missing something, can someone help here? Thanks.
> >
> > Why don't you use the branding-theme-profiler.ft in combination with the
> > hex-svg-png. That would overcome the problem of build/src dir and crawl
> > the pics.
>
> Not sure how to use it with corner images as above.
>
> I'll do a svn up and copy over the branding-theme-profiler.ft to v1.
>
> Not done an update for a while if there is a hole I fall down it :)
>
> Do views v1 work out the box with forrest.properties workaround:
>
> project.view.internal.plugin=org.apache.forrest.plugin.internal.view
> project.theme.plugin=org.apache.forrest.plugin.internal.view
>
> Thanks
Actually I would like to ask you to try v2 because David just solved the
main problem of it. Now a static export is working again which was the
reason AFAIR for you to stick with v1.
Thx Kevin for your constant work and suggestions.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
