[jira] [Commented] (FOR-1220) trouble with config variable and skins, only in WAR mode
[ https://issues.apache.org/jira/browse/FOR-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16365240#comment-16365240 ] Gavin commented on FOR-1220: I'm going to guess this will be a non-issue as next release I imagine we'll bump minimum to 1.7. > trouble with config variable and skins, only in WAR mode > > > Key: FOR-1220 > URL: https://issues.apache.org/jira/browse/FOR-1220 > Project: Forrest > Issue Type: Bug > Components: Launch servlet WAR, Skins (general issues) >Affects Versions: 0.9, 0.10-dev >Reporter: David Crossley >Priority: Major > Fix For: 0.10-dev > > > When using a WAR, and our provided skins, it seems that the $config (i.e. > //skinconf) variable is not instantiated until it has actually been used. In > a stylesheet (e.g. main/webapp/skins/pelt/xslt/html/site-to-xhtml.xsl) the > $config variable is set by the imported "common" related stylesheet. The > first use of the $config variable (i.e. motd) is failing in WAR mode, but all > is fine in 'forrest run' and 'forrest site' modes. The fix seems to be to > actually use the variable (e.g. with count() function) before trying to > process it. > This seems to be only a problem on Java 1.5 and is okay on Java 6. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] Commented: (FOR-1220) trouble with config variable and skins, only in WAR mode
[ https://issues.apache.org/jira/browse/FOR-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990931#comment-12990931 ] David Crossley commented on FOR-1220: - See mail discussion: http://s.apache.org/Yqd Subject: an XSLT issue with seed-sample WAR and Java-1.5 Date: 4 Feb 2011 > trouble with config variable and skins, only in WAR mode > > > Key: FOR-1220 > URL: https://issues.apache.org/jira/browse/FOR-1220 > Project: Forrest > Issue Type: Bug > Components: Launch servlet WAR, Skins (general issues) >Affects Versions: 0.9-dev, 0.10 >Reporter: David Crossley > Fix For: 0.10 > > > When using a WAR, and our provided skins, it seems that the $config (i.e. > //skinconf) variable is not instantiated until it has actually been used. In > a stylesheet (e.g. main/webapp/skins/pelt/xslt/html/site-to-xhtml.xsl) the > $config variable is set by the imported "common" related stylesheet. The > first use of the $config variable (i.e. motd) is failing in WAR mode, but all > is fine in 'forrest run' and 'forrest site' modes. The fix seems to be to > actually use the variable (e.g. with count() function) before trying to > process it. > This seems to be only a problem on Java 1.5 and is okay on Java 6. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FOR-1220) trouble with config variable and skins, only in WAR mode
trouble with config variable and skins, only in WAR mode Key: FOR-1220 URL: https://issues.apache.org/jira/browse/FOR-1220 Project: Forrest Issue Type: Bug Components: Launch servlet WAR, Skins (general issues) Affects Versions: 0.9-dev, 0.10 Reporter: David Crossley Fix For: 0.10 When using a WAR, and our provided skins, it seems that the $config (i.e. //skinconf) variable is not instantiated until it has actually been used. In a stylesheet (e.g. main/webapp/skins/pelt/xslt/html/site-to-xhtml.xsl) the $config variable is set by the imported "common" related stylesheet. The first use of the $config variable (i.e. motd) is failing in WAR mode, but all is fine in 'forrest run' and 'forrest site' modes. The fix seems to be to actually use the variable (e.g. with count() function) before trying to process it. This seems to be only a problem on Java 1.5 and is okay on Java 6. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (FOR-1000) Use locationmap to resolve XSL imports in skins
[ https://issues.apache.org/jira/browse/FOR-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian M Dube closed FOR-1000. - Resolution: Fixed Assignee: (was: Brian M Dube) Please review the locationmap naming scheme and documentation changes. > Use locationmap to resolve XSL imports in skins > --- > > Key: FOR-1000 > URL: https://issues.apache.org/jira/browse/FOR-1000 > Project: Forrest > Issue Type: Improvement > Components: Skins (general issues) >Affects Versions: 0.8, 0.9-dev >Reporter: Brian M Dube >Priority: Minor > Fix For: 0.9-dev > > > To create a custom skin that imports stylesheets from common, for example by > copying pelt and modifying it for a project, it is also necessary to copy the > common skin because the xsl:import calls use relative paths. The imports can > be done with the help of the locationmap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FOR-1000) Use locationmap to resolve XSL imports in skins
[ https://issues.apache.org/jira/browse/FOR-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian M Dube updated FOR-1000: -- Affects Version/s: 0.9-dev > Use locationmap to resolve XSL imports in skins > --- > > Key: FOR-1000 > URL: https://issues.apache.org/jira/browse/FOR-1000 > Project: Forrest > Issue Type: Improvement > Components: Skins (general issues) >Affects Versions: 0.8, 0.9-dev >Reporter: Brian M Dube >Assignee: Brian M Dube >Priority: Minor > Fix For: 0.9-dev > > > To create a custom skin that imports stylesheets from common, for example by > copying pelt and modifying it for a project, it is also necessary to copy the > common skin because the xsl:import calls use relative paths. The imports can > be done with the help of the locationmap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-1000) Use locationmap to resolve XSL imports in skins
[
https://issues.apache.org/jira/browse/FOR-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12785739#action_12785739
]
Brian M Dube commented on FOR-1000:
---
The rewrites are done in r887050. I have not yet updated the documentation.
I used something like this:
$ grep -r --exclude-dir=\.svn xsl:import main/webapp/skins \
| awk -F : '{ print $1 }' \
| xargs sed -i
's_../../../common/xslt/.*/\(.*\)-to-\(.*\)\.xsl_lm://transform.skin.common.\2.\1-to-\2_'
and a slightly different version for the css. Changes to the naming scheme I
used are fine by me.
There are a few files that may need to be handled separately:
$ grep -r --exclude-dir=\.svn xsl:import . | grep -v lm
./common/images/rc.svg.xslt:
./common/images/dc.svg.xslt:
./leather-dev/xslt/xml/contract.xsl:
./leather-dev/xslt/xml/ft-to-xhtml.xsl:
> Use locationmap to resolve XSL imports in skins
> ---
>
> Key: FOR-1000
> URL: https://issues.apache.org/jira/browse/FOR-1000
> Project: Forrest
> Issue Type: Improvement
> Components: Skins (general issues)
>Affects Versions: 0.8
>Reporter: Brian M Dube
>Assignee: Brian M Dube
>Priority: Minor
> Fix For: 0.9-dev
>
>
> To create a custom skin that imports stylesheets from common, for example by
> copying pelt and modifying it for a project, it is also necessary to copy the
> common skin because the xsl:import calls use relative paths. The imports can
> be done with the help of the locationmap.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (FOR-1000) Use locationmap to resolve XSL imports in skins
[ https://issues.apache.org/jira/browse/FOR-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780418#action_12780418 ] Brian M Dube edited comment on FOR-1000 at 12/1/09 3:56 AM: I just made a quick test and it worked. Next: 1) Devise a naming scheme for main/webapp/locationmap-transforms.xml 2) Replace all the relative skin imports with the locationmap pattern from step 1 3) Update documentation regarding custom skins If I don't get to it by tomorrow evening, it'll be a few weeks before I can. was (Author: brian): I just made a quick test and it worked. Next: 1) Devise a naming scheme for main/webapp/locationmap-transforms.xml 2) Replace all the relative skin imports with the locationmap pattern from step 1 If I don't get to it by tomorrow evening, it'll be a few weeks before I can. > Use locationmap to resolve XSL imports in skins > --- > > Key: FOR-1000 > URL: https://issues.apache.org/jira/browse/FOR-1000 > Project: Forrest > Issue Type: Improvement > Components: Skins (general issues) >Affects Versions: 0.8 >Reporter: Brian M Dube >Assignee: Brian M Dube >Priority: Minor > Fix For: 0.9-dev > > > To create a custom skin that imports stylesheets from common, for example by > copying pelt and modifying it for a project, it is also necessary to copy the > common skin because the xsl:import calls use relative paths. The imports can > be done with the help of the locationmap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (FOR-1000) Use locationmap to resolve XSL imports in skins
[ https://issues.apache.org/jira/browse/FOR-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian M Dube reassigned FOR-1000: - Assignee: Brian M Dube > Use locationmap to resolve XSL imports in skins > --- > > Key: FOR-1000 > URL: https://issues.apache.org/jira/browse/FOR-1000 > Project: Forrest > Issue Type: Improvement > Components: Skins (general issues) >Affects Versions: 0.8 >Reporter: Brian M Dube >Assignee: Brian M Dube >Priority: Minor > Fix For: 0.9-dev > > > To create a custom skin that imports stylesheets from common, for example by > copying pelt and modifying it for a project, it is also necessary to copy the > common skin because the xsl:import calls use relative paths. The imports can > be done with the help of the locationmap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-1000) Use locationmap to resolve XSL imports in skins
[ https://issues.apache.org/jira/browse/FOR-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780418#action_12780418 ] Brian M Dube commented on FOR-1000: --- I just made a quick test and it worked. Next: 1) Devise a naming scheme for main/webapp/locationmap-transforms.xml 2) Replace all the relative skin imports with the locationmap pattern from step 1 If I don't get to it by tomorrow evening, it'll be a few weeks before I can. > Use locationmap to resolve XSL imports in skins > --- > > Key: FOR-1000 > URL: https://issues.apache.org/jira/browse/FOR-1000 > Project: Forrest > Issue Type: Improvement > Components: Skins (general issues) >Affects Versions: 0.8 >Reporter: Brian M Dube >Priority: Minor > Fix For: 0.9-dev > > > To create a custom skin that imports stylesheets from common, for example by > copying pelt and modifying it for a project, it is also necessary to copy the > common skin because the xsl:import calls use relative paths. The imports can > be done with the help of the locationmap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-1000) Use locationmap to resolve XSL imports in skins
[ https://issues.apache.org/jira/browse/FOR-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12780334#action_12780334 ] Tim Williams commented on FOR-1000: --- So with the new LocationmapSourceFactory is this not resolved? > Use locationmap to resolve XSL imports in skins > --- > > Key: FOR-1000 > URL: https://issues.apache.org/jira/browse/FOR-1000 > Project: Forrest > Issue Type: Improvement > Components: Skins (general issues) >Affects Versions: 0.8 >Reporter: Brian M Dube >Priority: Minor > Fix For: 0.9-dev > > > To create a custom skin that imports stylesheets from common, for example by > copying pelt and modifying it for a project, it is also necessary to copy the > common skin because the xsl:import calls use relative paths. The imports can > be done with the help of the locationmap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: generate-id and @id (skins)
Gavin wrote: > Just wondering on the implementation of generate-id when @id are already > present. > > Example, in sample.xml we have > > > > which gives us a generated file with > > > > Now, I don't see the generated-id as being referenced anywhere, whereas > 'link-class' is referenced from the toc. > > This seems to be the situation for all , they all get a > generated id also. > > In document-to-html.xsl we have :- > > > > select="count(ancestor-or-self::section)"/> > > ... > > which causes the above behaviour. > > So, just wanted to query, should we use the given id and not use generate-id > unless an id is not given? (as 'id' is not a required attribute of section) > ? That way we have one named anchor or the other, not both. The following template is responsible for processing the section tag in [1]. ... (1) (2) ... It should be safe to remove (1) and replace (2) and other references to @id with: It would be even better to wrap the heading with a div. This way we can easily generate something like: Section Heading ... The id attribute on the wrapper div will do what (1) is supposed to do and is generally a better solution so we could also remove (1) unless there's a good reason not to do so. -Sina [1] $FORREST/main/webapp/skins/common/xslt/html/document-to-html.xsl
[jira] Closed: (FOR-1155) Skins site triggers error on w3c CSS validator
[ https://issues.apache.org/jira/browse/FOR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin closed FOR-1155. -- Resolution: Fixed This works fine now, and passes CSS Level 2.1. > Skins site triggers error on w3c CSS validator > -- > > Key: FOR-1155 > URL: https://issues.apache.org/jira/browse/FOR-1155 > Project: Forrest > Issue Type: Bug > Components: Example Sites, Skins (general issues) >Affects Versions: 0.9-dev >Reporter: Gavin > Fix For: 0.9-dev > > > Skins site can not currently be tested by the W3C CSS Validator. > On connecting and error is returned:- > Target: > http://forrest.zones.apache.org/ft/build/forrest-seed/samples-b/sample.html > java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > Doing the same test on the Dispatcher based site works fine (and passes too!) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FOR-1154) Skins test site page fails HTML validation
[ https://issues.apache.org/jira/browse/FOR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gavin closed FOR-1154. -- Resolution: Fixed Assignee: (was: Gavin) Tested at validator.w3.org, passes fine now. > Skins test site page fails HTML validation > -- > > Key: FOR-1154 > URL: https://issues.apache.org/jira/browse/FOR-1154 > Project: Forrest > Issue Type: Bug > Components: Example Sites, Skins (general issues) >Affects Versions: 0.9-dev >Reporter: Gavin > Fix For: 0.9-dev > > > Currently, the sample page fails validation for HTML in two places. > Error Line 666, Column 9: syntax of attribute value does not conform to > declared value. > > Line 667, Column 9: syntax of attribute value does not conform to declared > value. > src="images/project-logo.p > Full details at :- > http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fforrest.zones.apache.org%2Fft%2Fbuild%2Fforrest-seed%2Fsamples-b%2Fsample.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Work stopped: (FOR-1154) Skins test site page fails HTML validation
[ https://issues.apache.org/jira/browse/FOR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FOR-1154 stopped by Gavin. > Skins test site page fails HTML validation > -- > > Key: FOR-1154 > URL: https://issues.apache.org/jira/browse/FOR-1154 > Project: Forrest > Issue Type: Bug > Components: Example Sites, Skins (general issues) >Affects Versions: 0.9-dev >Reporter: Gavin >Assignee: Gavin > Fix For: 0.9-dev > > > Currently, the sample page fails validation for HTML in two places. > Error Line 666, Column 9: syntax of attribute value does not conform to > declared value. > > Line 667, Column 9: syntax of attribute value does not conform to declared > value. > src="images/project-logo.p > Full details at :- > http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fforrest.zones.apache.org%2Fft%2Fbuild%2Fforrest-seed%2Fsamples-b%2Fsample.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
generate-id and @id (skins)
HI All, Just wondering on the implementation of generate-id when @id are already present. Example, in sample.xml we have which gives us a generated file with Now, I don't see the generated-id as being referenced anywhere, whereas 'link-class' is referenced from the toc. This seems to be the situation for all , they all get a generated id also. In document-to-html.xsl we have :- ... which causes the above behaviour. So, just wanted to query, should we use the given id and not use generate-id unless an id is not given? (as 'id' is not a required attribute of section) ? That way we have one named anchor or the other, not both. Gav...
[jira] Work started: (FOR-1154) Skins test site page fails HTML validation
[ https://issues.apache.org/jira/browse/FOR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FOR-1154 started by Gavin. > Skins test site page fails HTML validation > -- > > Key: FOR-1154 > URL: https://issues.apache.org/jira/browse/FOR-1154 > Project: Forrest > Issue Type: Bug > Components: Example Sites, Skins (general issues) >Affects Versions: 0.9-dev >Reporter: Gavin >Assignee: Gavin > Fix For: 0.9-dev > > > Currently, the sample page fails validation for HTML in two places. > Error Line 666, Column 9: syntax of attribute value does not conform to > declared value. > > Line 667, Column 9: syntax of attribute value does not conform to declared > value. > src="images/project-logo.p > Full details at :- > http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fforrest.zones.apache.org%2Fft%2Fbuild%2Fforrest-seed%2Fsamples-b%2Fsample.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-1154) Skins test site page fails HTML validation
[ https://issues.apache.org/jira/browse/FOR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12707855#action_12707855 ] Gavin commented on FOR-1154: Note that the 'figure' element has as an optional 'id' attribute. This 'id' attribute is generated from document-to-html.xsl. However it generates the same given 'id' attribute for both the generated img element and its surrounding div element and duplicate id's are not allowed. I'm going to change this behaviour to add '-figure' to the end of the figure id if one is given to keep the id's unique. I'll leave the 'id' attribute as optional but also change it to not generate a blank id if none is given, as is the case currently. > Skins test site page fails HTML validation > -- > > Key: FOR-1154 > URL: https://issues.apache.org/jira/browse/FOR-1154 > Project: Forrest > Issue Type: Bug > Components: Example Sites, Skins (general issues) >Affects Versions: 0.9-dev >Reporter: Gavin >Assignee: Gavin > Fix For: 0.9-dev > > > Currently, the sample page fails validation for HTML in two places. > Error Line 666, Column 9: syntax of attribute value does not conform to > declared value. > > Line 667, Column 9: syntax of attribute value does not conform to declared > value. > src="images/project-logo.p > Full details at :- > http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fforrest.zones.apache.org%2Fft%2Fbuild%2Fforrest-seed%2Fsamples-b%2Fsample.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FOR-1155) Skins site triggers error on w3c CSS validator
[ https://issues.apache.org/jira/browse/FOR-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Crossley updated FOR-1155: Description: Skins site can not currently be tested by the W3C CSS Validator. On connecting and error is returned:- Target: http://forrest.zones.apache.org/ft/build/forrest-seed/samples-b/sample.html java.lang.StringIndexOutOfBoundsException: String index out of range: -1 Doing the same test on the Dispatcher based site works fine (and passes too!) was: Skins site can not currently be tested by the W3C Validator. On connecting and error is returned:- Target: http://forrest.zones.apache.org/ft/build/forrest-seed/samples-b/sample.html java.lang.StringIndexOutOfBoundsException: String index out of range: -1 Doing the same test on the Dispatcher based site works fine (and passes too!) Summary: Skins site triggers error on w3c CSS validator (was: Skins site triggers error on w3 vaildator) > Skins site triggers error on w3c CSS validator > -- > > Key: FOR-1155 > URL: https://issues.apache.org/jira/browse/FOR-1155 > Project: Forrest > Issue Type: Bug > Components: Example Sites, Skins (general issues) >Affects Versions: 0.9-dev >Reporter: Gavin > Fix For: 0.9-dev > > > Skins site can not currently be tested by the W3C CSS Validator. > On connecting and error is returned:- > Target: > http://forrest.zones.apache.org/ft/build/forrest-seed/samples-b/sample.html > java.lang.StringIndexOutOfBoundsException: String index out of range: -1 > Doing the same test on the Dispatcher based site works fine (and passes too!) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FOR-1155) Skins site triggers error on w3 vaildator
Skins site triggers error on w3 vaildator - Key: FOR-1155 URL: https://issues.apache.org/jira/browse/FOR-1155 Project: Forrest Issue Type: Bug Components: Example Sites, Skins (general issues) Affects Versions: 0.9-dev Reporter: Gavin Fix For: 0.9-dev Skins site can not currently be tested by the W3C Validator. On connecting and error is returned:- Target: http://forrest.zones.apache.org/ft/build/forrest-seed/samples-b/sample.html java.lang.StringIndexOutOfBoundsException: String index out of range: -1 Doing the same test on the Dispatcher based site works fine (and passes too!) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FOR-1154) Skins test site page fails HTML validation
Skins test site page fails HTML validation -- Key: FOR-1154 URL: https://issues.apache.org/jira/browse/FOR-1154 Project: Forrest Issue Type: Bug Components: Example Sites, Skins (general issues) Affects Versions: 0.9-dev Reporter: Gavin Assignee: Gavin Fix For: 0.9-dev Currently, the sample page fails validation for HTML in two places. Error Line 666, Column 9: syntax of attribute value does not conform to declared value. Line 667, Column 9: syntax of attribute value does not conform to declared value. http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fforrest.zones.apache.org%2Fft%2Fbuild%2Fforrest-seed%2Fsamples-b%2Fsample.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-1136) Error in skins/common/document-to-fo.xsl
[ https://issues.apache.org/jira/browse/FOR-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655149#action_12655149 ] David Crossley commented on FOR-1136: - IIRC, you said in another issue that you changed something to force it to use that file. > Error in skins/common/document-to-fo.xsl > > > Key: FOR-1136 > URL: https://issues.apache.org/jira/browse/FOR-1136 > Project: Forrest > Issue Type: Bug > Components: Skins (general issues) >Affects Versions: 0.9-dev >Reporter: Antoine ROBERT > > Hi > There is a simple error at line 692 of > %FORREST_HOME%\main\webapp\skins\common\xslt\fo\document-to-fo.xsl > name="space-after">6pt" > should be > name="space-after">6pt > ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-1136) Error in skins/common/document-to-fo.xsl
[ https://issues.apache.org/jira/browse/FOR-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655137#action_12655137 ] Antoine ROBERT commented on FOR-1136: - Actually, I had warning about this line in my logs ... So I guess this file is used ... Anyway a comment from guy who know Webapp build and PDF plugin would be great :) > Error in skins/common/document-to-fo.xsl > > > Key: FOR-1136 > URL: https://issues.apache.org/jira/browse/FOR-1136 > Project: Forrest > Issue Type: Bug > Components: Skins (general issues) >Affects Versions: 0.9-dev >Reporter: Antoine ROBERT > > Hi > There is a simple error at line 692 of > %FORREST_HOME%\main\webapp\skins\common\xslt\fo\document-to-fo.xsl > name="space-after">6pt" > should be > name="space-after">6pt > ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-1136) Error in skins/common/document-to-fo.xsl
[ https://issues.apache.org/jira/browse/FOR-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655084#action_12655084 ] David Crossley commented on FOR-1136: - Thanks, i applied your change. However, i am not sure if this file is actually used anymore. The FOP processing recently moved to the PDF output plugin and a copy was made of this file. Many subsequent edits to the plugin's version. Would someone more familiar with the PDF plugin please comment. Can these old stylesheets be removed? > Error in skins/common/document-to-fo.xsl > > > Key: FOR-1136 > URL: https://issues.apache.org/jira/browse/FOR-1136 > Project: Forrest > Issue Type: Bug > Components: Skins (general issues) >Affects Versions: 0.9-dev >Reporter: Antoine ROBERT > > Hi > There is a simple error at line 692 of > %FORREST_HOME%\main\webapp\skins\common\xslt\fo\document-to-fo.xsl > name="space-after">6pt" > should be > name="space-after">6pt > ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FOR-1136) Error in skins/common/document-to-fo.xsl
Error in skins/common/document-to-fo.xsl Key: FOR-1136 URL: https://issues.apache.org/jira/browse/FOR-1136 Project: Forrest Issue Type: Bug Components: Skins (general issues) Affects Versions: 0.9-dev Reporter: Antoine ROBERT Hi There is a simple error at line 692 of %FORREST_HOME%\main\webapp\skins\common\xslt\fo\document-to-fo.xsl 6pt" should be 6pt ? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: i18n message catalogue in dispatcher and skins
Sjur Moshagen wrote:
>
> I'm starting on the next step to make the pdf plugin fully i18n -
> support for i18n text.
>
> To that extent I have a couple of questions:
>
> 1.
>
> In $FORREST_HOME/main/webapp/sitemap.xmap, the following lines are
> found:
>
>src="org.apache.cocoon.transformation.I18nTransformer">
>
>location="{properties:skins-dir}common/translations"/>
>
> true
>
>
> Why is the path to the message catalogue "soft-coded" to the project
> instead of using a LM?
When the locationmap was introduced we tried to
methodically go through all the plugins to
utilise the locationmaps. However, i don't recall
us doing that methodically in core. We need
another scan through everything.
> 2.
>
> Dispatcher has its own set of translations in
>
> $FORREST_HOME/whiteboard/plugins/o.a.f.plugin.internal.dispatcher/
> resources/stylesheets/common/translations/
>
> The files there seem to be exact copies of the ones in
>
> $FORREST_HOME/main/webapp/skins/common/translations/
>
> Any reason for the duplication? Why not use the skins catalogue?
There is a lot of stuff that got duplicated when
the dispatcher work started, e.g. sitemaps.
Not criticising, there seemed to be no other way.
I recall expressing concern over how to keep
stuff synchronised.
So anything that can be done to ease that is good.
> 3. Both dispatcher and skins seem to prefer translations in the
> project tree. Why is that? To ease setup for new languages for new
> users (understandable)? It would still be quite easy to use some LM to
> fall back to a message catalogue in forrest if not found in the
> project, and just tell users to copy the files into the proper project
> folder if needed (ie when needing support for a language not yet
> included in Forrest).
I suppose it is just the way that it evolved.
> Basic point for all these questions:
>
> now we have copies of the same info all over the place, and most is
> not used - I would like to remove all the unnecessary ones, and use LM
> in all cases - and remove the messages from the seed. As part of that
> I would like to update the user documentation for i18n as well, to
> make sure it reflects the current state and how to set up proper i18n
> support, as well as how to add new languages to the translation
> catalogue.
>
> WDYT?
I agree. Good on you for getting into this.
It is certainly needed.
-David
Re: i18n message catalogue in dispatcher and skins
Sjur Moshagen wrote:
Hello all,
I'm starting on the next step to make the pdf plugin fully i18n -
support for i18n text.
To that extent I have a couple of questions:
1.
In $FORREST_HOME/main/webapp/sitemap.xmap, the following lines are found:
src="org.apache.cocoon.transformation.I18nTransformer">
location="{properties:skins-dir}common/translations"/>
true
Why is the path to the message catalogue "soft-coded" to the project
instead of using a LM?
Quite possibly missed when I did the move to LM. I probably did a search
for 'src="' which would have missed this.
I certainly didn't intentionally leave it out.
[I'll have to pass on questions 2 and 3]
Basic point for all these questions:
now we have copies of the same info all over the place, and most is not
used - I would like to remove all the unnecessary ones, and use LM in
all cases - and remove the messages from the seed. As part of that I
would like to update the user documentation for i18n as well, to make
sure it reflects the current state and how to set up proper i18n
support, as well as how to add new languages to the translation catalogue.
Yes please!
Ross
i18n message catalogue in dispatcher and skins
Hello all,
I'm starting on the next step to make the pdf plugin fully i18n -
support for i18n text.
To that extent I have a couple of questions:
1.
In $FORREST_HOME/main/webapp/sitemap.xmap, the following lines are
found:
src="org.apache.cocoon.transformation.I18nTransformer">
location="{properties:skins-dir}common/translations"/>
true
Why is the path to the message catalogue "soft-coded" to the project
instead of using a LM?
2.
Dispatcher has its own set of translations in
$FORREST_HOME/whiteboard/plugins/o.a.f.plugin.internal.dispatcher/
resources/stylesheets/common/translations/
The files there seem to be exact copies of the ones in
$FORREST_HOME/main/webapp/skins/common/translations/
Any reason for the duplication? Why not use the skins catalogue?
3. Both dispatcher and skins seem to prefer translations in the
project tree. Why is that? To ease setup for new languages for new
users (understandable)? It would still be quite easy to use some LM to
fall back to a message catalogue in forrest if not found in the
project, and just tell users to copy the files into the proper project
folder if needed (ie when needing support for a language not yet
included in Forrest).
Basic point for all these questions:
now we have copies of the same info all over the place, and most is
not used - I would like to remove all the unnecessary ones, and use LM
in all cases - and remove the messages from the seed. As part of that
I would like to update the user documentation for i18n as well, to
make sure it reflects the current state and how to set up proper i18n
support, as well as how to add new languages to the translation
catalogue.
WDYT?
Best regards,
Sjur
Re: svn commit: r628187 [1/3] - in /forrest/trunk: lib/core/ main/webapp/ main/webapp/resources/stylesheets/ main/webapp/skins/common/xslt/fo/ plugins/org.apache.forrest.plugin.output.pdf/ plugins/org
I still don't understand why the revert did not work, but at least I know what broke trunk. My fault, I misunderstood the process of merging and did not merge all changes to trunk into my branch before merging branch back into trunk. Will fix that with a new merge this weekend. Best regards, Ferdinand Soethe Ferdinand Soethe wrote: Hmmm. That is strange. I just reverted my merger thinking that I had broken trunk. But it is still broken. Did I do something wrong reverting changes from 628175? Best regards, Ferdinand Soethe
Re: svn commit: r628187 [1/3] - in /forrest/trunk: lib/core/ main/webapp/ main/webapp/resources/stylesheets/ main/webapp/skins/common/xslt/fo/ plugins/org.apache.forrest.plugin.output.pdf/ plugins/org
Hmmm. That is strange. I just reverted my merger thinking that I had broken trunk. But it is still broken. Did I do something wrong reverting changes from 628175? Best regards, Ferdinand Soethe
Re: svn commit: r615253 - /forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl
I agree. Will check the sizing if headings and text in general before I change that. Best regards, Ferdinand Soethe Johannes Schaefer wrote: I would choose a smaller font size for sans headings they look too big now, IMHO. Johannes [EMAIL PROTECTED] schrieb: Author: ferdinand Date: Fri Jan 25 07:58:21 2008 New Revision: 615253 URL: http://svn.apache.org/viewvc?rev=615253&view=rev Log: Minor changes to typesetting of headings (font changed to sans-serif) and padding of box. Modified: forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl Modified: forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl URL: http://svn.apache.org/viewvc/forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl?rev=615253&r1=615252&r2=615253&view=diff == --- forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl (original) +++ forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl Fri Jan 25 07:58:21 2008 @@ -508,7 +508,7 @@ name="heading-type" select="//skinconfig/headings/@type" /> 3pt +name="padding-left">3pt 2pt +name="padding-top">4pt
Re: svn commit: r615253 - /forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl
I would choose a smaller font size for sans headings they look too big now, IMHO. Johannes [EMAIL PROTECTED] schrieb: Author: ferdinand Date: Fri Jan 25 07:58:21 2008 New Revision: 615253 URL: http://svn.apache.org/viewvc?rev=615253&view=rev Log: Minor changes to typesetting of headings (font changed to sans-serif) and padding of box. Modified: forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl Modified: forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl URL: http://svn.apache.org/viewvc/forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl?rev=615253&r1=615252&r2=615253&view=diff == --- forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl (original) +++ forrest/branches/UpdateFOPto094/main/webapp/skins/common/xslt/fo/document-to-fo.xsl Fri Jan 25 07:58:21 2008 @@ -508,7 +508,7 @@ name="heading-type" select="//skinconfig/headings/@type" /> 3pt +name="padding-left">3pt 2pt +name="padding-top">4pt -- User Interface Design GmbH, Ludwigsburg, Germany Phone/Fax +49 7141 37700-46/-99, Mobile +49 170 4914567 E-mail [EMAIL PROTECTED] * www.uidesign.de Offices: Martin-Luther-Straße 57-59, D-71636 Ludwigsburg Truderinger Strasse 330, D-81825 Muenchen Friedrichsring 46, D-68161 Mannheim Legal information according to EHUG: User Interface Design GmbH; Managing Directors: Dr. Claus Goerner, Franz Koller; Head office: Ludwigsburg; Commercial register of the local court of Stuttgart, Germany, HRB 205519
Re: svn commit: r548615 - /forrest/trunk/main/webapp/skins/common/xslt/fo/document-to-fo.xsl
On 19/06/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Author: bdube Date: Mon Jun 18 23:56:40 2007 New Revision: 548615 URL: http://svn.apache.org/viewvc?view=rev&rev=548615 Log: Allow skinconf.xml setting to provide absolute URLs in PDF. Thanks to Patrick Ohly. Issue FOR-1013 Don't forget an entry in status.xml, that is how we notify of improvements and also how we record contributions from none committers. Ross
[jira] Commented: (FOR-1000) Use locationmap to resolve XSL imports in skins
[ https://issues.apache.org/jira/browse/FOR-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500994 ] Brian M Dube commented on FOR-1000: --- Example: Cocoon generates an error for unknown protocol "lm" when I test this. > Use locationmap to resolve XSL imports in skins > --- > > Key: FOR-1000 > URL: https://issues.apache.org/jira/browse/FOR-1000 > Project: Forrest > Issue Type: Improvement > Components: Skins (general issues) >Affects Versions: 0.8 >Reporter: Brian M Dube >Priority: Minor > Fix For: 0.9-dev > > > To create a custom skin that imports stylesheets from common, for example by > copying pelt and modifying it for a project, it is also necessary to copy the > common skin because the xsl:import calls use relative paths. The imports can > be done with the help of the locationmap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-1000) Use locationmap to resolve XSL imports in skins
[ https://issues.apache.org/jira/browse/FOR-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497311 ] Brian Dube commented on FOR-1000: - As David indicates in the surrounding thread, the custom skin documentation will need to reflect this change. > Use locationmap to resolve XSL imports in skins > --- > > Key: FOR-1000 > URL: https://issues.apache.org/jira/browse/FOR-1000 > Project: Forrest > Issue Type: Improvement > Components: Skins (general issues) >Affects Versions: 0.8 >Reporter: Brian Dube >Priority: Minor > Fix For: 0.9-dev > > > To create a custom skin that imports stylesheets from common, for example by > copying pelt and modifying it for a project, it is also necessary to copy the > common skin because the xsl:import calls use relative paths. The imports can > be done with the help of the locationmap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-1000) Use locationmap to resolve XSL imports in skins
[ https://issues.apache.org/jira/browse/FOR-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497270 ] Brian Dube commented on FOR-1000: - Some discussion: http://www.mail-archive.com/[EMAIL PROTECTED]/msg02741.html > Use locationmap to resolve XSL imports in skins > --- > > Key: FOR-1000 > URL: https://issues.apache.org/jira/browse/FOR-1000 > Project: Forrest > Issue Type: Improvement > Components: Skins (general issues) >Affects Versions: 0.8 >Reporter: Brian Dube >Priority: Minor > Fix For: 0.9-dev > > > To create a custom skin that imports stylesheets from common, for example by > copying pelt and modifying it for a project, it is also necessary to copy the > common skin because the xsl:import calls use relative paths. The imports can > be done with the help of the locationmap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FOR-1000) Use locationmap to resolve XSL imports in skins
Use locationmap to resolve XSL imports in skins --- Key: FOR-1000 URL: https://issues.apache.org/jira/browse/FOR-1000 Project: Forrest Issue Type: Improvement Components: Skins (general issues) Affects Versions: 0.8 Reporter: Brian Dube Priority: Minor Fix For: 0.9-dev To create a custom skin that imports stylesheets from common, for example by copying pelt and modifying it for a project, it is also necessary to copy the common skin because the xsl:import calls use relative paths. The imports can be done with the help of the locationmap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Ferdinand Soethe wrote: > Thanks for that pointer David. Cyriaque actually fixed the same bug in a > different way. So no need to apply this to other versions. > > > This seems like a strange place to be handling processing > > instructions and xml comments. The FOR-555 indicate that > > there is a wider issue. > > Did look at FOR-555 and my understanding was that it was meant to remove > namespaces that had wormed their way into the final output. No. Removing namespaces was an earlier issue. See the comments in main/webapp/sitemap.xmap where the transformer stylesheet that you are editing is called from. FOR-555 was about a change in behaviour that suddenly caused xml comments to vanish. -David > Handling PIs and probably comments separatelly is necessary because of > the way they are treated differently in xsl and can't be 'unnamespaced' > the way it was done for elements and attributes. > > > Best regards, > Ferdinand > >
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Thanks for that pointer David. Cyriaque actually fixed the same bug in a different way. So no need to apply this to other versions. > This seems like a strange place to be handling processing > instructions and xml comments. The FOR-555 indicate that > there is a wider issue. Did look at FOR-555 and my understanding was that it was meant to remove namespaces that had wormed their way into the final output. Handling PIs and probably comments separatelly is necessary because of the way they are treated differently in xsl and can't be 'unnamespaced' the way it was done for elements and attributes. Best regards, Ferdinand
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Did you see Cyriaque's change to this file in trunk some time ago. At r463293 he was adding support for PHP which i presume needs to get processing instructions from source through to output. It might address your issue. I gather that the same template in 0.7 was not dealing with processing instructions. http://article.gmane.org/gmane.text.xml.forrest.cvs/7502 This seems like a strange place to be handling processing instructions and xml comments. The FOR-555 indicate that there is a wider issue. -David > Author: ferdinand > Date: Sun May 6 03:24:22 2007 > New Revision: 535593 > > URL: http://svn.apache.org/viewvc?view=rev&rev=535593 > Log: > Attempt to fix disappearance of processing-instructions. > > Modified: > > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl > > Modified: > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl > URL: > http://svn.apache.org/viewvc/forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl?view=diff&rev=535593&r1=535592&r2=535593 > ====== > --- > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl > (original) > +++ > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl > Sun May 6 03:24:22 2007 > @@ -20,9 +20,14 @@ > > > > - select="@*|*|text()|processing-instruction()|comment()"/> > + > > > + > + > + > + > + > > > > >
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Thorsten Scherler wrote: On Sun, 2007-05-06 at 12:28 +0200, Ferdinand Soethe wrote: If nobody has any objections I'd apply this fix to .8 and head as well next week. I did not know that the 0.7 branch is the version where we do such bugfixes. Please, do bugfixes in trunk and not in such old branches such as 0.7. You are the only person that I know that is fixing stuff in an already released and antique version. well, I guess there are people still using 0.7 version and for those people it probably makes sense, right? Or how much does it take to upgrade from 0.7 to trunk version? It is much more important to fix stuff in trunk! is the same patch applicable on trunk? It seems to me that Ferdinand wants to apply the same fix to trunk as well as he wrote above or do I misunderstand something? Just my 2 cents Michael wdot? salu2 -- Michael Wechner Wyona - Open Source Content Management -Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED][EMAIL PROTECTED] +41 44 272 91 61
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
Thorsten Scherler wrote: > I did not know that the 0.7 branch is the version where we do such > bugfixes. > Please, do bugfixes in trunk and not in such old branches such as 0.7. > You are the only person that I know that is fixing stuff in an already > released and antique version. I corrected this bug in the current version of .7 because I have a project that is still using .7 and needed this fix. In addition I offered to apply this fix to .8 and trunk. Not sure what is wrong about that. > It is much more important to fix stuff in trunk! Perhaps that depends on the point of view. My clients using a production version of Forrest would certainly like to see bugs fixed in the current version. Best regards, Ferdinand Soethe
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
On Sun, 2007-05-06 at 12:28 +0200, Ferdinand Soethe wrote: > If nobody has any objections I'd apply this fix to .8 and head as well > next week. I did not know that the 0.7 branch is the version where we do such bugfixes. Please, do bugfixes in trunk and not in such old branches such as 0.7. You are the only person that I know that is fixing stuff in an already released and antique version. It is much more important to fix stuff in trunk! wdot? salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions
Re: svn commit: r535593 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl
If nobody has any objections I'd apply this fix to .8 and head as well next week. Best regards, Ferdinand Soethe [EMAIL PROTECTED] wrote: > Author: ferdinand > Date: Sun May 6 03:24:22 2007 > New Revision: 535593 > > URL: http://svn.apache.org/viewvc?view=rev&rev=535593 > Log: > Attempt to fix disappearance of processing-instructions. > > Modified: > > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl > > Modified: > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl > URL: > http://svn.apache.org/viewvc/forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl?view=diff&rev=535593&r1=535592&r2=535593 > ====== > --- > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl > (original) > +++ > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/strip_namespaces.xsl > Sun May 6 03:24:22 2007 > @@ -20,9 +20,14 @@ > > > > - select="@*|*|text()|processing-instruction()|comment()"/> > + > > > + > + > + > + > + > > > > > > >
[jira] Commented: (FOR-973) handling of some document/header/* elements was disabled from skins
[ https://issues.apache.org/jira/browse/FOR-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485443 ] David Crossley commented on FOR-973: r523984 made a partial fix for this to handle document/header/version elements. > handling of some document/header/* elements was disabled from skins > --- > > Key: FOR-973 > URL: https://issues.apache.org/jira/browse/FOR-973 > Project: Forrest > Issue Type: Bug > Components: Skins (general issues) >Affects Versions: 0.7, 0.8-dev >Reporter: David Crossley >Priority: Minor > > In r36355 the handling of document/header/abstract and > document/header/authors was modified. This also removed the handling of > "document/header/notice" and "document/header/version" elements". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FOR-973) handling of some document/header/* elements was disabled from skins
handling of some document/header/* elements was disabled from skins --- Key: FOR-973 URL: https://issues.apache.org/jira/browse/FOR-973 Project: Forrest Issue Type: Bug Components: Skins (general issues) Affects Versions: 0.7, 0.8-dev Reporter: David Crossley Priority: Minor In r36355 the handling of document/header/abstract and document/header/authors was modified. This also removed the handling of "document/header/notice" and "document/header/version" elements". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-809) Remove build targets around "skins"
[ https://issues.apache.org/jira/browse/FOR-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483084 ] Cyriaque Dupoirieux commented on FOR-809: - Generally, we should put the skin generation in a plugin just like the dispatcher. There are not only some skin oriented targets (targets/skins.xml) to remove from the core, but also : - the skin directory, - the specific location maps in webapps (locationmap-skinconf.xml, locationmap-skins.xml...) - and certainly other files I forget. > Remove build targets around "skins" > --- > > Key: FOR-809 > URL: https://issues.apache.org/jira/browse/FOR-809 > Project: Forrest > Issue Type: Sub-task > Components: Core operations, Dispatcher (aka views), Skins (general > issues) >Reporter: Thorsten Scherler >Priority: Minor > > We need to remove some targets that we now use for skins for the dispatcher. > from forrest site: > check-skin: > ... > fetch-skins-descriptors: > fetch-skin: > unpack-skins: > init-skins: > ... > -validate-skinconf: > 1 file(s) have been successfully validated. > ...validated skinconf > validate-skins-stylesheets: > validate-skins: > validate-skinchoice: > ...validated existence of skin 'pelt' > Created dir: > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/build/site/skin/images > Copying 23 files to > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/build/site/skin/images > Copying 14 files to > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/build/site/skin/images > Copying project skin images to site ... > Warning: > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/src/documentation/skins/common/images > not found. > Warning: > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/src/documentation/skins/pelt/images > not found. > Copying main skin css and js files to site ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FOR-809) Remove build targets around "skins"
[ https://issues.apache.org/jira/browse/FOR-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470255 ] Thorsten Scherler commented on FOR-809: --- The whole "site" target will need a rewrite. I am thinking to just add a NEW "forrest.crawl" target that just would do the calling of the cli and the analysis of the build result. Meaning we would just use and the last All other stuff in this target is skin related and unwanted ballast. wdot? > Remove build targets around "skins" > --- > > Key: FOR-809 > URL: https://issues.apache.org/jira/browse/FOR-809 > Project: Forrest > Issue Type: Sub-task > Components: Core operations, Dispatcher (aka views), Skins (general > issues) >Reporter: Thorsten Scherler >Priority: Minor > > We need to remove some targets that we now use for skins for the dispatcher. > from forrest site: > check-skin: > ... > fetch-skins-descriptors: > fetch-skin: > unpack-skins: > init-skins: > ... > -validate-skinconf: > 1 file(s) have been successfully validated. > ...validated skinconf > validate-skins-stylesheets: > validate-skins: > validate-skinchoice: > ...validated existence of skin 'pelt' > Created dir: > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/build/site/skin/images > Copying 23 files to > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/build/site/skin/images > Copying 14 files to > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/build/site/skin/images > Copying project skin images to site ... > Warning: > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/src/documentation/skins/common/images > not found. > Warning: > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/src/documentation/skins/pelt/images > not found. > Copying main skin css and js files to site ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: svn commit: r471107 - /forrest/trunk/main/webapp/skins/pelt/css/print.css
Damn, I forgot to link FOR-891 in my last commits, do you want me to change
the commit logs and add them in ?
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 4 November 2006 11:37 AM
> To: svn@forrest.apache.org
> Subject: svn commit: r471107 -
> /forrest/trunk/main/webapp/skins/pelt/css/print.css
>
> Author: gmcdonald
> Date: Fri Nov 3 19:37:08 2006
> New Revision: 471107
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=471107
> Log:
> Fix last remaining CSS warning for print.css. screen.css and profile.css
> still to do. changed transparent value to inherit, transparent although
> legit does not pass CSS warnings, inherit in this case does not pose a
> problem.
>
> Modified:
> forrest/trunk/main/webapp/skins/pelt/css/print.css
>
> Modified: forrest/trunk/main/webapp/skins/pelt/css/print.css
> URL:
> http://svn.apache.org/viewvc/forrest/trunk/main/webapp/skins/pelt/css/prin
> t.css?view=diff&rev=471107&r1=471106&r2=471107
> ==
>
> --- forrest/trunk/main/webapp/skins/pelt/css/print.css (original)
> +++ forrest/trunk/main/webapp/skins/pelt/css/print.css Fri Nov 3 19:37:08
> 2006
> @@ -31,12 +31,12 @@
>padding: 0;
>float: none !important;
>color: black;
> - background: transparent;
> + background: inherit;
> }
>
> a:link, a:visited {
>color: #336699;
> - background: transparent;
> + background: inherit;
>text-decoration: underline;
> }
>
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.409 / Virus Database: 268.13.27/517 - Release Date: 11/3/2006
[jira] Closed: (FOR-867) need doc to explain status of skins and dispatcher
[ http://issues.apache.org/jira/browse/FOR-867?page=all ] David Crossley closed FOR-867. -- Resolution: Fixed Summarised the remainder of the discussion. > need doc to explain status of skins and dispatcher > -- > > Key: FOR-867 > URL: http://issues.apache.org/jira/browse/FOR-867 > Project: Forrest > Issue Type: Task > Components: Dispatcher (aka views), Documentation and website, Skins > (general issues) >Affects Versions: 0.8-dev >Reporter: David Crossley >Priority: Blocker > Fix For: 0.8-dev > > > Need doc to explain status of skins and dispatcher. Link to the doc from > warnings of dispatchers docs, from skins.html and from upgrading_08.html > I have already commenced this xdoc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (FOR-867) need doc to explain status of skins and dispatcher
[ http://issues.apache.org/jira/browse/FOR-867?page=all ] David Crossley reassigned FOR-867: -- Assign To: (was: David Crossley) See the discussion in Re: status of skins and dispatcher for 0.8 release http://marc.theaimsgroup.com/?t=11465467111 > need doc to explain status of skins and dispatcher > -- > > Key: FOR-867 > URL: http://issues.apache.org/jira/browse/FOR-867 > Project: Forrest > Type: Task > Components: Skins (general issues), Documentation and website, Dispatcher > (aka views) > Versions: 0.8-dev > Reporter: David Crossley > Priority: Blocker > Fix For: 0.8-dev > > Need doc to explain status of skins and dispatcher. Link to the doc from > warnings of dispatchers docs, from skins.html and from upgrading_08.html > I have already commenced this xdoc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Plugin dependencies (Re: status of skins and dispatcher for 0.8 release)
Ferdinand Soethe wrote: Ross Gardler wrote: Just to be clear. The reason we decided (in the past) not to allow plugins to have dependencies in this way is because it requires the user to have a deep understanding of what plugins work with what other plugins. Even worse, they need to know which versions of plugins will play happily. By requiring the user to know this we will end up with user support questions, which in turn will result in us having to maintain documentation, which in turn will get out of synch with the reality of development, which will result in more user confusion. So, my proposal is to document what plays with what in a feature definition file as described in the previous email. We can generate documentation from this file and it removes the need for the user to worry about version numbers of plugins. This was really helpful because if made me go back and re-read you previous posting and really understand features. +1 for the concept How about naming them in a way that explains better what they are. Something like compound-plugin for example? I really have no problem with any name. Features can be a little misleading and did confuse me for a while in the Eclipse environment. Ross
Re: status of skins and dispatcher for 0.8 release
Ferdinand Soethe wrote: Cyriaque Dupoirieux wrote: I think we need to specify the concept of "feature" for plugins and the notion of plugin dependency of "features". Try to explain : * Plugin A implement the Feature 1 * Plugin B also implement the feature 1 * Plugin C depends on the feature 1 For instance, Plugin C is the dispatcher and Plugins A and B two implementations of the core.theme So what ? Projects can select their implementations : If a project specifies project.required.plugins=C, A, it's OK, If a project specifies project.required.plugins=C, B, it's OK too - but with a different behaviour or rendering, Perhaps it would be a good idea to have this important architectural discussion in a new thread? We did: http://marc.theaimsgroup.com/?l=forrest-dev&m=114675058628417&w=2 Ross
Re: status of skins and dispatcher for 0.8 release
Ferdinand Soethe wrote: Ross Gardler wrote: Nice overlap with Ferdinands proposal for a clear development proposal. Lets use this as a test case. I'll be proposing the Daisy plugin too once I have enough time to document it a little better. We can use both the Daisy and the Dispatcher/themer plugins as test cases. +1 As much as I appreciate lazy consensus, should we not call a vote on this to make people aware of this rather drastic change in our guidelines? Once time has passed for discussion on your Proposal you should call a vote to make that proposal part of our guidelines. Probably best to leave it for at least a week since it is a very important discussion that is rounding up many previous similar discussions. It will take people time to consider the ramifications and find the time to respond. Note that David linked your thread to an issue for tracking these related items. Before voting we will need to ensure your proposal includes everything said in the past. (this should move back to your proposal thread now) Ross Ross
Re: Plugin dependencies (Re: status of skins and dispatcher for 0.8 release)
Ross Gardler wrote: > Just to be clear. The reason we decided (in the past) not to allow > plugins to have dependencies in this way is because it requires the user > to have a deep understanding of what plugins work with what other > plugins. Even worse, they need to know which versions of plugins will > play happily. > By requiring the user to know this we will end up with user support > questions, which in turn will result in us having to maintain > documentation, which in turn will get out of synch with the reality of > development, which will result in more user confusion. > So, my proposal is to document what plays with what in a feature > definition file as described in the previous email. We can generate > documentation from this file and it removes the need for the user to > worry about version numbers of plugins. This was really helpful because if made me go back and re-read you previous posting and really understand features. +1 for the concept How about naming them in a way that explains better what they are. Something like compound-plugin for example? -- Ferdinand Soethe
Re: status of skins and dispatcher for 0.8 release
Ross Gardler wrote: > Nice overlap with Ferdinands proposal for a clear development proposal. > Lets use this as a test case. I'll be proposing the Daisy plugin too > once I have enough time to document it a little better. We can use both > the Daisy and the Dispatcher/themer plugins as test cases. +1 As much as I appreciate lazy consensus, should we not call a vote on this to make people aware of this rather drastic change in our guidelines? -- Ferdinand Soethe
Re: status of skins and dispatcher for 0.8 release
Cyriaque Dupoirieux wrote: > I think we need to specify the concept of "feature" for plugins and the > notion of plugin dependency of "features". > Try to explain : > * Plugin A implement the Feature 1 > * Plugin B also implement the feature 1 > * Plugin C depends on the feature 1 > For instance, Plugin C is the dispatcher and Plugins A and B two > implementations of the core.theme > So what ? > Projects can select their implementations : > If a project specifies project.required.plugins=C, A, it's OK, > If a project specifies project.required.plugins=C, B, it's OK too - > but with a different behaviour or rendering, Perhaps it would be a good idea to have this important architectural discussion in a new thread? -- Ferdinand Soethe
Re: Plugin dependencies (Re: status of skins and dispatcher for 0.8 release)
le 04/05/2006 16:24 Ross Gardler a écrit : Ross Gardler wrote: Cyriaque Dupoirieux wrote: ... Projects can select their implementations : If a project specifies project.required.plugins=C, A, it's OK, If a project specifies project.required.plugins=C, B, it's OK too - but with a different behaviour or rendering, There you go, you just wound up at the Eclipse definition of a Feature. Just to be clear. The reason we decided (in the past) not to allow plugins to have dependencies in this way is because it requires the user to have a deep understanding of what plugins work with what other plugins. Even worse, they need to know which versions of plugins will play happily. By requiring the user to know this we will end up with user support questions, which in turn will result in us having to maintain documentation, which in turn will get out of synch with the reality of development, which will result in more user confusion. So, my proposal is to document what plays with what in a feature definition file as described in the previous email. We can generate documentation from this file and it removes the need for the user to worry about version numbers of plugins. Ok, I fully agree. It's a very nice solution :-) . Cyriaque, PS : I wanted to see how rpm packages manage dependencies, but I have not the time... I think it must be close to your solution... Ross
Re: Plugin dependencies (Re: status of skins and dispatcher for 0.8 release)
Ross Gardler wrote: Cyriaque Dupoirieux wrote: ... Projects can select their implementations : If a project specifies project.required.plugins=C, A, it's OK, If a project specifies project.required.plugins=C, B, it's OK too - but with a different behaviour or rendering, There you go, you just wound up at the Eclipse definition of a Feature. Just to be clear. The reason we decided (in the past) not to allow plugins to have dependencies in this way is because it requires the user to have a deep understanding of what plugins work with what other plugins. Even worse, they need to know which versions of plugins will play happily. By requiring the user to know this we will end up with user support questions, which in turn will result in us having to maintain documentation, which in turn will get out of synch with the reality of development, which will result in more user confusion. So, my proposal is to document what plays with what in a feature definition file as described in the previous email. We can generate documentation from this file and it removes the need for the user to worry about version numbers of plugins. Ross
Plugin dependencies (Re: status of skins and dispatcher for 0.8 release)
Cyriaque Dupoirieux wrote: le 04/05/2006 09:06 Ross Gardler a écrit : David Crossley wrote: Thorsten Scherler wrote: [SNIP] Nice overlap with Ferdinands proposal for a clear development proposal. Lets use this as a test case. I'll be proposing the Daisy plugin too once I have enough time to document it a little better. We can use both the Daisy and the Dispatcher/themer plugins as test cases. One thing that will have to happen before the Dispatcher comes out of core is to resolve the plugin dependency issues. Some time ago we agreed that plugins should not have any dependencies on one another. We also acknowledged that here may come a time in which such a dependency is required. This may be it, but the plugin architecture does not currently support dependencies. We need to create the concept of "features" which are collections of plugins that work together to achieve a specific goal. I think we need to specify the concept of "feature" for plugins and the notion of plugin dependency of "features". Sorry, I'm using Eclipse terminology here. It is a little counter intuitive. A feature is a collection of plugins that work together well. So for example, a feature may be "convert ODT files to PDF". This would require the ODT input plugin and the PDF output plugin. Or a feature may be "provide a theming ability based that allows individual pages to be given a different structure", this would be the Dispatcher internal plugin and the themer plugin. Try to explain : * Plugin A implement the Feature 1 * Plugin B also implement the feature 1 * Plugin C depends on the feature 1 So, given the above definitions of feature a plugin does not implement a feature. A feature is a set of plugins. Instead a plugin adds a unit of functionality to the core of forrest, which can be used to create a specific feature. By doing this a plugin is not directly dependant on another plugin. Instead a feature defines a collection of plugins that will work happily together. This means that we can then have a feature that uses, for example, the dispatcher plugin, but does not use the themer plugin, instead it uses, for example, a hypothetical JXTemplates plugin for themeing. For instance, Plugin C is the dispatcher and Plugins A and B two implementations of the core.theme So what ? Projects can select their implementations : If a project specifies project.required.plugins=C, A, it's OK, If a project specifies project.required.plugins=C, B, it's OK too - but with a different behaviour or rendering, There you go, you just wound up at the Eclipse definition of a Feature. In other words, I agree. We just need to define the terminology and implement the ability to define a feature in forrest.properties. This is really easy to do. It can be something like: feature-def.xml: Enables the rendering of ODT documents as PDF documents 0.1 0.8 0.1 0.2 forrest.properties: requried.features=org.apache.forrest.feature.ODT2PDF Version management just utilises the existing plugin version management. However, we could have incompatabilities between plugin versions. For example, two features may demand incompatible plugin versions. We will need to check this at startup: 1. collect list of all requied plugins 2. look for clashing versions of plugins 3. warn user of potential probelems (if any exist) 4. install latest version of each requirted plugin Thus if, for example, feature A requires plugin P-0.1 (version 0.1) and feature B requires plugin P-0.2 (version 0.2). The user is warned as follows: "Feature A requires plugin P-0.1 whilst feature B requires P-0.2. Forrest has installed the latest version (P-0.2). This may couse unexpected results in Feature A." If this looks OK then we should get this into an issue before we forget it. Ross
Re: status of skins and dispatcher for 0.8 release
le 04/05/2006 09:06 Ross Gardler a écrit : David Crossley wrote: Thorsten Scherler wrote: [SNIP] Nice overlap with Ferdinands proposal for a clear development proposal. Lets use this as a test case. I'll be proposing the Daisy plugin too once I have enough time to document it a little better. We can use both the Daisy and the Dispatcher/themer plugins as test cases. One thing that will have to happen before the Dispatcher comes out of core is to resolve the plugin dependency issues. Some time ago we agreed that plugins should not have any dependencies on one another. We also acknowledged that here may come a time in which such a dependency is required. This may be it, but the plugin architecture does not currently support dependencies. We need to create the concept of "features" which are collections of plugins that work together to achieve a specific goal. I think we need to specify the concept of "feature" for plugins and the notion of plugin dependency of "features". Try to explain : * Plugin A implement the Feature 1 * Plugin B also implement the feature 1 * Plugin C depends on the feature 1 For instance, Plugin C is the dispatcher and Plugins A and B two implementations of the core.theme So what ? Projects can select their implementations : If a project specifies project.required.plugins=C, A, it's OK, If a project specifies project.required.plugins=C, B, it's OK too - but with a different behaviour or rendering, Salutations, Cyriaque, We can return to this after the 0.8 release though. Ross
Re: status of skins and dispatcher for 0.8 release
le 04/05/2006 06:36 David Crossley a écrit : Thorsten Scherler wrote: Ross Gardler escribi??: Thorsten Scherler wrote: Ross Gardler escribi??: David Crossley wrote: We need to have a very clear statement about the status of "Skins" and "Dispatcher" for the upcoming 0.8 release. This statement needs to reflect the vision of developers and where the PMC wants the project to be going. At the same time we need to be careful to not get people over-excited about new technologies that are not quite ready. Remember the mess that we got into at Apache Incubator. Users and developers need to know that Skins are still usable and still the main mechanism. There is then the Dispatcher work-in-progress that has reached an excellent stage. We certainly want to encourage people to investigate it and help to develop it. It is my understanding that we have not yet made a decision about when Dispatcher will be ready, nor whether it will replace skins or whether both will be usable as plugins. I, for one, am happy to further delay that decision, but we need to come up with some words to define the situation. What do others think? It is my understanding that the intention is to eventually have dispatcher in core and that the current skins functionality will move to an internal plugin. No, not sure about the moving to core part. I do not think it is a good idea to add the dispatcher "directly" to the "core". Lately I reread lots of Nicolas Ken threads about html as internal format, then I looked at the plain skin and our WD. I agree the core should provide xhmtl2 and xhtml support from the core, but I think that should be *un-skinned* or *un-dispatched*. Basically *only* the plain skin applied, but even without any navigation information (such as menu, tabs, etc.). I will write a plain theme to explain. ;) The dispatcher will become as well a core plugin (but stay within a plugin) and as well the themes.core. The skins should (not sure if somebody will do it) as well become a plugin. If I understand you correctly I think this is a great idea. Let me explain why... Good, i agree. Yes it's excellent, I currently use the Cocoon Portal to generate the final skinned/themed content for many of my sites. I am also doing a new project now that uses Tiles (within Struts). In these instances I request the body-*.html page from Forrest and include it in the relevant rendering platform. If we do as you suggest, and have core only outputting XHTML2, the user is free to use whatever skinning/theming engine they need. This makes Forrest much more flexible in terms of embedding it in new applications and would help us get away from the view that "Forrest is a web site generation tool". We can still provide a number of seed and samples illustrating different approaches to content skinning. Am I following you correctly? yes. :) Good, i agree. Perfect, That is the basic idea as I understood Nicola after x re-reads. ;) Just output plain something (xhtml or xhtml2) and then let the theming engine take over. ...and yes, we only provide different seeds to the different approaches. ...in the end, who set the dispatcher is "better" then skins. ;) Skins are still way faster and doing certain partial jobs very well, so not need to migrate to the dispatcher right away. In the end the only thing that we need in forrest as interface is *one* common interface (let it be xdocs for now and xhtml2 in the future). Good, i agree. I would like to see skins remain. They can satisfy certain limited uses and i reckon that they can be enhanced. Ok, If somebody starts an skin plugin I reckon I am the first one to help but we need a common output that is way easier as the question dispatcher or skin in any way. ;) We need to remove all skin specific stuff from core and _should_ move it to a plugin. The holes should be filled with some very simple and basic *-to-xhtml(2) transformations. KISS ;) Perfect, Lets do this ASAP after the 0.8 release. Existing skins to core plugins; xhtml2 as the internal format; enhance the input.XDoc plugin; and create the input.html plugin... [SNIP] I think the future forrest architecture starts to be clear in our mind :-) ! Salutations, Cyriaque, Thanks David. salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
Re: status of skins and dispatcher for 0.8 release
David Crossley wrote: Thorsten Scherler wrote: Ross Gardler escribi??: Thorsten Scherler wrote: Ross Gardler escribi??: ... So is it stable enough for us to promise backward compatability? from 0.8 up yes, *my personal opinion* (!!!) Are you sure that the move to xhtml2 in the core ASAP after the release is not going to affect that? To be stable with respect to backward compatability it needs to have a fixed grammar so that users need not change anything to keep up with any internal changes in the code. A move to XHTML2 should not affect this as it is an internal format and would not affect the source format or the structurer grammar. If dispatcher cannot be called stable yet then I do not think we should be encouraging users to adopt it. If it is considered stable then I think a statement to the effect of "cutting edge users and developers are encouraged to *test* the dispatcher which is intended to replace skins in 0.9" If we agree on the above discussion about continuing skins as plugins, then say "alternative to". Agreed. I think we should move the dispatcher out of the whiteboard now. There are only some minor enhancements that keeps it still in there. I reckon when we are switching to dispatcher after the 0.8 release (in 0.9-dev) then the least thing is to add the dispatcher to the official plugins before the 0.8 release. It is just a svn mv and some other things, or? I don't know what is involved. This case is one of the first that we have had. I suppose that we would need a clear proposal and the PMC needs to decide that we agree with the overall direction and timing, etc. Nice overlap with Ferdinands proposal for a clear development proposal. Lets use this as a test case. I'll be proposing the Daisy plugin too once I have enough time to document it a little better. We can use both the Daisy and the Dispatcher/themer plugins as test cases. One thing that will have to happen before the Dispatcher comes out of core is to resolve the plugin dependency issues. Some time ago we agreed that plugins should not have any dependencies on one another. We also acknowledged that here may come a time in which such a dependency is required. This may be it, but the plugin architecture does not currently support dependencies. We need to create the concept of "features" which are collections of plugins that work together to achieve a specific goal. We can return to this after the 0.8 release though. Ross
Re: status of skins and dispatcher for 0.8 release
Thorsten Scherler wrote: > Ross Gardler escribi??: > > Thorsten Scherler wrote: > > > Ross Gardler escribi??: > > >>David Crossley wrote: > > >> > > >>>We need to have a very clear statement about the > > >>>status of "Skins" and "Dispatcher" for the upcoming > > >>>0.8 release. This statement needs to reflect the vision > > >>>of developers and where the PMC wants the project to > > >>>be going. > > >>> > > >>>At the same time we need to be careful to not get > > >>>people over-excited about new technologies that are > > >>>not quite ready. Remember the mess that we got into > > >>>at Apache Incubator. > > >>> > > >>>Users and developers need to know that Skins are > > >>>still usable and still the main mechanism. > > >>> > > >>>There is then the Dispatcher work-in-progress that > > >>>has reached an excellent stage. We certainly want to > > >>>encourage people to investigate it and help to > > >>>develop it. > > >>> > > >>>It is my understanding that we have not yet made a > > >>>decision about when Dispatcher will be ready, nor > > >>>whether it will replace skins or whether both will > > >>>be usable as plugins. I, for one, am happy to further > > >>>delay that decision, but we need to come up with > > >>>some words to define the situation. > > >>> > > >>>What do others think? > > >> > > >>It is my understanding that the intention is to eventually have > > >>dispatcher in core and that the current skins functionality will move to > > >>an internal plugin. > > > > > > No, not sure about the moving to core part. I do not think it is a good > > > idea to add the dispatcher "directly" to the "core". > > > > > > Lately I reread lots of Nicolas Ken threads about html as internal > > > format, then I looked at the plain skin and our WD. I agree the core > > > should provide xhmtl2 and xhtml support from the core, but I think that > > > should be *un-skinned* or *un-dispatched*. Basically *only* the plain > > > skin applied, but even without any navigation information (such as menu, > > > tabs, etc.). I will write a plain theme to explain. ;) > > > > > > The dispatcher will become as well a core plugin (but stay within a > > > plugin) and as well the themes.core. The skins should (not sure if > > > somebody will do it) as well become a plugin. > > > > If I understand you correctly I think this is a great idea. Let me > > explain why... Good, i agree. > > I currently use the Cocoon Portal to generate the final skinned/themed > > content for many of my sites. I am also doing a new project now that > > uses Tiles (within Struts). In these instances I request the body-*.html > > page from Forrest and include it in the relevant rendering platform. > > > > If we do as you suggest, and have core only outputting XHTML2, the user > > is free to use whatever skinning/theming engine they need. This makes > > Forrest much more flexible in terms of embedding it in new applications > > and would help us get away from the view that "Forrest is a web site > > generation tool". > > > > We can still provide a number of seed and samples illustrating different > > approaches to content skinning. > > > > Am I following you correctly? > > yes. :) Good, i agree. > That is the basic idea as I understood Nicola after x re-reads. ;) Just > output plain something (xhtml or xhtml2) and then let the theming engine > take over. > > ...and yes, we only provide different seeds to the different > approaches. > > ...in the end, who set the dispatcher is "better" then skins. ;) Skins > are still way faster and doing certain partial jobs very well, so not > need to migrate to the dispatcher right away. In the end the only thing > that we need in forrest as interface is *one* common interface (let it > be xdocs for now and xhtml2 in the future). Good, i agree. I would like to see skins remain. They can satisfy certain limited uses and i reckon that they can be enhanced. > If somebody starts an skin plugin I reckon I am the first one to help > but we need a common output that is way easier as the question > dispatcher or skin in any way. ;) We need to remove all skin specific > stuff from core and _should_ move
Re: status of skins and dispatcher for 0.8 release
Gav wrote: -Original Message- From: Ross Gardler [mailto:[EMAIL PROTECTED] Sent: Wednesday, 3 May 2006 3:47 AM To: dev@forrest.apache.org Subject: Re: status of skins and dispatcher for 0.8 release Thorsten Scherler wrote: ... Are the broken links in the issue I reported [1] still a problem? That issue was closed but I never saw any commits to resolve it. For that xhtml2_subset file yes still broken. Bit I don't think it an Issue yet since xhtml2 is not yet being worked on. OK, thank you both for your clarifications. My only caution would be, if XHTML2 is not supported then it should not be in the samples when dispatcher comes out of the whiteboard. Perhaps a separate "dev" seed could be used to demonstrate "in progress" features. Ross Ross
RE: status of skins and dispatcher for 0.8 release
> -Original Message- > From: Ross Gardler [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 3 May 2006 3:47 AM > To: dev@forrest.apache.org > Subject: Re: status of skins and dispatcher for 0.8 release > > Thorsten Scherler wrote: > > El mar, 02-05-2006 a las 20:27 +0100, Ross Gardler escribió: > > > >>Ross Gardler wrote: > >> > >>>David Crossley wrote: > >> > >>... > >> > >> > >>>>I made a start today with a new document called: > >>>>"Status of Themes: Skins and Dispatcher" ... > >>>>http://svn.apache.org/viewcvs?rev=398810&view=rev > >>> > >>> > >>>It's down at the moment - will look later. > >> > >>It looks good to me. I think it has the right balance. We may want to > >>create a matrix showing what is supported in the dispatcher and what is > >>not supported. For example, one cannot generate PDF's with a dispatcher > >>enabled site. > > > > > > That is not true. Why do you think so? > > > > It is not possible to generate PDF in the dispatcher out of *xhtml2* > > (like in general). > > I thought this because of [1]. Re-reading alongside your comment above I > see I may have misunderstood. > > I see now that you say that PDF generation does ot work because the > sample is an XHTML2 source file and we need XHTML2-to-FO, OK that is > fine and is not a dispatcher issue but is part of the move to XHTML2. > > Can you confirm that if I use XDoc as a source in a dispatcher enabled > site I will still be able to generate PDF? I can confirm it, PDFs work fine. > > Are the broken links in the issue I reported [1] still a problem? That > issue was closed but I never saw any commits to resolve it. For that xhtml2_subset file yes still broken. Bit I don't think it an Issue yet since xhtml2 is not yet being worked on. Gav... > > Ross > > [1] http://issues.apache.org/jira/browse/FOR-863 > > > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.1.385 / Virus Database: 268.5.1/328 - Release Date: 1/05/2006
Re: status of skins and dispatcher for 0.8 release
El mar, 02-05-2006 a las 20:47 +0100, Ross Gardler escribió: > Thorsten Scherler wrote: > > El mar, 02-05-2006 a las 20:27 +0100, Ross Gardler escribió: > > > >>Ross Gardler wrote: > >> > >>>David Crossley wrote: > >> > >>... > >> > >> > >>>>I made a start today with a new document called: > >>>>"Status of Themes: Skins and Dispatcher" ... > >>>>http://svn.apache.org/viewcvs?rev=398810&view=rev > >>> > >>> > >>>It's down at the moment - will look later. > >> > >>It looks good to me. I think it has the right balance. We may want to > >>create a matrix showing what is supported in the dispatcher and what is > >>not supported. For example, one cannot generate PDF's with a dispatcher > >>enabled site. > > > > > > That is not true. Why do you think so? > > > > It is not possible to generate PDF in the dispatcher out of *xhtml2* > > (like in general). > > I thought this because of [1]. Re-reading alongside your comment above I > see I may have misunderstood. > > I see now that you say that PDF generation does ot work because the > sample is an XHTML2 source file and we need XHTML2-to-FO, OK that is > fine and is not a dispatcher issue but is part of the move to XHTML2. yes, thanks for clarifying. > > Can you confirm that if I use XDoc as a source in a dispatcher enabled > site I will still be able to generate PDF? yes, since the pdf generation is coming from the plugin. > > Are the broken links in the issue I reported [1] still a problem? I do not find broken links in the issue. If you mean the redirect to /index.* that was a quick workaround back in v3. The trunk does not suffer this problem. > That > issue was closed but I never saw any commits to resolve it. Hmm, how about http://marc.theaimsgroup.com/?l=forrest-dev&m=114554635309074&w=2 "Comment by Thorsten Scherler [20/Apr/06 03:07 PM] v3 is not up to date and will be deleted in the process of FOR-798. Further http://localhost:/samples/xhtml2_subset.html is using xhtml2 as input and not xdocs. This means that the pdf will not work anyway since we do not have a xhtml2-to-fo transformation established. Another point is that the xhtml2 integration demonstrated in v3 needs to be done in a different way like I described in a couple of threads on dev (e.g. [RT] structurer location and resource types). This issue will be actual when we base the dispatcher on xhtml2 as input format." ...and the quick workaround for v3 based site is: un-comment the links. ;) In the current dispatcher that is fixed. Maybe we should change the description to "implement xhtml2-to-fo transformation". salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
Re: status of skins and dispatcher for 0.8 release
El mar, 02-05-2006 a las 20:36 +0100, Ross Gardler escribió: > Thorsten Scherler wrote: > > El mar, 02-05-2006 a las 17:50 +0100, Ross Gardler escribió: > > > >>David Crossley wrote: > >> > >>>We need to have a very clear statement about the > >>>status of "Skins" and "Dispatcher" for the upcoming > >>>0.8 release. This statement needs to reflect the vision > >>>of developers and where the PMC wants the project to > >>>be going. > >>> > >>>At the same time we need to be careful to not get > >>>people over-excited about new technologies that are > >>>not quite ready. Remember the mess that we got into > >>>at Apache Incubator. > >>> > >>>Users and developers need to know that Skins are > >>>still usable and still the main mechanism. > >>> > >>>There is then the Dispatcher work-in-progress that > >>>has reached an excellent stage. We certainly want to > >>>encourage people to investigate it and help to > >>>develop it. > >>> > >>>It is my understanding that we have not yet made a > >>>decision about when Dispatcher will be ready, nor > >>>whether it will replace skins or whether both will > >>>be usable as plugins. I, for one, am happy to further > >>>delay that decision, but we need to come up with > >>>some words to define the situation. > >>> > >>>What do others think? > >> > >>It is my understanding that the intention is to eventually have > >>dispatcher in core and that the current skins functionality will move to > >>an internal plugin. > > > > > > No, not sure about the moving to core part. I do not think it is a good > > idea to add the dispatcher "directly" to the "core". > > > > Lately I reread lots of Nicolas Ken threads about html as internal > > format, then I looked at the plain skin and our WD. I agree the core > > should provide xhmtl2 and xhtml support from the core, but I think that > > should be *un-skinned* or *un-dispatched*. Basically *only* the plain > > skin applied, but even without any navigation information (such as menu, > > tabs, etc.). I will write a plain theme to explain. ;) > > > > The dispatcher will become as well a core plugin (but stay within a > > plugin) and as well the themes.core. The skins should (not sure if > > somebody will do it) as well become a plugin. > > If I understand you correctly I think this is a great idea. Let me > explain why... > > I currently use the Cocoon Portal to generate the final skinned/themed > content for many of my sites. I am also doing a new project now that > uses Tiles (within Struts). In these instances I request the body-*.html > page from Forrest and include it in the relevant rendering platform. > > If we do as you suggest, and have core only outputting XHTML2, the user > is free to use whatever skinning/theming engine they need. This makes > Forrest much more flexible in terms of embedding it in new applications > and would help us get away from the view that "Forrest is a web site > generation tool". > > We can still provide a number of seed and samples illustrating different > approaches to content skinning. > > Am I following you correctly? yes. :) That is the basic idea as I understood Nicola after x re-reads. ;) Just output plain something (xhtml or xhtml2) and then let the theming engine take over. ...and yes, we only provide different seeds to the different approaches. ...in the end, who set the dispatcher is "better" then skins. ;) Skins are still way faster and doing certain partial jobs very well, so not need to migrate to the dispatcher right away. In the end the only thing that we need in forrest as interface is *one* common interface (let it be xdocs for now and xhtml2 in the future). If somebody starts an skin plugin I reckon I am the first one to help but we need a common output that is way easier as the question dispatcher or skin in any way. ;) We need to remove all skin specific stuff from core and _should_ move it to a plugin. The holes should be filled with some very simple and basic *-to-xhtml(2) transformations. KISS ;) ...and yes IMO forrest is a framework that should be able to incorporate any output coming from whatsoever. That is why I started work on the dispatcher in the first place, remember? ...and currently working on doco. ;) > >>This means that new sites will be seeded with the > >>dispatcher as default, old sites will need to add the skins plugin to > &g
Re: status of skins and dispatcher for 0.8 release
Thorsten Scherler wrote: El mar, 02-05-2006 a las 20:27 +0100, Ross Gardler escribió: Ross Gardler wrote: David Crossley wrote: ... I made a start today with a new document called: "Status of Themes: Skins and Dispatcher" ... http://svn.apache.org/viewcvs?rev=398810&view=rev It's down at the moment - will look later. It looks good to me. I think it has the right balance. We may want to create a matrix showing what is supported in the dispatcher and what is not supported. For example, one cannot generate PDF's with a dispatcher enabled site. That is not true. Why do you think so? It is not possible to generate PDF in the dispatcher out of *xhtml2* (like in general). I thought this because of [1]. Re-reading alongside your comment above I see I may have misunderstood. I see now that you say that PDF generation does ot work because the sample is an XHTML2 source file and we need XHTML2-to-FO, OK that is fine and is not a dispatcher issue but is part of the move to XHTML2. Can you confirm that if I use XDoc as a source in a dispatcher enabled site I will still be able to generate PDF? Are the broken links in the issue I reported [1] still a problem? That issue was closed but I never saw any commits to resolve it. Ross [1] http://issues.apache.org/jira/browse/FOR-863
Re: status of skins and dispatcher for 0.8 release
Thorsten Scherler wrote: El mar, 02-05-2006 a las 17:50 +0100, Ross Gardler escribió: David Crossley wrote: We need to have a very clear statement about the status of "Skins" and "Dispatcher" for the upcoming 0.8 release. This statement needs to reflect the vision of developers and where the PMC wants the project to be going. At the same time we need to be careful to not get people over-excited about new technologies that are not quite ready. Remember the mess that we got into at Apache Incubator. Users and developers need to know that Skins are still usable and still the main mechanism. There is then the Dispatcher work-in-progress that has reached an excellent stage. We certainly want to encourage people to investigate it and help to develop it. It is my understanding that we have not yet made a decision about when Dispatcher will be ready, nor whether it will replace skins or whether both will be usable as plugins. I, for one, am happy to further delay that decision, but we need to come up with some words to define the situation. What do others think? It is my understanding that the intention is to eventually have dispatcher in core and that the current skins functionality will move to an internal plugin. No, not sure about the moving to core part. I do not think it is a good idea to add the dispatcher "directly" to the "core". Lately I reread lots of Nicolas Ken threads about html as internal format, then I looked at the plain skin and our WD. I agree the core should provide xhmtl2 and xhtml support from the core, but I think that should be *un-skinned* or *un-dispatched*. Basically *only* the plain skin applied, but even without any navigation information (such as menu, tabs, etc.). I will write a plain theme to explain. ;) The dispatcher will become as well a core plugin (but stay within a plugin) and as well the themes.core. The skins should (not sure if somebody will do it) as well become a plugin. If I understand you correctly I think this is a great idea. Let me explain why... I currently use the Cocoon Portal to generate the final skinned/themed content for many of my sites. I am also doing a new project now that uses Tiles (within Struts). In these instances I request the body-*.html page from Forrest and include it in the relevant rendering platform. If we do as you suggest, and have core only outputting XHTML2, the user is free to use whatever skinning/theming engine they need. This makes Forrest much more flexible in terms of embedding it in new applications and would help us get away from the view that "Forrest is a web site generation tool". We can still provide a number of seed and samples illustrating different approaches to content skinning. Am I following you correctly? This means that new sites will be seeded with the dispatcher as default, old sites will need to add the skins plugin to their forrest.properties. yes It is my understanding that this is scheduled to happen in the 0.9 release, by which time the dispatcher should be stable. yes So, my questions are: 1) is my understanding correct? 2) is the dispatcher stable in its implementation? Seems stable from the community feedback, or? ;) Yes it does seem stable, but then I thought that about views 2 as well, then you went and made major architectural changes (for the better of course). That is, can people adopt it without fear of their sites breaking or the dispatcher moving so far from its current implementation that sites will need to be reconfigured? Well I am tended to play the oracle from delphi, but seriously I think we should adopt user feedback as well in the future like now. If that means we need to change some things than we need to do it (like we always did). If users get involved they need backward compatability. Devs expect things to break in alpha code, users do not understand that. So is it stable enough for us to promise backward compatability? ...but I personally consider the current structurer/contract grammar (the only thing that would need reconfiguring) as stable. Like said above when we get lots of feedback to change some things then we need to decide on a case-per-case basis but generally we are always open for enhancements. Of course, sometimes things need to break. If the payoff is sufficient this is worthwhile. Your opinion that it is stable in respect to the grammar (pending feedback) is good enough for me. If dispatcher cannot be called stable yet then I do not think we should be encouraging users to adopt it. If it is considered stable then I think a statement to the effect of "cutting edge users and developers are encouraged to *test* the dispatcher which is intended to replace skins in 0.9" I think we should move the dispatcher out of the whiteboard now. There are only some minor enhancements that keeps it still in there. I reckon when we a
Re: status of skins and dispatcher for 0.8 release
El mar, 02-05-2006 a las 20:27 +0100, Ross Gardler escribió: > Ross Gardler wrote: > > David Crossley wrote: > > ... > > >> I made a start today with a new document called: > >> "Status of Themes: Skins and Dispatcher" ... > >> http://svn.apache.org/viewcvs?rev=398810&view=rev > > > > > > It's down at the moment - will look later. > > It looks good to me. I think it has the right balance. We may want to > create a matrix showing what is supported in the dispatcher and what is > not supported. For example, one cannot generate PDF's with a dispatcher > enabled site. That is not true. Why do you think so? It is not possible to generate PDF in the dispatcher out of *xhtml2* (like in general). > I'm not sure of the status of other plugins when used in > conunction with dispatcher, would a matrix help in showing how > "complete" the dispatche is? > > Ross -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
Re: status of skins and dispatcher for 0.8 release
Ross Gardler wrote: David Crossley wrote: ... I made a start today with a new document called: "Status of Themes: Skins and Dispatcher" ... http://svn.apache.org/viewcvs?rev=398810&view=rev It's down at the moment - will look later. It looks good to me. I think it has the right balance. We may want to create a matrix showing what is supported in the dispatcher and what is not supported. For example, one cannot generate PDF's with a dispatcher enabled site. I'm not sure of the status of other plugins when used in conunction with dispatcher, would a matrix help in showing how "complete" the dispatche is? Ross
Re: status of skins and dispatcher for 0.8 release
El mar, 02-05-2006 a las 17:50 +0100, Ross Gardler escribió: > David Crossley wrote: > > We need to have a very clear statement about the > > status of "Skins" and "Dispatcher" for the upcoming > > 0.8 release. This statement needs to reflect the vision > > of developers and where the PMC wants the project to > > be going. > > > > At the same time we need to be careful to not get > > people over-excited about new technologies that are > > not quite ready. Remember the mess that we got into > > at Apache Incubator. > > > > Users and developers need to know that Skins are > > still usable and still the main mechanism. > > > > There is then the Dispatcher work-in-progress that > > has reached an excellent stage. We certainly want to > > encourage people to investigate it and help to > > develop it. > > > > It is my understanding that we have not yet made a > > decision about when Dispatcher will be ready, nor > > whether it will replace skins or whether both will > > be usable as plugins. I, for one, am happy to further > > delay that decision, but we need to come up with > > some words to define the situation. > > > > What do others think? > > It is my understanding that the intention is to eventually have > dispatcher in core and that the current skins functionality will move to > an internal plugin. No, not sure about the moving to core part. I do not think it is a good idea to add the dispatcher "directly" to the "core". Lately I reread lots of Nicolas Ken threads about html as internal format, then I looked at the plain skin and our WD. I agree the core should provide xhmtl2 and xhtml support from the core, but I think that should be *un-skinned* or *un-dispatched*. Basically *only* the plain skin applied, but even without any navigation information (such as menu, tabs, etc.). I will write a plain theme to explain. ;) The dispatcher will become as well a core plugin (but stay within a plugin) and as well the themes.core. The skins should (not sure if somebody will do it) as well become a plugin. > This means that new sites will be seeded with the > dispatcher as default, old sites will need to add the skins plugin to > their forrest.properties. yes > > It is my understanding that this is scheduled to happen in the 0.9 > release, by which time the dispatcher should be stable. yes > > So, my questions are: > > 1) is my understanding correct? > 2) is the dispatcher stable in its implementation? Seems stable from the community feedback, or? ;) > That is, can people > adopt it without fear of their sites breaking or the dispatcher moving > so far from its current implementation that sites will need to be > reconfigured? Well I am tended to play the oracle from delphi, but seriously I think we should adopt user feedback as well in the future like now. If that means we need to change some things than we need to do it (like we always did). ...but I personally consider the current structurer/contract grammar (the only thing that would need reconfiguring) as stable. Like said above when we get lots of feedback to change some things then we need to decide on a case-per-case basis but generally we are always open for enhancements. > If dispatcher cannot be called stable yet then I do not think we should > be encouraging users to adopt it. If it is considered stable then I > think a statement to the effect of "cutting edge users and developers > are encouraged to *test* the dispatcher which is intended to replace > skins in 0.9" I think we should move the dispatcher out of the whiteboard now. There are only some minor enhancements that keeps it still in there. I reckon when we are switching to dispatcher after the 0.8 release (in 0.9-dev) then the least thing is to add the dispatcher to the official plugins before the 0.8 release. It is just a svn mv and some other things, or? > > I made a start today with a new document called: > > "Status of Themes: Skins and Dispatcher" ... > > http://svn.apache.org/viewcvs?rev=398810&view=rev > > It's down at the moment - will look later. > Sounds good. Thanks David. salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
Re: status of skins and dispatcher for 0.8 release
David Crossley wrote: We need to have a very clear statement about the status of "Skins" and "Dispatcher" for the upcoming 0.8 release. This statement needs to reflect the vision of developers and where the PMC wants the project to be going. At the same time we need to be careful to not get people over-excited about new technologies that are not quite ready. Remember the mess that we got into at Apache Incubator. Users and developers need to know that Skins are still usable and still the main mechanism. There is then the Dispatcher work-in-progress that has reached an excellent stage. We certainly want to encourage people to investigate it and help to develop it. It is my understanding that we have not yet made a decision about when Dispatcher will be ready, nor whether it will replace skins or whether both will be usable as plugins. I, for one, am happy to further delay that decision, but we need to come up with some words to define the situation. What do others think? It is my understanding that the intention is to eventually have dispatcher in core and that the current skins functionality will move to an internal plugin. This means that new sites will be seeded with the dispatcher as default, old sites will need to add the skins plugin to their forrest.properties. It is my understanding that this is scheduled to happen in the 0.9 release, by which time the dispatcher should be stable. So, my questions are: 1) is my understanding correct? 2) is the dispatcher stable in its implementation? That is, can people adopt it without fear of their sites breaking or the dispatcher moving so far from its current implementation that sites will need to be reconfigured? If dispatcher cannot be called stable yet then I do not think we should be encouraging users to adopt it. If it is considered stable then I think a statement to the effect of "cutting edge users and developers are encouraged to *test* the dispatcher which is intended to replace skins in 0.9" I made a start today with a new document called: "Status of Themes: Skins and Dispatcher" ... http://svn.apache.org/viewcvs?rev=398810&view=rev It's down at the moment - will look later. Ross
Re: svn commit: r398460 - /forrest/trunk/main/webapp/skins/common/skinconf.xsl
le 01/05/2006 01:21 [EMAIL PROTECTED] a écrit : Author: crossley Date: Sun Apr 30 16:21:01 2006 New Revision: 398460 URL: http://svn.apache.org/viewcvs?rev=398460&view=rev Log: Increment default $year. Modified: forrest/trunk/main/webapp/skins/common/skinconf.xsl Modified: forrest/trunk/main/webapp/skins/common/skinconf.xsl URL: http://svn.apache.org/viewcvs/forrest/trunk/main/webapp/skins/common/skinconf.xsl?rev=398460&r1=398459&r2=398460&view=diff == --- forrest/trunk/main/webapp/skins/common/skinconf.xsl (original) +++ forrest/trunk/main/webapp/skins/common/skinconf.xsl Sun Apr 30 16:21:01 2006 @@ -81,7 +81,7 @@ - 2005 + 2006 In the siteinfo-copyright.ft contract, there is a nice method which calculates and layout the copyright date(s), here is the comments : It is not necessary to update the date every year. Salutations, Cyriaque, The Acme Software Foundation.
status of skins and dispatcher for 0.8 release
We need to have a very clear statement about the status of "Skins" and "Dispatcher" for the upcoming 0.8 release. This statement needs to reflect the vision of developers and where the PMC wants the project to be going. At the same time we need to be careful to not get people over-excited about new technologies that are not quite ready. Remember the mess that we got into at Apache Incubator. Users and developers need to know that Skins are still usable and still the main mechanism. There is then the Dispatcher work-in-progress that has reached an excellent stage. We certainly want to encourage people to investigate it and help to develop it. It is my understanding that we have not yet made a decision about when Dispatcher will be ready, nor whether it will replace skins or whether both will be usable as plugins. I, for one, am happy to further delay that decision, but we need to come up with some words to define the situation. What do others think? I made a start today with a new document called: "Status of Themes: Skins and Dispatcher" ... http://svn.apache.org/viewcvs?rev=398810&view=rev -David
[jira] Assigned: (FOR-867) need doc to explain status of skins and dispatcher
[ http://issues.apache.org/jira/browse/FOR-867?page=all ] David Crossley reassigned FOR-867: -- Assign To: David Crossley > need doc to explain status of skins and dispatcher > -- > > Key: FOR-867 > URL: http://issues.apache.org/jira/browse/FOR-867 > Project: Forrest > Type: Task > Components: Dispatcher (aka views), Documentation and website, Skins > (general issues) > Versions: 0.8-dev > Reporter: David Crossley > Assignee: David Crossley > Priority: Blocker > Fix For: 0.8-dev > > Need doc to explain status of skins and dispatcher. Link to the doc from > warnings of dispatchers docs, from skins.html and from upgrading_08.html > I have already commenced this xdoc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FOR-867) need doc to explain status of skins and dispatcher
need doc to explain status of skins and dispatcher -- Key: FOR-867 URL: http://issues.apache.org/jira/browse/FOR-867 Project: Forrest Type: Task Components: Dispatcher (aka views), Documentation and website, Skins (general issues) Versions: 0.8-dev Reporter: David Crossley Priority: Blocker Fix For: 0.8-dev Need doc to explain status of skins and dispatcher. Link to the doc from warnings of dispatchers docs, from skins.html and from upgrading_08.html I have already commenced this xdoc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FOR-314) synchronise pelt skin: ensure all features from old krysalis-site and forrest-site skins
[ http://issues.apache.org/jira/browse/FOR-314?page=comments#action_12366144 ] David Crossley commented on FOR-314: The original review was only basic, so we may have lost some features. Items A, B, C are fixed. However Items D and E still remain in plugin ...internal.dispatcher/resources/stylesheets/html/book-to-menu.xsl These are fixed in main/webapp/skins/common/xslt/html/book-to-menu.xsl > synchronise pelt skin: ensure all features from old krysalis-site and > forrest-site skins > > > Key: FOR-314 > URL: http://issues.apache.org/jira/browse/FOR-314 > Project: Forrest > Type: Bug > Components: Skins (general issues) > Versions: 0.6 > Reporter: David Crossley > Priority: Minor > > The old skins were reviewed to ensure that features were not lost in the > migration to the pelt skin. The following issues are noted for pelt ... > site2xhtml.xsl > A) needs "copyright-link" from "forrest-site" and "All rights reserved." > B) credits logo in alternative location needs a divider from the navigation > menu above it. (around line 390) > document2html.xsl > C) line 98 why "test -"? > book2menu.xsl > D) why at match="menu" at line 36? > E) why is 'font color="#ffcc00"' in template name="print-external" ... CSS? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FOR-808) Switch from skins to dispatcher as default
[ http://issues.apache.org/jira/browse/FOR-808?page=all ] Thorsten Scherler updated FOR-808: -- Comment: was deleted > Switch from skins to dispatcher as default > -- > > Key: FOR-808 > URL: http://issues.apache.org/jira/browse/FOR-808 > Project: Forrest > Type: Task > Components: Core operations, Dispatcher (aka views), Skins (general issues) > Reporter: Thorsten Scherler > Priority: Minor > > We need to plan the switch from skins to the dispatcher. > This issue should track the issues involved in this task. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (FOR-314) synchronise pelt skin: ensure all features from old krysalis-site and forrest-site skins
[ http://issues.apache.org/jira/browse/FOR-314?page=comments#action_12366106 ] Thorsten Scherler commented on FOR-314: --- Is this still an open issue? Will resolve (wont fix) it after a week from now. lazy consensus active. > synchronise pelt skin: ensure all features from old krysalis-site and > forrest-site skins > > > Key: FOR-314 > URL: http://issues.apache.org/jira/browse/FOR-314 > Project: Forrest > Type: Bug > Components: Skins (general issues) > Versions: 0.6 > Reporter: David Crossley > Priority: Minor > > The old skins were reviewed to ensure that features were not lost in the > migration to the pelt skin. The following issues are noted for pelt ... > site2xhtml.xsl > A) needs "copyright-link" from "forrest-site" and "All rights reserved." > B) credits logo in alternative location needs a divider from the navigation > menu above it. (around line 390) > document2html.xsl > C) line 98 why "test -"? > book2menu.xsl > D) why at match="menu" at line 36? > E) why is 'font color="#ffcc00"' in template name="print-external" ... CSS? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (FOR-809) Remove build targets around "skins"
Thorsten Scherler (JIRA) wrote: > Remove build targets around "skins" > --- > > Key: FOR-809 > URL: http://issues.apache.org/jira/browse/FOR-809 > Project: Forrest > Type: Sub-task > Components: Core operations, Dispatcher (aka views), Skins (general issues) > > Versions: 0.9 > Reporter: Thorsten Scherler > Priority: Minor > > We need to remove some targets that we now use for skins for the dispatcher. > > from forrest site: > > check-skin: > ... > > fetch-skins-descriptors: > > fetch-skin: > > unpack-skins: > > init-skins: > ... [ snip more ] However, we need to discuss and then declare somewhere for how long we are going to support the "skins". I removed the "Version" from these Jira issues. When we decide then use the "Fix Version". -David
[jira] Updated: (FOR-809) Remove build targets around "skins"
[ http://issues.apache.org/jira/browse/FOR-809?page=all ] David Crossley updated FOR-809: --- Version: (was: 0.9) > Remove build targets around "skins" > --- > > Key: FOR-809 > URL: http://issues.apache.org/jira/browse/FOR-809 > Project: Forrest > Type: Sub-task > Components: Core operations, Dispatcher (aka views), Skins (general issues) > Reporter: Thorsten Scherler > Priority: Minor > > We need to remove some targets that we now use for skins for the dispatcher. > from forrest site: > check-skin: > ... > fetch-skins-descriptors: > fetch-skin: > unpack-skins: > init-skins: > ... > -validate-skinconf: > 1 file(s) have been successfully validated. > ...validated skinconf > validate-skins-stylesheets: > validate-skins: > validate-skinchoice: > ...validated existence of skin 'pelt' > Created dir: > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/build/site/skin/images > Copying 23 files to > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/build/site/skin/images > Copying 14 files to > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/build/site/skin/images > Copying project skin images to site ... > Warning: > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/src/documentation/skins/common/images > not found. > Warning: > /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/src/documentation/skins/pelt/images > not found. > Copying main skin css and js files to site ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (FOR-808) Switch from skins to dispatcher as default
[ http://issues.apache.org/jira/browse/FOR-808?page=all ] David Crossley updated FOR-808: --- Version: (was: 0.9) > Switch from skins to dispatcher as default > -- > > Key: FOR-808 > URL: http://issues.apache.org/jira/browse/FOR-808 > Project: Forrest > Type: Task > Components: Core operations, Dispatcher (aka views), Skins (general issues) > Reporter: Thorsten Scherler > Priority: Minor > > We need to plan the switch from skins to the dispatcher. > This issue should track the issues involved in this task. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FOR-809) Remove build targets around "skins"
Remove build targets around "skins" --- Key: FOR-809 URL: http://issues.apache.org/jira/browse/FOR-809 Project: Forrest Type: Sub-task Components: Core operations, Dispatcher (aka views), Skins (general issues) Versions: 0.9 Reporter: Thorsten Scherler Priority: Minor We need to remove some targets that we now use for skins for the dispatcher. from forrest site: check-skin: ... fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: ... -validate-skinconf: 1 file(s) have been successfully validated. ...validated skinconf validate-skins-stylesheets: validate-skins: validate-skinchoice: ...validated existence of skin 'pelt' Created dir: /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/build/site/skin/images Copying 23 files to /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/build/site/skin/images Copying 14 files to /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/build/site/skin/images Copying project skin images to site ... Warning: /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/src/documentation/skins/common/images not found. Warning: /home/thorsten/src/apache/forrest-trunk/main/template-sites/v2/src/documentation/skins/pelt/images not found. Copying main skin css and js files to site ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (FOR-808) Switch from skins to dispatcher as default
Switch from skins to dispatcher as default -- Key: FOR-808 URL: http://issues.apache.org/jira/browse/FOR-808 Project: Forrest Type: Task Components: Core operations, Dispatcher (aka views), Skins (general issues) Versions: 0.9 Reporter: Thorsten Scherler Priority: Minor We need to plan the switch from skins to the dispatcher. This issue should track the issues involved in this task. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: svn commit: r358325 - /forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
Johannes Schaefer wrote: > now, if everybody agrees I'll need to backport this to 0.7 You don't really need to ask. Add whatever changes that you see fit. Just ensure that any changes have also been made to trunk. The default is that we don't bother reflecting any new stuff into the branch. If a developer has a need then they can send a patch. Ideally this is an 'svn merge' so we get the exact same changes that were done in trunk. -David
Re: svn commit: r358325 - /forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
now, if everybody agrees I'll need to backport this to 0.7 Johannes [EMAIL PROTECTED] schrieb: > Author: josch > Date: Wed Dec 21 08:55:12 2005 > New Revision: 358325 > > URL: http://svn.apache.org/viewcvs?rev=358325&view=rev > Log: > added new template "add.class" > * adds a class w/o removing previously set classes and > * w/o inserting unnecessary blanks > applied it to et al. and > > Modified: > forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl > > Modified: > forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl > URL: > http://svn.apache.org/viewcvs/forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl?rev=358325&r1=358324&r2=358325&view=diff > ====== > --- forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl > (original) > +++ forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl Wed > Dec 21 08:55:12 2005 > @@ -137,7 +137,10 @@ > > > > - > + > + > + select="local-name()"/> > + > > > > @@ -228,12 +231,9 @@ > > > > - > - > - codefrag select="@class"/> > - codefrag > - > - > + > +codefrag > + > > > > @@ -383,6 +383,24 @@ > > > > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > + > > > > > > -- User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99 Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 * D-81825 München www.uidesign.de Buch "User Interface Tuning" von Joachim Machate & Michael Burmester www.user-interface-tuning.de
Re: svn commit: r358278 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl
still hesitating/experimenting on hwo to do this, see my last mails ... js Ross Gardler schrieb: > [EMAIL PROTECTED] wrote: > >> Author: josch >> Date: Wed Dec 21 04:51:17 2005 >> New Revision: 358278 >> >> URL: http://svn.apache.org/viewcvs?rev=358278&view=rev >> Log: >> pass class on to and , e.g. from sdocbook-plugin >> >> Modified: >> >> forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl >> > > > > Please make changes like these in trunk as well where appropriate > > Ross > -- User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99 Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 * D-81825 München www.uidesign.de Buch "User Interface Tuning" von Joachim Machate & Michael Burmester www.user-interface-tuning.de
Re: svn commit: r358278 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl
[EMAIL PROTECTED] wrote: Author: josch Date: Wed Dec 21 04:51:17 2005 New Revision: 358278 URL: http://svn.apache.org/viewcvs?rev=358278&view=rev Log: pass class on to and , e.g. from sdocbook-plugin Modified: forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl Please make changes like these in trunk as well where appropriate Ross
Re: svn commit: r354838 - /forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
Tim Williams schrieb: > On 12/21/05, Johannes Schaefer <[EMAIL PROTECTED]> wrote: > >> >>[EMAIL PROTECTED] schrieb: >> >>>Author: rgardler >>>Date: Wed Dec 7 11:58:13 2005 >>>New Revision: 354838 >>> >>>URL: http://svn.apache.org/viewcvs?rev=354838&view=rev >>>Log: >>>check for existence of @class to prevent an extra space being added when not >>>needed >> >>Is this necessary? The extra space does not do any harm. >>If "Yes", I'll update my recent comitts accordingly. >>Sorry for not noticing/reviewing earlier. >>Johannes > > > I think this came up because it caused unexpected changes in the > forrestbot build to our docs. Someone will let us know if I'm wrong. > http://marc.theaimsgroup.com/?l=forrest-dev&m=113384565318583&w=2 wow! small change big effect! Will do my best to avoid extra spaces, then. Thanks for the link. Johannes > > --tim > -- User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99 Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 * D-81825 München www.uidesign.de Buch "User Interface Tuning" von Joachim Machate & Michael Burmester www.user-interface-tuning.de
Re: svn commit: r354838 - /forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
On 12/21/05, Johannes Schaefer <[EMAIL PROTECTED]> wrote: > > > [EMAIL PROTECTED] schrieb: > > Author: rgardler > > Date: Wed Dec 7 11:58:13 2005 > > New Revision: 354838 > > > > URL: http://svn.apache.org/viewcvs?rev=354838&view=rev > > Log: > > check for existence of @class to prevent an extra space being added when > > not needed > > Is this necessary? The extra space does not do any harm. > If "Yes", I'll update my recent comitts accordingly. > Sorry for not noticing/reviewing earlier. > Johannes I think this came up because it caused unexpected changes in the forrestbot build to our docs. Someone will let us know if I'm wrong. http://marc.theaimsgroup.com/?l=forrest-dev&m=113384565318583&w=2 --tim
Re: svn commit: r354838 - /forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
[EMAIL PROTECTED] schrieb: > Author: rgardler > Date: Wed Dec 7 11:58:13 2005 > New Revision: 354838 > > URL: http://svn.apache.org/viewcvs?rev=354838&view=rev > Log: > check for existence of @class to prevent an extra space being added when not > needed Is this necessary? The extra space does not do any harm. If "Yes", I'll update my recent comitts accordingly. Sorry for not noticing/reviewing earlier. Johannes > > Modified: > forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl > > Modified: > forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl > URL: > http://svn.apache.org/viewcvs/forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl?rev=354838&r1=354837&r2=354838&view=diff > == > --- forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl > (original) > +++ forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl Wed > Dec 7 11:58:13 2005 > @@ -227,7 +227,13 @@ > > > > - > + > + > + > + codefrag select="@class"/> > + codefrag > + > + > > > > > > -- User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99 Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 * D-81825 München www.uidesign.de Buch "User Interface Tuning" von Joachim Machate & Michael Burmester www.user-interface-tuning.de
Re: svn commit: r358278 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl
Johannes Schaefer schrieb: > What happened to my former comitt? sorry, this applies to TRUNK, I looked at 0.7. js > http://marc.theaimsgroup.com/?l=forrest-dev&m=113320014819323&w=2 > > Was there a roll-back due to Thorstens reply? > It's a minor thing but I would like to understand. > > Johannes > > > [EMAIL PROTECTED] schrieb: > >>Author: josch >>Date: Wed Dec 21 04:51:17 2005 >>New Revision: 358278 >> >>URL: http://svn.apache.org/viewcvs?rev=358278&view=rev >>Log: >>pass class on to and , e.g. from sdocbook-plugin >> >>Modified: >> >> forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl >> >>Modified: >>forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl >>URL: >>http://svn.apache.org/viewcvs/forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl?rev=358278&r1=358277&r2=358278&view=diff >>== >>--- >>forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl >> (original) >>+++ >>forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl >> Wed Dec 21 04:51:17 2005 >>@@ -137,7 +137,8 @@ >> >> >> >>- >>+ >>+ >> >> >> >>@@ -151,6 +152,7 @@ >> >> >> >>+ >> >> >> >>@@ -227,7 +229,7 @@ >> >> >> >>- >>+ >> >> >> >> >> >> > > -- User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99 Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 * D-81825 München www.uidesign.de Buch "User Interface Tuning" von Joachim Machate & Michael Burmester www.user-interface-tuning.de
Re: svn commit: r358278 - /forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl
What happened to my former comitt? http://marc.theaimsgroup.com/?l=forrest-dev&m=113320014819323&w=2 Was there a roll-back due to Thorstens reply? It's a minor thing but I would like to understand. Johannes [EMAIL PROTECTED] schrieb: > Author: josch > Date: Wed Dec 21 04:51:17 2005 > New Revision: 358278 > > URL: http://svn.apache.org/viewcvs?rev=358278&view=rev > Log: > pass class on to and , e.g. from sdocbook-plugin > > Modified: > > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl > > Modified: > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl > URL: > http://svn.apache.org/viewcvs/forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl?rev=358278&r1=358277&r2=358278&view=diff > ====== > --- > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl > (original) > +++ > forrest/branches/forrest_07_branch/main/webapp/skins/common/xslt/html/document2html.xsl > Wed Dec 21 04:51:17 2005 > @@ -137,7 +137,8 @@ > > > > - > + > + > > > > @@ -151,6 +152,7 @@ > > > > + > > > > @@ -227,7 +229,7 @@ > > > > - > + > > > > > > -- User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99 Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 * D-81825 München www.uidesign.de Buch "User Interface Tuning" von Joachim Machate & Michael Burmester www.user-interface-tuning.de
please check svn client config (Was: svn commit: r354332 ...skins/scales/ ...
Hi Ferdinand, would you please see if there is something wrong with the configuration of your svn client. I presume that it must be missing "eol-style native" for the extensions below and that is why your commit had Windows line-endings. Doing a 'diff' said that every line had changed, e.g. diff pelt/xslt/html/site-to-xhtml.xsl scales/xslt/html/ Wheras in fact it is an exact copy, but with bad line-endings. http://www.apache.org/dev/version-control.html#https-svn -David > Author: crossley > Date: Mon Dec 5 22:12:27 2005 > New Revision: 354332 > > URL: http://svn.apache.org/viewcvs?rev=354332&view=rev > Log: > Fix DOS line-ending and svn:eol-style > > Modified: > forrest/trunk/main/webapp/skins/scales/css/basic.css (contents, props > changed) > forrest/trunk/main/webapp/skins/scales/css/print.css (contents, props > changed) > forrest/trunk/main/webapp/skins/scales/css/profile.css.xslt (contents, > props changed) > forrest/trunk/main/webapp/skins/scales/css/screen.css (contents, props > changed) > forrest/trunk/main/webapp/skins/scales/note.txt (contents, props > changed) > forrest/trunk/main/webapp/skins/scales/skinconf.xsl (contents, props > changed) > forrest/trunk/main/webapp/skins/scales/xslt/fo/document-to-fo.xsl > (contents, props changed) > forrest/trunk/main/webapp/skins/scales/xslt/html/book-to-menu.xsl > (contents, props changed) > forrest/trunk/main/webapp/skins/scales/xslt/html/document-to-html.xsl > (contents, props changed) > forrest/trunk/main/webapp/skins/scales/xslt/html/site-to-xhtml.xsl > (contents, props changed) > forrest/trunk/main/webapp/skins/scales/xslt/html/tab-to-menu.xsl > (contents, props changed)
Re: svn commit: r349444 - /forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
see comments inline
Johannes Schaefer schrieb:
> Still -1?
> Johannes
this ought not to be here ...
js
>
>
> Thorsten Scherler schrieb:
>
>>El lun, 28-11-2005 a las 17:48 +, [EMAIL PROTECTED] escribió:
>>
>>
>>>Author: josch
>>>Date: Mon Nov 28 09:48:30 2005
>>>New Revision: 349444
>>>
>>>URL: http://svn.apache.org/viewcvs?rev=349444&view=rev
>>>Log:
>>>make respect @class; used to differentiate e.g. from sdocbook's
>>>,
>>>
>>>Modified:
>>> forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
>>>
>>>Modified:
>>>forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
>>>URL:
>>>http://svn.apache.org/viewcvs/forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl?rev=349444&r1=349443&r2=349444&view=diff
>>>==
>>>--- forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
>>>(original)
>>>+++ forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
>>>Mon Nov 28 09:48:30 2005
>>>@@ -227,7 +227,7 @@
>>>
>>>
>>>
>>>-
>>>+
>>
>>
>>That is not really css friendly. Please use:
>>+
>
>
> I did it like this to leave the other *.css definitions
> untouched.
>
>
>>Otherwise it is a nightmare in the *.css.
>
>
> Don't understand why, it's one of the features of CSS,
> see e.g.
> http://dhtmlkitchen.com/learn/css/multiclass/
> (The example there is not very useful, though)
>
> I added this to skinconf/extra-css:
>
> .literal { font-weight:bold; }
>
> which gives me nicely monospaced + bold for
>
> Still objecting?
> Johannes
>
>
>>salu2
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>
>
--
User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg
Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99
Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 *
D-81825 München
www.uidesign.de
Buch "User Interface Tuning" von Joachim Machate & Michael Burmester
www.user-interface-tuning.de
Re: svn commit: r349444 - /forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
Still -1?
Johannes
Thorsten Scherler schrieb:
> El lun, 28-11-2005 a las 17:48 +, [EMAIL PROTECTED] escribió:
>
>>Author: josch
>>Date: Mon Nov 28 09:48:30 2005
>>New Revision: 349444
>>
>>URL: http://svn.apache.org/viewcvs?rev=349444&view=rev
>>Log:
>>make respect @class; used to differentiate e.g. from sdocbook's
>>,
>>
>>Modified:
>>forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
>>
>>Modified:
>>forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
>>URL:
>>http://svn.apache.org/viewcvs/forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl?rev=349444&r1=349443&r2=349444&view=diff
>>==
>>--- forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
>>(original)
>>+++ forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl Mon
>>Nov 28 09:48:30 2005
>>@@ -227,7 +227,7 @@
>>
>>
>>
>>-
>>+
>
>
> That is not really css friendly. Please use:
> +
I did it like this to leave the other *.css definitions
untouched.
> Otherwise it is a nightmare in the *.css.
Don't understand why, it's one of the features of CSS,
see e.g.
http://dhtmlkitchen.com/learn/css/multiclass/
(The example there is not very useful, though)
I added this to skinconf/extra-css:
.literal { font-weight:bold; }
which gives me nicely monospaced + bold for
Still objecting?
Johannes
>
> salu2
>
>
>>
>>
>>
>>
>>
--
User Interface Design GmbH * Teinacher Str. 38 * D-71634 Ludwigsburg
Fon +49 (0)7141 377 000 * Fax +49 (0)7141 377 00-99
Geschäftsstelle: User Interface Design GmbH * Lehrer-Götz-Weg 11 *
D-81825 München
www.uidesign.de
Buch "User Interface Tuning" von Joachim Machate & Michael Burmester
www.user-interface-tuning.de
Re: svn commit: r349444 - /forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl
El lun, 28-11-2005 a las 17:48 +, [EMAIL PROTECTED] escribió: > Author: josch > Date: Mon Nov 28 09:48:30 2005 > New Revision: 349444 > > URL: http://svn.apache.org/viewcvs?rev=349444&view=rev > Log: > make respect @class; used to differentiate e.g. from sdocbook's > , > > Modified: > forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl > > Modified: > forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl > URL: > http://svn.apache.org/viewcvs/forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl?rev=349444&r1=349443&r2=349444&view=diff > ====== > --- forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl > (original) > +++ forrest/trunk/main/webapp/skins/common/xslt/html/document-to-html.xsl Mon > Nov 28 09:48:30 2005 > @@ -227,7 +227,7 @@ > > > > - > + That is not really css friendly. Please use: + Otherwise it is a nightmare in the *.css. salu2 > > > > > -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd)
Re: svn commit: r348868 - /forrest/branches/forrest_07_branch/main/webapp/skins/pelt/images/chapter_open.gif
Ferdinand Soethe wrote: Ross Gardler wrote: Please add changes to trunk, if you need them in 0.7 as well that's fine for this kind of change, but please keep 0.8 in sync otherwise it becomes a big job to release 0.8 Sorry, I thought I had. Checking Modified: forrest/trunk/main/webapp/skins/pelt/images/chapter_open.gif Still think I have. :-) Sorry I must have missed it. Ross
Re: svn commit: r348868 - /forrest/branches/forrest_07_branch/main/webapp/skins/pelt/images/chapter_open.gif
Ross Gardler wrote: > Please add changes to trunk, if you need them in 0.7 as well that's fine > for this kind of change, but please keep 0.8 in sync otherwise it > becomes a big job to release 0.8 Sorry, I thought I had. Checking > Modified: forrest/trunk/main/webapp/skins/pelt/images/chapter_open.gif Still think I have. Have a nice weekend ... -- Ferdinand Soethe
