Thorsten Scherler wrote: > David Crossley escribi??: > > Thorsten Scherler wrote: > > > Modify pelt.fv from site-author to reflect our current design and values > > > ------------------------------------------------------------------------ > > > > > > Key: FOR-816 > > > URL: http://issues.apache.org/jira/browse/FOR-816 > > > Project: Forrest > > > Type: Sub-task > > > Components: Dispatcher (aka views) > > > Reporter: Thorsten Scherler > > > > > > > > > While fixing FOR-807 I added a default structurer for the site-author. > > > > > > However we need to add our default values and modify it to reflect > > > http://forrest.apache.org/ > > > > We have issue FOR-811 > > to tidy up the themes.core/themes/pelt.fv > > and associated contracts. > > Yeah, like you said FOR-811 is to tidy up the default pelt theme. > > > Gav was working on that for ForrestFriday. > > However we have not yet got his patch. > > > > How are we going to keep these two copies > > of the pelt structure synchronised? > > Let give me you an example why we need a structurer for site-author. The > skinconf.xml can be found in *all* projects, right? What does > skinconf.xml do? Customizing the skin for the current project (change > logos and project name, ...) Now the skinconf.xml is growing up to the > structurer.
I am not disputing that we need a modified structurer. I am very concerned that we will not be able to keep the two copies synchronised. > Trying to say if we use themes.core/themes/pelt.fv then we have MyGroup > and MyProject, ... but that is not reflecting the reality since we have > custom contract configuration in our site-author. I said 'svn merge'. The site-author version can still have local changes. > This can be overcome if we solve > http://issues.apache.org/jira/browse/FOR-800 > because we then can enhance the structurer (pelt.fv) and corresponding > contracts to automatically take the properties of forrest.properties.xml > (if defined) and use it instead the right now hard coded values (which > would become fallbacks in the contracts). Great, but until then this is dangerous to have two copies of the pelt.fv with separate applied-by-hand changes. > Like (just brainstorming here): > $forrest-trunk/whiteboard/plugins/org.apache.forrest.themes.core/themes/common/html/branding-logo.ft > > <xsl:stylesheet version="1.1" > xmlns:xsl="http://www.w3.org/1999/XSL/Transform";> > <xsl:param name="defaultVariables" select="'test.html'"/> > <xsl:param name="branding-logo-name" select="'MyGroup'"/> > ... > <xsl:variable name="projectBranding-logo-name" > select="$defaultVariables/*/[EMAIL > PROTECTED]'projectBranding-logo-name']/@value"/> > <xsl:variable name="finalBranding-logo-name"> > <xsl:if test="$projectBranding-logo-name=''"> > <xsl:value-of select="$branding-logo-name"/> > </xsl:if> > <xsl:if test="not($projectBranding-logo-name='')"> > <xsl:value-of select="$projectBranding-logo-name"/> > </xsl:if> > ... > > > I reckon that we should continue to work > > on the default core pelt.fv and regularly > > do 'svn merge' to this site-author version. > > So the only changes to the site-author one > > would be specific to our f.a.o site. > > Well, that will end in a build failed for the site-author site since we > do not have e.g. the requested logos (see my comment at 12/Feb/06 01:14 > PM https://issues.apache.org/jira/browse/FOR-807) > > > Otherwise maintenance will be a nightmare. > > > > We also need to be able to test the pelt.fv > > with the seed-sample site. > > In the sample seed we do not use customized logos. I am saying that if the modifications to pelt.fv are not synchronised with the themes.core version then we cannot test the "seed-sample" using pelt.fv We need to test both site-author and seed-sample. > > WDYT? > > I am not sure. > > I agree we should enhance the dispatcher but IMO we should focus on > https://issues.apache.org/jira/browse/FOR-789 > "The dispatcher needs an aggregation of forrest.properties.xml." > which means we need to resolve > https://issues.apache.org/jira/browse/FOR-800 > and then we can close FOR-816 by using FOR-811, but till then I am > afraid we need FOR-816. I know that we need it, but i am worried about maintenance of rapid changes. -David
