You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Ross Gardler <rg...@apache.org> on 2005/02/23 13:00:00 UTC
[RT] Per document skinconf (was Re: coloring table cells [from the
user list])
Johannes Schaefer wrote:
> Is there a valid way to specify a specific style for a
> single element in document-v1.3 (or v2.0)?
>
> The only way I see is to use a class attribute but this is
> not possible because each and every cell may have a
> different bg-color.
[Note what I am thinking about here is quite a bit of work, I'd suggest
that if anyone tackles it they should do so in a branch so that there is
no danger of it messing up the 0.7 release.]
The Problem
===========
In Forrest we have always insisted that the source document should not
contain any style information. However with our increasing support of
other formats we are losing control of this in some cases. Already there
are two solutions in two different plugins.
I really don't like the idea of embedding style information into the
style attribute of the Intermediate format as is the current solution
for the Excel plugin. Similarly I do not like the solution I hacked for
the OpenOffice.org plugin (en embedded style element in the header).
I think we need to devise a solution for use in Input plugins that will
be the "official" way for Forrest to deal with embedded style
information. Note that I am *not* suggesting we allow style information
into documents written specifically for Forrest, just that we handle
documents with embedded style information in a consistent way.
This means that at the intermediate format must allow skin information
to be extended, but how?
A second, but related problem, is the feature requests we have for per
page configuration of the skin. Some people want to turn the PDF button
on or off on a per page basis, others want to change the logo images at
the top of the page.
fbits are a proposed solution to this. I'm not sure how this RT fits in
with fbits or if it stomps all over the fbits proposal. That is why this
is an RT (random thoughts) rather than a proposal. I want to see if it
all fits together.
Generating skinconf.xml
=======================
Recently, Bastian Bowe showed us how we can customise skinconfig on a
per plugin basis
(http://marc.theaimsgroup.com/?l=forrest-dev&m=110873270020951&w=2). I
think if we extend this idea a little we could have plugins generate the
extended config info.
Consider this match (hint: the map:generate of the current sitemap has
been replaced by map:aggregate):
<map:match pattern="**body-*.html">
<map:aggregate element="page">
<map:part src="cocoon:/{1}{2}.xml"/>
<map:part src="cocoon:/{1}pageconf-{2}.xml"/>
</map:generate>
<map:transform type="idgen"/>
<map:transform type="xinclude"/>
<map:transform type="linkrewriter"
src="cocoon:/{1}linkmap-{2}.html"/>
<map:transform
src="resources/stylesheets/declare-broken-site-links.xsl" />
<map:call resource="skinit">
<map:parameter name="type" value="document2html"/>
<map:parameter name="path" value="{1}{2}.html"/>
<map:parameter name="notoc" value="false"/>
</map:call>
</map:match>
here we are adding configuration info for individual pages
(cocoon:/{1}pageconf-{2}.xml). Therefore it can do things like add CSS
styles or change some default behaviour, such as whether the PDF button
should be displayed or change the logo's on individual pages etc.
skinconf.xml now becomes the specification of the default behaviour.
In the event of a conflict between different plugins we would give
precedence to the one that appears first in the list of plugins in
forrest.properties (this is reflected in the order that the conf
elements appear). This conflict resolution may turn out to be too
simplistic, but I am sure it will work in the short to medium term. A
longer term solution can be found later.
Generating page config
----------------------
Each plugin must be able to contribute to the page config, so we will
need a new matcher that will aggregate all the pageconf contributions
from the individual plugins. I don't think Cocoon is able to do this and
so this match will have to be created in the same way that the relevant
plugin mounts are created (see targets/plugins.xml). The pageconf match
will appear in the generated internal.xmap file and will look like this:
<map:match pattern="**pageconf-*.xml">
<map:aggregate element="pageconf">
<map:part src="cocoon:/PLUGINNAME_1-pageconf-{1}{2}.xml/>
<map:part src="cocoon:/PLUGINNAME_2-pageconf-{1}{2}.xml/>
<map:part src="cocoon:/PLUGINNAME_3-pageconf-{1}{2}.xml/>
...
</map:aggregate>
<map:serialize type"xml"/>
</map:match>
Within each plugin sitemap we will find:
<map:match pattern="PLUGINNAME-pageconf-*.xml">
Since we are using a cocoon match to create the config we can use really
simple techniques for configuration (like a plugin.properties file) or
we can do really clever stuff like the include/exclude patterns for
enabling specific page features such as PDF buttons (as discussed on dev
list).
The output of each cocoon:/PLUGINAME-pageconf-*.xml would be something like:
<org.apache.forrest.plugin.excel>
<disable-print-link>true</disable-print-link>
<disable-pdf-link>false</disable-pdf-link>
<extra-css>
...
</extra-css>
</org.apache.forrest.plugin.PDF-output>
In most cases (i.e. all but extra-css) the values in here override those
in skinconf.xml and other pageconf elements. The extra-css values are
added to those in skinconf.xml and elsewhere in pageconf.
Using page config
-----------------
To use this information we simply need to modify any code that works
with skinconfig.xml. We would first look for a value in the pageconf
element, if it does not exist we would use the one in skinconf.xml instead.
Issues to Consider
==================
Performance
----------
There is potentially a large impact on performance here as we are
considerably increasing the number of matches for each page. This is
mitigated to some extent by only using the plugins applicable to this
site, but nevertheless the impact could be quite large. Of course,
Cocoon's caching will help considerably in most cases.
fbits
-----
How does this contribute to/intefere with work on fbits?
alternatives
------------
????
unforseen problems
------------------
?????
Ross
Re: Metadata in Forrest (was Re: [RT] Per document skinconf...)
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> Nicola Ken Barozzi wrote:
>
>> Ross Gardler wrote:
>
> ...
>
>>> All that being said, Forrest could be made to support both a separate
>>> file or embedded data (there are use cases where the simplistic
>>> solution is the best one). The problem with this is that we will have
>>> two locations for storing the same data - could be confusing for users.
>>
>>
>> IMHO the least we have to worry about is to confuse users. I have seen
>> that if there is a simple and a more complete way, users would not get
>> confused.
>>
>> The only confusion would come out of using both methods at the same
>> time, with clashing metadata values. Ouch!
>>
>> I'll browse the web for 'rdf in html', 'xhtml metadata' etc to see how
>> this is defined elsewhere. I want to try to reinvent the wheel the
>> least possible.
>
>
> And I did :-)
>
> From what I read it seems that making it possible to embed in xhtml
> *and* be able to king to a metadata file is the solution to pursue.
OK, I'm working on meta-data in an extension to Burrokeet soon (using
Dublin Core). I'll follow up on these links and create a separate RT
(after 0.7 release).
Ross
Metadata in Forrest (was Re: [RT] Per document skinconf...)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
...
>> All that being said, Forrest could be made to support both a separate
>> file or embedded data (there are use cases where the simplistic
>> solution is the best one). The problem with this is that we will have
>> two locations for storing the same data - could be confusing for users.
>
> IMHO the least we have to worry about is to confuse users. I have seen
> that if there is a simple and a more complete way, users would not get
> confused.
>
> The only confusion would come out of using both methods at the same
> time, with clashing metadata values. Ouch!
>
> I'll browse the web for 'rdf in html', 'xhtml metadata' etc to see how
> this is defined elsewhere. I want to try to reinvent the wheel the least
> possible.
And I did :-)
From what I read it seems that making it possible to embed in xhtml
*and* be able to king to a metadata file is the solution to pursue.
Informative Opinion
http://lists.oasis-open.org/archives/legalxml-econtracts/200401/msg00026.html
XHTML2 Metainformation Attributes Module
http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-metaAttributes.html
<link> to the Metadata
http://infomesh.net/2002/rdfinhtml/#link
FOAF Auto-Discovery: Publishing and Linking FOAF files
http://xmlns.com/foaf/0.1/#sec-foaffiles
Using Dublin Core
http://dublincore.org/documents/usageguide/
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
>
>> Nicola Ken Barozzi wrote:
>
...
>> Meta-data is often processed independently of actual data. For
>> example, a meta-data harvester is not interested in content. Of
>> course, this would still be possible if it were all in the same file,
>> but performance would suffer.
>
>
> So it's a technical and not a design issue. I tend to optimize later
> (and sometimes get bitten ;-)
That is also my method, and I am being bitten on the Learning Objects
projects - hence my concern here. The solution I have implemented is a
simple on in which the meta-data is embedded in the XHTML and it's a
real problem.
>> In some use cases this performance bottleneck will become an issue,
>> for example I have Learning Objects that consist of over 600 pages,
>> each with an average of around 4000 characters. Each page has an
>> additional 1000 characters of meta data (not including XML elements).
>> The nature of XML is that you need to process the whole file even if
>> you only want one element. This means we are processing 5000
>> characters of data instead of 1000, when harvesting 600 pages that is
>> 300,000 characters of data that we don't want (and we are still
>> ignoring the XML elements).
>
>
> Well, it's not true, as the stremaing parser can stop processing at any
> time. This is how we get the doctype.
OK, I concede that one :-))
>> Furthermore, meta-data tends to be highly structured and would
>> therefore benefit from being stored in a relational database rather
>> than an XML one.
>
>
> Hmmm, this is an interesting point.
I have an RDBMS Database plugin sitting on my hard drive that was built
exactly for this purpose. I've not had the time to package it nicely
yet, but it will be committed when time allows (or someone asks for it).
> My use case for metadata is title, author, etc. You have a much more
> complex use case. I now start to understand more of your POV.
I'm sure this will be the most common use case. Perhaps we now have the
first situation where we need two alternative plugins doing the same
basic job; A simple meta data plugin for handling the majority use case
of author, subject etc. and a complex one with an RDBMS and full dublin
core meta-data.
>> All that being said, Forrest could be made to support both a separate
>> file or embedded data (there are use cases where the simplistic
>> solution is the best one). The problem with this is that we will have
>> two locations for storing the same data - could be confusing for users.
>
>
> IMHO the least we have to worry about is to confuse users. I have seen
> that if there is a simple and a more complete way, users would not get
> confused.
OK
> The only confusion would come out of using both methods at the same
> time, with clashing metadata values. Ouch!
>
> I'll browse the web for 'rdf in html', 'xhtml metadata' etc to see how
> this is defined elsewhere. I want to try to reinvent the wheel the least
> possible.
I see from another mail you have found some solutions, so I'll return to
this elsewhere.
>
>>> Also, what is the relationship between skinconf.xml,
>>> pdf-output.conf.xml and metadata.xml?
>>
>>
>> The files in FORREST-INF are the defaults. So skinconf.xml contains
>> the site wide defaults for presentation elements that are core to
>> Forrest. pdf-output.conf.xml contains the defaults for PDF config
>> (button on or off, page size etc.) Metadata.xml contains site wide
>> meta data (generated-by, site title etc.)
>
>
> Why are skinconf.xml and pdf-output.conf.xml separate?
My thinking was only that the items in pdf-output.xml are irrelevant if
the pdf-output plugin is not present. Consequently, we do not want to
clutter skinconf.xml in fresh-site with config information not relevant
to the core.
An alternative would be to have the plugin add the elements into the
project skinconf-xml file the first time the site is built with the
plugin enabled.
> It seems we are in violent agreement on the concept, just need to iron
> out some smaller details.
Yes, and to see what Thorsten comes up with on the forrest:views front.
Ross
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
> Nicola Ken Barozzi wrote:
...
>> Why not insert the metadata in the file itself like I proposed? I
>> prefer to keep faith to the 1 file -> one output rule.
>
> I guess our different views here are because of different use cases. You
> seem to be assuming that you only ever want the meta-data and the
> content together. That is not the case for me.
>
> Meta-data is often processed independently of actual data. For example,
> a meta-data harvester is not interested in content. Of course, this
> would still be possible if it were all in the same file, but performance
> would suffer.
So it's a technical and not a design issue. I tend to optimize later
(and sometimes get bitten ;-)
> In some use cases this performance bottleneck will become an issue, for
> example I have Learning Objects that consist of over 600 pages, each
> with an average of around 4000 characters. Each page has an additional
> 1000 characters of meta data (not including XML elements). The nature of
> XML is that you need to process the whole file even if you only want one
> element. This means we are processing 5000 characters of data instead of
> 1000, when harvesting 600 pages that is 300,000 characters of data that
> we don't want (and we are still ignoring the XML elements).
Well, it's not true, as the stremaing parser can stop processing at any
time. This is how we get the doctype.
> Furthermore, meta-data tends to be highly structured and would therefore
> benefit from being stored in a relational database rather than an XML
> one.
Hmmm, this is an interesting point.
My use case for metadata is title, author, etc. You have a much more
complex use case. I now start to understand more of your POV.
> Meta-data is often the subject of complex queries and the speed of
> a relational database is useful here. If the meta-data is stored inside
> the content file then this can only be done by duplicating the data
> across two locations. I don't want to do that, I only want to store it
> once. This wold force the meta-data to be separate from the content.
>
> Further still, it is also common, in some use cases (i.e. editing
> Learning Objects) for a meta-data editor to be working on the meta-data
> at the same time as the content author. Having the files separate is
> useful in the absence of Version Control that does not require technical
> knowledge (most of my users can barely use an email client).
I understand now.
> All that being said, Forrest could be made to support both a separate
> file or embedded data (there are use cases where the simplistic solution
> is the best one). The problem with this is that we will have two
> locations for storing the same data - could be confusing for users.
IMHO the least we have to worry about is to confuse users. I have seen
that if there is a simple and a more complete way, users would not get
confused.
The only confusion would come out of using both methods at the same
time, with clashing metadata values. Ouch!
I'll browse the web for 'rdf in html', 'xhtml metadata' etc to see how
this is defined elsewhere. I want to try to reinvent the wheel the least
possible.
>> Also, what is the relationship between skinconf.xml,
>> pdf-output.conf.xml and metadata.xml?
>
> The files in FORREST-INF are the defaults. So skinconf.xml contains the
> site wide defaults for presentation elements that are core to Forrest.
> pdf-output.conf.xml contains the defaults for PDF config (button on or
> off, page size etc.) Metadata.xml contains site wide meta data
> (generated-by, site title etc.)
Why are skinconf.xml and pdf-output.conf.xml separate?
> As with your RT you can then have versions of these files in subsites
> that will override these defaults within the scope of the subsite.
Yup.
It seems we are in violent agreement on the concept, just need to iron
out some smaller details.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>> Ross Gardler wrote:
>>> ...
>>>
>
>> Handling Meta Data and Presentation Data
>> ----------------------------------------
>>
>> Meta-data is generated on a per file basis, with only a minority of
>> information coming from a central location. On the other hand,
>> presentation data has the majority of information coming from a
>> central location with only a minority being defined on a per file
>> granularity.
>
>
> Not necessarily. If a Forrest provider makes a site for multiple people,
> each would want it's own presentation metadata...
Exactly, if I reuse your content I will want your meta-data but not your
presentation data. Therefore we need to keep it separate.
>
>> This means that to be "able to define metadata nearer to the file that
>> needs it" we need to store the different types of data in different
>> locations. Meta-data needs to be closer to the file with an
>> opportunity to centrally define defaults (as per your RT) and
>> presentation data needs to be centralised with an opportunity to
>> override locally to the file (as per my RT).
>
>
> Again, since there are both local and central locations, where is the
> divide?
You are absolutely correct. I spotted this mistake after posting, but
thought I'd wait for your comments. Although we need two files (see
above) there need only be one access mechanism within Forrest.
>> Directory Structure
>> ===================
>>
>> How does this affect the proposed directory structure in your RT?
>>
>> You propose:
>>
>> my-project/
>> forrest.xml
>> documentation/
>> status.xml
>> ** all other content
>> FORREST-INF/
>> skinconf.xml
>> site.xml
>> tabs.xml
>>
>> This would become (arrows indicate changed/added lines):
>>
> (inserted correct version)
> ...
>
>> my-project/
>> forrest.xml
>> documentation/
>> status.xml
>> --> content.xml
>> --> content.meta.xml
>> ** all other content
>> FORREST-INF/
>> skinconf.xml
>> --> pdf-output.conf.xml
>> site.xml
>> tabs.xml
>> --> metadata.xml
>> Note that with the introduction of a meta-data plugin all the
>> meta-data files would be optional since the plugin would provide
>> defaults. Similarly the plugin conf.xml files are optional. So
>> although this looks like adding many new files, they are only present
>> if actually needed by a user.
>
>
> I don't understand what the files you add contain.
Sorry, I'll try and explain
> I suppose that content.xml is a normal xml file, and content.meta.xml
> it's metadata.
Yes
> Why not insert the metadata in the file itself like I
> proposed? I prefer to keep faith to the 1 file -> one output rule.
I guess our different views here are because of different use cases. You
seem to be assuming that you only ever want the meta-data and the
content together. That is not the case for me.
Meta-data is often processed independently of actual data. For example,
a meta-data harvester is not interested in content. Of course, this
would still be possible if it were all in the same file, but performance
would suffer.
In some use cases this performance bottleneck will become an issue, for
example I have Learning Objects that consist of over 600 pages, each
with an average of around 4000 characters. Each page has an additional
1000 characters of meta data (not including XML elements). The nature of
XML is that you need to process the whole file even if you only want one
element. This means we are processing 5000 characters of data instead of
1000, when harvesting 600 pages that is 300,000 characters of data that
we don't want (and we are still ignoring the XML elements).
Furthermore, meta-data tends to be highly structured and would therefore
benefit from being stored in a relational database rather than an XML
one. Meta-data is often the subject of complex queries and the speed of
a relational database is useful here. If the meta-data is stored inside
the content file then this can only be done by duplicating the data
across two locations. I don't want to do that, I only want to store it
once. This wold force the meta-data to be separate from the content.
Further still, it is also common, in some use cases (i.e. editing
Learning Objects) for a meta-data editor to be working on the meta-data
at the same time as the content author. Having the files separate is
useful in the absence of Version Control that does not require technical
knowledge (most of my users can barely use an email client).
All that being said, Forrest could be made to support both a separate
file or embedded data (there are use cases where the simplistic solution
is the best one). The problem with this is that we will have two
locations for storing the same data - could be confusing for users.
> Also, what is the relationship between skinconf.xml, pdf-output.conf.xml
> and metadata.xml?
The files in FORREST-INF are the defaults. So skinconf.xml contains the
site wide defaults for presentation elements that are core to Forrest.
pdf-output.conf.xml contains the defaults for PDF config (button on or
off, page size etc.) Metadata.xml contains site wide meta data
(generated-by, site title etc.)
As with your RT you can then have versions of these files in subsites
that will override these defaults within the scope of the subsite.
Ross
>
> TIA
>
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
> Nicola Ken Barozzi wrote:
>
>> Ross Gardler wrote:
>> ...
>>
>> I agree to the intent, and in fact I had done a similar proposal,
>> although without considering the impact for the plugins.
>>
>> Read this and tell me what you think, and how the two may fit.
>>
>> [RT] Directory structure and configuration
>> http://marc.theaimsgroup.com/?l=forrest-dev&m=110172138119333&w=2
>
> I remember this RT now, it seems that my RT includes many of the meme's
> planted by you in your original - this is a good sign.
Indeed! :-)
> Lets discuss...
>
> What is Meta-Data? What is Presentation Data?
> =============================================
>
> In re-reading your RT I discovered why I am not completely at ease with
> the current skinconf.xml. We are confusing two types of data in the
> skinconf.xml file. On the one hand there is true meta-data (data about
> data), for example:
>
> <project-name>Forrest</project-name>
>
> and presentation data:
>
> <disable-pdf-link>false</disable-pdf-link>
>
> We have gotten away with this so far because we do not handle meta-data
> separately. However, your RT and a post by Glen Tulikin
> (http://marc.theaimsgroup.com/?l=forrest-dev&m=110324061019177&w=2)
> start to look at how we can better handle true meta-data.
>
> Unfortunately, your RT further blurs the distinction between true
> meta-data and presentation data, for example:
>
> <meta name="credits.title.name" content="Built with Forrest">
>
> is meta-data, but:
>
> <meta name="org.apache.forrest.disable-pdf-link"
> content="true"/>
>
> is presentation data.
>
> I think to further blur things in this way would be dangerous.
Hmmm, I don't understand why you think it's dangerous.... let's read on...
> I tried
> to avoid this in my RT by ignoring the meta-data aspect. I was hoping to
> sneak it through without the need to move meta-data nearer the data
> raising its head. However, your RT has the intention of being "able to
> define metadata nearer to the file that needs it".
>
> The problem is if we mix the two types of "meta" data "the file that
> needs it" cannot be identified. I'll try to explain...
Hmmm...
> Handling Meta Data and Presentation Data
> ----------------------------------------
>
> Meta-data is generated on a per file basis, with only a minority of
> information coming from a central location. On the other hand,
> presentation data has the majority of information coming from a central
> location with only a minority being defined on a per file granularity.
Not necessarily. If a Forrest provider makes a site for multiple people,
each would want it's own presentation metadata...
> This means that to be "able to define metadata nearer to the file that
> needs it" we need to store the different types of data in different
> locations. Meta-data needs to be closer to the file with an opportunity
> to centrally define defaults (as per your RT) and presentation data
> needs to be centralised with an opportunity to override locally to the
> file (as per my RT).
Again, since there are both local and central locations, where is the
divide?
> Directory Structure
> ===================
>
> How does this affect the proposed directory structure in your RT?
>
> You propose:
>
> my-project/
> forrest.xml
> documentation/
> status.xml
> ** all other content
> FORREST-INF/
> skinconf.xml
> site.xml
> tabs.xml
>
> This would become (arrows indicate changed/added lines):
>
(inserted correct version)
...
> my-project/
> forrest.xml
> documentation/
> status.xml
> --> content.xml
> --> content.meta.xml
> ** all other content
> FORREST-INF/
> skinconf.xml
> --> pdf-output.conf.xml
> site.xml
> tabs.xml
> --> metadata.xml
>
> Note that with the introduction of a meta-data plugin all the meta-data
> files would be optional since the plugin would provide defaults.
> Similarly the plugin conf.xml files are optional. So although this looks
> like adding many new files, they are only present if actually needed by
> a user.
I don't understand what the files you add contain.
I suppose that content.xml is a normal xml file, and content.meta.xml
it's metadata. Why not insert the metadata in the file itself like I
proposed? I prefer to keep faith to the 1 file -> one output rule.
Also, what is the relationship between skinconf.xml, pdf-output.conf.xml
and metadata.xml?
TIA
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: 0.7 Plugin Documentation
Posted by David Crossley <cr...@apache.org>.
Jason End wrote:
> I was wondering if anyone would object to me rewriting
> the Plugin documentation. My understanding is that the
> 0.7 documentation isn't finished and hence I find some
> of the topics slightly confusing.
Please do. Documentation is never finished :-) and
there is always room for improvement. Do it in stages
if needed. Please send patches via the Jira Issue Tracker.
> I have some technical doubts that might require a
> couple answers from someone, but beyond that I'd have
> no problem doing the rewrite.
Please discuss any issues here on the dev list.
--David
Re: 0.7 Plugin Documentation
Posted by Ross Gardler <rg...@apache.org>.
[Please don't reply to a mail and change the subject completely it makes
the archives hard to search - start a completely new thread]
Jason End wrote:
> I was wondering if anyone would object to me rewriting
> the Plugin documentation. My understanding is that the
> 0.7 documentation isn't finished and hence I find some
> of the topics slightly confusing.
We welcome *any* contribution that you believe is an improvement to
*any* part of Forrest. Please go ahead.
> I have some technical doubts that might require a
> couple answers from someone, but beyond that I'd have
> no problem doing the rewrite.
At the moment there are only a few of us who have worked on plugins, so
the more questions that are asked about how and why it works the more
polished it will become. I'm ready to help where I can.
Ross
0.7 Plugin Documentation
Posted by Jason End <be...@yahoo.com>.
Hi,
I was wondering if anyone would object to me rewriting
the Plugin documentation. My understanding is that the
0.7 documentation isn't finished and hence I find some
of the topics slightly confusing.
I have some technical doubts that might require a
couple answers from someone, but beyond that I'd have
no problem doing the rewrite.
Jay
__________________________________
Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.
http://promotions.yahoo.com/new_mail
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Nicola Ken Barozzi wrote:
>
>> Ross Gardler wrote:
...
> my-project/
> forrest.xml
> documentation/
> status.xml
> --> content.xml
> --> content.meta.xml
> ** all other content
> FORREST-INF/
> skinconf.xml
> --> pdf-output.conf.xml
> site.xml
> tabs.xml
> --> metadata.xml
Blasted email editor inserted tabs so the layout is wrong: this is what
I intended:
my-project/
forrest.xml
documentation/
status.xml
--> content.xml
--> content.meta.xml
** all other content
FORREST-INF/
skinconf.xml
--> pdf-output.conf.xml
site.xml
tabs.xml
--> metadata.xml
Ross
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Ross Gardler <rg...@apache.org>.
Nicola Ken Barozzi wrote:
> Ross Gardler wrote:
> ...
>
> I agree to the intent, and in fact I had done a similar proposal,
> although without considering the impact for the plugins.
>
> Read this and tell me what you think, and how the two may fit.
>
> [RT] Directory structure and configuration
> http://marc.theaimsgroup.com/?l=forrest-dev&m=110172138119333&w=2
>
I remember this RT now, it seems that my RT includes many of the meme's
planted by you in your original - this is a good sign. Lets discuss...
What is Meta-Data? What is Presentation Data?
=============================================
In re-reading your RT I discovered why I am not completely at ease with
the current skinconf.xml. We are confusing two types of data in the
skinconf.xml file. On the one hand there is true meta-data (data about
data), for example:
<project-name>Forrest</project-name>
and presentation data:
<disable-pdf-link>false</disable-pdf-link>
We have gotten away with this so far because we do not handle meta-data
separately. However, your RT and a post by Glen Tulikin
(http://marc.theaimsgroup.com/?l=forrest-dev&m=110324061019177&w=2)
start to look at how we can better handle true meta-data.
Unfortunately, your RT further blurs the distinction between true
meta-data and presentation data, for example:
<meta name="credits.title.name" content="Built with Forrest">
is meta-data, but:
<meta name="org.apache.forrest.disable-pdf-link"
content="true"/>
is presentation data.
I think to further blur things in this way would be dangerous. I tried
to avoid this in my RT by ignoring the meta-data aspect. I was hoping to
sneak it through without the need to move meta-data nearer the data
raising its head. However, your RT has the intention of being "able to
define metadata nearer to the file that needs it".
The problem is if we mix the two types of "meta" data "the file that
needs it" cannot be identified. I'll try to explain...
Handling Meta Data and Presentation Data
----------------------------------------
Meta-data is generated on a per file basis, with only a minority of
information coming from a central location. On the other hand,
presentation data has the majority of information coming from a central
location with only a minority being defined on a per file granularity.
This means that to be "able to define metadata nearer to the file that
needs it" we need to store the different types of data in different
locations. Meta-data needs to be closer to the file with an opportunity
to centrally define defaults (as per your RT) and presentation data
needs to be centralised with an opportunity to override locally to the
file (as per my RT).
Directory Structure
===================
How does this affect the proposed directory structure in your RT?
You propose:
my-project/
forrest.xml
documentation/
status.xml
** all other content
FORREST-INF/
skinconf.xml
site.xml
tabs.xml
This would become (arrows indicate changed/added lines):
my-project/
forrest.xml
documentation/
status.xml
--> content.xml
--> content.meta.xml
** all other content
FORREST-INF/
skinconf.xml
--> pdf-output.conf.xml
site.xml
tabs.xml
--> metadata.xml
Note that with the introduction of a meta-data plugin all the meta-data
files would be optional since the plugin would provide defaults.
Similarly the plugin conf.xml files are optional. So although this looks
like adding many new files, they are only present if actually needed by
a user.
(At Burrokeet I am doing some extensive work on Meta-Data at present, I
hope to be moving much of this into Forrest in 2-3 months, fortunately
Nicola's RT memes seem to be infecting my work there too :-)).
Ross
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Ross Gardler wrote:
...
I agree to the intent, and in fact I had done a similar proposal,
although without considering the impact for the plugins.
Read this and tell me what you think, and how the two may fit.
[RT] Directory structure and configuration
http://marc.theaimsgroup.com/?l=forrest-dev&m=110172138119333&w=2
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Wed, 2005-02-23 at 23:23 +0000, Ross Gardler wrote:
>
>
>>OK, I suspected this would be the case. Care to expand? I'm particularly
>>interested in where the config files are placed and how Forrest
>>manipulates them.
>>
>
>
> I will answer on Johannes reply with an example.
Cool I just did the same so we can compare the methods.
>>Also how does forrest:views + fbits address the meta-data issues raised
>>in response to Nicola's RT?
>>
>
>
> Sorry, I have not look close enough to Nicola's RT yet to answer that.
OK, it is quite possible that your solution does not address this since
as understand it you are only dealing with presentation data. If not
then the solution might be forrest:views for presentation config and
Nicola/my RT for meta-data.
>>Unfortunately, I don't "get" what you are doing with fbits yet. I
>>understand the what you are trying to achieve and I like the sound of
>>it, but I have to admit to being lost as to the "how". So I seem to have
>>come up with my own "how".
>>
>
>
> Hmmm, there are some threads I wrote about it, but I will try again. ;-)
Yeah, I read them all (a number of times actually). The theory looks
great but I am still struggling with the practice. Thanks for taking the
time to hammer it in ;-)
> Ok, I will try to find time in the next couple of weeks for doing it.
> Sorry ATM I am really busy (professional and private) but I was up to
> finish it pretty soon. I hope if I can explain it to you we can finish
> it together.
No problem, like I said there is not a huge rush for this, I'm just keen
to get a solution together since we now have two plugins creating
documents that are not valid - this can only cause problems if we don't
short it out soon. As I said, I don't want to do this and then find you
implement a better solution when your time allows.
>
> ...BTW do not thread me. LOL.
I'll try to remember that, after all I'm a pacifist and I hope that we
meet one day ;-)
> No actually you have been very patient
> with the fbits. If you need it in the next two month that is a good
> motivation for me to finish it. :)
If I need it it's even better motivation for me to implement it once I
know I am doing it the way you envision - since you have done some
extensive experimentation on this elsewhere I'd hate to ignore your
experience.
Ross
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-02-23 at 23:23 +0000, Ross Gardler wrote:
> OK, I suspected this would be the case. Care to expand? I'm particularly
> interested in where the config files are placed and how Forrest
> manipulates them.
>
I will answer on Johannes reply with an example.
> Also how does forrest:views + fbits address the meta-data issues raised
> in response to Nicola's RT?
>
Sorry, I have not look close enough to Nicola's RT yet to answer that.
> Unfortunately, I don't "get" what you are doing with fbits yet. I
> understand the what you are trying to achieve and I like the sound of
> it, but I have to admit to being lost as to the "how". So I seem to have
> come up with my own "how".
>
Hmmm, there are some threads I wrote about it, but I will try again. ;-)
> I've been waiting for fbits to develop a little so that I could
> understand from the code, but I am getting closer to actually needing a
> solution for this (a few months of yet, but I like to plan in advance).
> Either you make me understand the "how" of fbits and I contribute to
> that or I'll have to get on with implementing something along the lines
> of this RT (and Nicola's). (this sounds a little like a threat, of
> course it isn't it's an attempt to avoid duplication of work. As I said
> I won't actually be implementing this for a month or two anyway so we
> have plenty of time to work out which way to go).
Ok, I will try to find time in the next couple of weeks for doing it.
Sorry ATM I am really busy (professional and private) but I was up to
finish it pretty soon. I hope if I can explain it to you we can finish
it together.
...BTW do not thread me. LOL. No actually you have been very patient
with the fbits. If you need it in the next two month that is a good
motivation for me to finish it. :)
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Ross Gardler <rg...@apache.org>.
Johannes Schaefer wrote:
> Thorsten Scherler wrote:
>
>> On Thu, 2005-02-24 at 10:31 +0000, Ross Gardler wrote:
>>
>>> Johannes Schaefer wrote:
>>>
>>>
>>>> With what is proposed now would I have to define a
>>>> lot of classes like class="color_ff00ff" and define
>>>> these classes in the file-specific config?
>>>
>>>
>>> Take a look at the OOo plugin. It does exactly this with a similar
>>> file format, although it places the style stiff in the xdoc so this
>>> is only a partial solution, but at least it uses classes. Perhaps you
>>> can try and replicate for the Excel sheet to see if it works. Here's
>>> a where to start looking:
>>>
>>> In the root template we have
>>>
>>> <header>
>>> <title>
>>> ....
>>> </title>
>>> <xsl:call-template name="style"/>
>>> </header>
>>>
>>> The style template looks like this:
>>>
>>> <xsl:template name="style">
>>> <style>
>>> <xsl:apply-templates select="//office:styles/style:style"/>
>>> <xsl:apply-templates
>>> select="//office:automatic-styles/style:style"/>
>>> </style>
>>> </xsl:template>
>>>
>>> The rest of the templates you can easily trace from here. We match
>>> all the style information that we want to allow through to the
>>> skinning stage, therefore it would be possible to configure which
>>> style information we allow and which we disallow on a per document
>>> basis.
>
>
> In the OOo plugin the style information is available
> *before* writing the output. In the Excel plugin the cell
> content determins the style (i.e. color) of it. I would have
> to do a pre-processing step to create all the classes
> (styles) and put them into the header
> (anybody to suggest how?).
I'm not following you, how is this different to the OOo plugin? In the
OOo plugin the OOo style information is aggregated with the content in
the first stage of the pipeline so it is all processed at the same time.
In the Excel document this is also the case isn't it?
Perhaps a more complete example will help (please make it another thread
as this is getting off topic here)
> But this is not where the discussion is heading ... the
> style information should be neither in-line nor in-header.
Agreed
>>> With this RT this style information would be extracted with the
>>> request for the plugin config stuff rather than embedded in head.
>
>
> If it was to write a separate file (like a template), this
> could be done I think (again: how?).
No need to actually write a file, we would need a second pipeline that
processed the request for the CSS and generated it on the fly. Cocoon
will handle the caching for us. SO the process would be:
- browser requests page (say myPage.html)
- generate XDoc from XML (with class attributes)
- generate HTML from XDoc (adding a link to a virtual CSS stylesheet,
say myPage.excelStylesheet.css)
- generate the CSS from the XML source in response to browser request
for myPage.excelStylesheet.css
>> The problem that I see is that if you have a table with many colored
>> fields and all have different colors that can be pretty soon overkill. I
>> understand that the intermediate format should be clean of style
>> information but I reckon it will be pretty hard to achieve.
>
>
> Right, putting each color into a class/ft could explode
> the style section.
>
> We now have about 25 basic colors but I don't know what
> others will come up with (or other projects).
Let us suppose we have 25 cells, 24 have a different colour, but one has
a duplicate colour. Embedding the colour definition in the TD element
means 25 definitions, using classes means 24 definitions.
What I am trying to say is that whilst it may explode, it will never be
bigger than the original source.
>> Now to the promised example, I would place the style information into a
>> forrest:view like:
>>
>> ...
>> <forrest:hook name="color_ff0000">
>> <css>
>> <background-color value="#ff0000"/>
>> </css>
>> </forrest:hook>
>> ...
>>
>> Then I would add this to fileSpecific.ft (ft = forrest template) add it
>> to an aggregation and match it in the xsl.
>> In the document I would recommend to add an attribute <td
>> ft="color_ff0000"/> that will be matched in the xsl.
>
>
> For me it would be sufficient to have @class. No new
> attribute @ft needed. The question is, how and where
> can I define the classes? They need to make it into
> CSS-classes at the skinning stage (like Excel-CSS).
My original proposal in this thread was that we provide defaults in a
"excel-input.conf.xml" file, which is augmented by a pipeline in the
plugin that defines some information (like embedded styles) on the fly.
>
> I still cannot see a big difference between a
> class=" background_color__ff0000 "
> and a style="{background-color=#ff0000;}"
>
> Both look to me like style information ;-)
The two differences are subtle, but very important:
- class promotes reuse (i.e. we don't want to allow style in the
intermediate docs as they are used for many other purposes, including as
source documents)
- class can be overridden by external stylesheets, style cannot.
> This is different in the OOo where styles are used
> consistently throughout the document.
> In the Excel plugin it's basically a one-time use.
You know you may like to consider an alternative support for MS Office
files. It is, IMHO, a better solution to the whole MS Office document
problem. One that does not require the user to save in a different
format and does not require Forrest to maintain two input plugins.
OOo can be run as a headless server. If we create a generator that uses
OOo to convert from the MS formats to OOo then we only need to maintain
the OOo plugin and an MS conversion plugin (and any other OOo supported
formats). This will give us full support of all the MS office formats we
support currently support in the OOo plugin (currently not Excel/Calc
I'm afraid, that's why I never said anything sooner).
If you are interested we have some code that does this in another
project, it just needs packaging as a generator (requires Java skills
though). Start another thread if you'd like to have a go.
Ross
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Thorsten Scherler <th...@apache.org>.
On Tue, 2005-03-01 at 16:40 +0100, Johannes Schaefer wrote:
> > Then I would add this to fileSpecific.ft (ft = forrest template) add it
> > to an aggregation and match it in the xsl.
> >
> > In the document I would recommend to add an attribute <td
> > ft="color_ff0000"/> that will be matched in the xsl.
>
> For me it would be sufficient to have @class. No new
> attribute @ft needed. The question is, how and where
> can I define the classes? They need to make it into
> CSS-classes at the skinning stage (like Excel-CSS).
>
Ok, what is the problem with this?
> I still cannot see a big difference between a
> class=" background_color__ff0000 "
> and a style="{background-color=#ff0000;}"
>
> Both look to me like style information ;-)
>
You are right I thought it should not be a @class. Sorry for the
confusion.
> This is different in the OOo where styles are used
> consistently throughout the document.
> In the Excel plugin it's basically a one-time use.
>
Even if it is one time only one can use it again. You never know. ;-)
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Johannes Schaefer <jo...@uidesign.de>.
Thorsten Scherler wrote:
> On Thu, 2005-02-24 at 10:31 +0000, Ross Gardler wrote:
>
>>Johannes Schaefer wrote:
>>
>>
>>>With what is proposed now would I have to define a
>>>lot of classes like class="color_ff00ff" and define
>>>these classes in the file-specific config?
>>
>>Take a look at the OOo plugin. It does exactly this with a similar file
>>format, although it places the style stiff in the xdoc so this is only a
>>partial solution, but at least it uses classes. Perhaps you can try and
>>replicate for the Excel sheet to see if it works. Here's a where to
>>start looking:
>>
>>In the root template we have
>>
>> <header>
>> <title>
>> ....
>> </title>
>> <xsl:call-template name="style"/>
>> </header>
>>
>>The style template looks like this:
>>
>> <xsl:template name="style">
>> <style>
>> <xsl:apply-templates select="//office:styles/style:style"/>
>> <xsl:apply-templates select="//office:automatic-styles/style:style"/>
>> </style>
>> </xsl:template>
>>
>>The rest of the templates you can easily trace from here. We match all
>>the style information that we want to allow through to the skinning
>>stage, therefore it would be possible to configure which style
>>information we allow and which we disallow on a per document basis.
In the OOo plugin the style information is available
*before* writing the output. In the Excel plugin the cell
content determins the style (i.e. color) of it. I would have
to do a pre-processing step to create all the classes
(styles) and put them into the header
(anybody to suggest how?).
But this is not where the discussion is heading ... the
style information should be neither in-line nor in-header.
>>With this RT this style information would be extracted with the request
>>for the plugin config stuff rather than embedded in head.
If it was to write a separate file (like a template), this
could be done I think (again: how?).
>>Can this work for Excel sheets?
>>
>>
>>>Or would I need to extend the DTD to validate this
>>>single file and provide an XSL fragment (like extra-XSL)
>>>to translate it?
>>
>>No, we do not want style information in our intermediate format so no
>>extending the DTD.
>>
>
>
> The problem that I see is that if you have a table with many colored
> fields and all have different colors that can be pretty soon overkill. I
> understand that the intermediate format should be clean of style
> information but I reckon it will be pretty hard to achieve.
Right, putting each color into a class/ft could explode
the style section.
We now have about 25 basic colors but I don't know what
others will come up with (or other projects).
>
> Now to the promised example, I would place the style information into a
> forrest:view like:
>
> ...
> <forrest:hook name="color_ff0000">
> <css>
> <background-color value="#ff0000"/>
> </css>
> </forrest:hook>
> ...
>
> Then I would add this to fileSpecific.ft (ft = forrest template) add it
> to an aggregation and match it in the xsl.
>
> In the document I would recommend to add an attribute <td
> ft="color_ff0000"/> that will be matched in the xsl.
For me it would be sufficient to have @class. No new
attribute @ft needed. The question is, how and where
can I define the classes? They need to make it into
CSS-classes at the skinning stage (like Excel-CSS).
I still cannot see a big difference between a
class=" background_color__ff0000 "
and a style="{background-color=#ff0000;}"
Both look to me like style information ;-)
This is different in the OOo where styles are used
consistently throughout the document.
In the Excel plugin it's basically a one-time use.
Just another bit ;-)
Johannes
>
> The whole thing do not have much to do with fbits. I am just using the
> forrest:views as config file format for the fbits.
>
> fbits are capsuled code snippets that can be called by a forrest:view.
> The fbit plugin has a method "get.fbits.*" (in form of an URL) which
> will return the snippets. * has to be replaced by the name of the fbit.
>
> The only problem that I am facing and that is why I do not really get to
> the point of releasing it is that I am facing the problem of how to
> resolve the variables of the snippets before I parse them to the code.
>
> e.g. <img class="skin" src="{$skin-img-dir}/poddoc.png" alt="POD -
> icon" />.
>
> I will have to return to work, but fell free to ask question and suggest
> alternatives.
>
>
>>>Just my part of RT ;-)
>>
>
> ...and my. ;-)
>
>
>>I'm glad you spoke up, it is your post that prompted me to write this RT
>>it has been knocking around on my To Do list for some time. Now there
>>are three of us with a strong use case (Thorsten is the third) it should
>>be easier to discover a suitable solution.
>>
>
>
> yeah I will hope as much as I can ATM.
>
>
>>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
Besuchen Sie uns auf der Hannover Messe 11.-15. April 2005
Halle 2, Stand C14 auf dem MMI Gemeinschaftsstand
www.uidesign.de/hmi2005
Nächstes TAE-Seminar zu User Interface Design
Ostfildern-Nellingen, 07.-08. April 2005
www.tae.de TAE-Veranstaltung Nr. 31189
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-03-03 at 21:36 +0000, Ross Gardler wrote:
> Thorsten Scherler wrote:
> > On Tue, 2005-03-01 at 15:59 +0000, Ross Gardler wrote:
> >
> >>Thorsten Scherler wrote:
>
> I'm only going to reply briefly to most of your points. But I will be
> brief (well brief by my standards ;-)) because of the conclusion I come
> to. I recommend reading to the end before replying as you may find it
> saves you time (I sometimes reply as I read).
:)
I like your style ;-)
I will wait with my answer after the weekend, but just some things:
>Well my proposal is replacing skinconf and moving all the relevant
parts
> to a plugin specific configuration. Again, I'm having difficulty
> understanding how this is different from your proposal (other than
> document syntax).
I see it on a per document basis not only on a plugin basis.
> OK, I see your point. I am still lost here since the position of the
> content does not affect the content. This is still presentation detail
> and therefore not part of the fbits.
You are right, like I said in [RT] forrest:templates practical
experience "FURTHER REMARK: In xhtml the differents between nuggets and
fbits is not
really practical, in INX it is. In the fbits plugin (that we should
rename to 'contracts') I am focussing for now just on html and I would
rather call nuggets and fbits 'contracts' then trying to seperate them.
This is because the processing for both are not different."
>position of the
> content does not affect the content
-> yes, that is right but you can want to influence the content itself
(e.g. different rssFeed for different site, ...)
> <forrest:nugget name="print-link" class="formatButton">
Really I like it, that would be the way to go.
> > That would solve another thing that I do not like on our current
skinconf. The color tags are not self explaining.
> > I would like them in the element that they are changing.
>
> IS this worth the trade-off of an unfamiliar syntax for CSS designers
> and reduced reuse?
hmm, I thought about something like:
<forrest:nugget name="menu" class="menu">
<color value="#F7F7F7" link="#000000" vlink="#000000" hlink="#000000"/>
</forrest:nugget>
All other points I will answer hopefully after the weekend.
salu2
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Tue, 2005-03-01 at 15:59 +0000, Ross Gardler wrote:
>
>>Thorsten Scherler wrote:
I'm only going to reply briefly to most of your points. But I will be
brief (well brief by my standards ;-)) because of the conclusion I come
to. I recommend reading to the end before replying as you may find it
saves you time (I sometimes reply as I read).
> I see the skinconf.xml problematic because there is not a common
> structure.
Agreed.
> Your solution as well is not abstract enough IMO:
>
> <org.apache.forrest.plugin.PDF-output>
> <disable-print-link>true</disable-print-link>
> <disable-pdf-link>false</disable-pdf-link>
> <extra-css>
> <background-color value="#ff0000"/>
> </extra-css>
> </org.apache.forrest.plugin.PDF-output>
Yes, I see your point. *If* we were to go this way we would want
something like (note the *if*, it becomes very important further on):
<pluginConf name="org.apache.forrest.plugin.pdf-output">
<param name="disable-print-link" value="true"/>
<css>
...
</css>
</pluginconf>
> When I want to match a new plugin I would need to add a new match in the
> controller. That is the reason why I would like to do it with
> forrest:views, where you have three different kind of main tags (so far)
> which all have certain functions.
No need to add anything to the controller, the directory generator will
provide a reference to all the plugin files.
> The other thing is I would like to
> have a skinconf per page basis, but that not make much sense if I am
> using our current skinconf because it is to mixed up.
Well my proposal is replacing skinconf and moving all the relevant parts
to a plugin specific configuration. Again, I'm having difficulty
understanding how this is different from your proposal (other than
document syntax).
> This discussion was a wake-up call for me to finish the fbits-plugin. I hope I can establish a proof-of-concept
> example with the forrest:views.
This is the point that leads me to my eventual conclusion, read on...
>>>The whole thing do not have much to do with fbits. I am just using the
>>>forrest:views as config file format for the fbits.
>>>
>>>fbits are capsuled code snippets that can be called by a forrest:view.
>>>The fbit plugin has a method "get.fbits.*" (in form of an URL) which
>>>will return the snippets. * has to be replaced by the name of the fbit.
>>
>>Yes, love the idea of fbits. However, fbits are about content in the
>>page whereas this RT is about the subsequent styling of the page. I do
>>not think there is *any* overlap between the two stages of production.
>>
>
>
> ...and this point I see different. I see the problem as follow:
> In a skin there the content is placed on certain positions.
> The skinconf determines whether or not the content should be placed but not where.
> ok that is not 100% true because e.g. pelt have two different position for the breadtrail.
With the existing setup this is true, but we are discussing how this
would change.
> I would like to use the skinconf in a way which will determine the position of elements. I see
> forrest:views as the next generation skinconf. I can place elements and e.g. the fbits will be then
> inserted on this position.
OK, I see your point. I am still lost here since the position of the
content does not affect the content. This is still presentation detail
and therefore not part of the fbits.
> I do not need something like <disable-print-link>true</disable-print-link>
> because if I do not place the <forrest:nugget name="print-link"/> in my view this link will not get rendered.
OK, yes I get this point, this particular value is about content not
about skinning (I remember I made this very point to Nicola in a
previous thread, seems I forgot it ;-) It should not be included in my
skinconf stuff, it certainly belongs in fbits.
> Now where I see an overlap is that I could easily add css to the <forrest:nugget name="print-link"/>
> like (or similar)
> <forrest:nugget name="print-link">
> <css>
> <background-color value="#ff0000"/>
> </css>
> </forrest:nugget>
could != should
If I want to render two copies of a site, one with the print-link and
one without I now have to duplicate all the CSS stuff across both config
files. Similarly, if I want to use the same CSS class in a different
fbit I now have to duplicate across two forrest:nuggets. Would it not be
better to have:
<forrest:nugget name="print-link" class="formatButton">
And then elsewhere, in some other skin config file:
<css>
.formatButton: background-color value="#ff0000
</css>
(or whatever syntax we want)
> That would solve another thing that I do not like on our current skinconf. The color tags are not self explaining.
> I would like them in the element that they are changing.
IS this worth the trade-off of an unfamiliar syntax for CSS designers
and reduced reuse?
> The last thing that I do not like on skinconf that it is 100% forrest specific and I can not reuse it in e.g. lenya.
Agreed, how does your proposal address this?
> Gregor wrote yesterday in the lenya-dev list:
> "the plus side of forrest plugins is that they exist today and address an
> area where lenya is weak today (resource type packages). on the minus
> side, it seems to rely heavily on skinconf.xml (very forrest-specific)
> and seems stuck in the DTD world. (note that i did not take a very
> close
> look, so i might be wrong)"
>
> I have to agree on BOTH minuses. ;-)
I would also agree, the first point is what we are discussing here, so
that is being addressed and the second is addressed by
http://issues.cocoondev.org/browse/FOR-184 and
http://issues.cocoondev.org/browse/FOR-101 (both scheduled for 0.8)
>>It may make sense to move the style configuration stuff into
>>forrest:views when it is implemented, but I don't think we need to wait
>>for it since I believe such a change will only require a few changes to
>>the skining pipelines and stylesheets.
>>
>>Is there more to it than that?
>>
>
>
> Yes and no. IMO it will be a major break for skins, because there will be no more. Skins are not flexible.
> I want something that I can change within a minute without touching xsl code. It should be after the KISS motto.
> Keep It Simple and Successful.
Interesting I say Keep it Simple, Stupid, but I guess your version is
more polite :-)) Either way, neither of these approaches requires anyone
to touch XSL. Admittedly, I am not addressing the *layout* issues
(although CSS can do layout too, but that is not my intention since it
is a nightmare with regards cross browser compatability).
> A forrest:view can alter a whole site or only pages.
How? What is forrest:views equivalent of the include/exclude patterns of
my proposal? (read on before taking the time to answer)
> You already did it (kind of). I was trying to reuse a lot of stuff without major changes, but I think that is not wise.
> I will try to hack a solution over the weekend and would be really happy if you (ant others of course) will comment on it.
I do think that our views (I'm including Nicola here) are very similar,
but we have different implementation ideas. At the end of the day the
implementation can be changed if necessary. Since you are hoping to hack
a solution together before me, it would make more sense for you to take
the time working on the solution than replying to my points in this
mail. I provide them only as further food for thought.
I wait with eager anticipation :-))
Ross
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Thorsten Scherler <th...@apache.org>.
On Tue, 2005-03-01 at 15:59 +0000, Ross Gardler wrote:
> Thorsten Scherler wrote:
> >
> > The problem that I see is that if you have a table with many colored
> > fields and all have different colors that can be pretty soon overkill. I
> > understand that the intermediate format should be clean of style
> > information but I reckon it will be pretty hard to achieve.
>
> I disagree, for the use case we have here it is very easy to achieve
> since all the CSS style information is generated by the XSL which
> extracts it from the original source document. All that is required to
> turn the hack solution in the OOo plugin into a solution that produces
> valid XDocs is to create a separate pipeline to create the CSS sheet
> rather than have it created as par of the intermediate XDoc.
>
I am sorry I did not had enough time to really get into the actual
problem. In the Indesign Plugin I am doing a similar thing. I let the
designer create all objects and styles and I just parse the content.
I already have the content separated from the style at this stage. I
only need to match from the user data to the design object. This
matching is configured by forrest:views. forrest:views are just
configuration files for controller and matching engine.
In the end I would like to alter my application in changing
configuration files (CheChe will now laugh ;-) when I meet him I think
all my solutions ended up with a config file).
I see the skinconf.xml problematic because there is not a common
structure. Your solution as well is not abstract enough IMO:
<org.apache.forrest.plugin.PDF-output>
<disable-print-link>true</disable-print-link>
<disable-pdf-link>false</disable-pdf-link>
<extra-css>
<background-color value="#ff0000"/>
</extra-css>
</org.apache.forrest.plugin.PDF-output>
When I want to match a new plugin I would need to add a new match in the
controller. That is the reason why I would like to do it with
forrest:views, where you have three different kind of main tags (so far)
which all have certain functions. The other thing is I would like to
have a skinconf per page basis, but that not make much sense if I am
using our current skinconf because it is to mixed up.
> > Now to the promised example, I would place the style information into a
> > forrest:view like:
> >
> > ...
> > <forrest:hook name="color_ff0000">
> > <css>
> > <background-color value="#ff0000"/>
> > </css>
> > </forrest:hook>
> > ...
> >
> > Then I would add this to fileSpecific.ft (ft = forrest template) add it
> > to an aggregation and match it in the xsl.
> >
> > In the document I would recommend to add an attribute <td
> > ft="color_ff0000"/> that will be matched in the xsl.
>
> How is this any different from <td class="color_ff000"> as I was proposing?
>
It is not I thought it should not be done with @class. Sorry for the noise.
>
> I see a different attribute name, but not a different design. Wouldn't
> it be better to stay consistent with XHTML2 since that will be our
> intermediate format?
>
> The only other difference I see is where the CSS classes are defined. In
> your proposal it is in a forrest:views definition file. In mine it is in
> some other file (skinconf.xml, pdf-output.xml or whatever):
>
> <org.apache.forrest.plugin.PDF-output>
> <disable-print-link>true</disable-print-link>
> <disable-pdf-link>false</disable-pdf-link>
> <extra-css>
> <background-color value="#ff0000"/>
> </extra-css>
> </org.apache.forrest.plugin.PDF-output>
>
> I feel I must be missing something important about forrest:views ...
>
This discussion was a wake-up call for me to finish the fbits-plugin. I hope I can establish a proof-of-concept
example with the forrest:views.
>
> > The whole thing do not have much to do with fbits. I am just using the
> > forrest:views as config file format for the fbits.
> >
> > fbits are capsuled code snippets that can be called by a forrest:view.
> > The fbit plugin has a method "get.fbits.*" (in form of an URL) which
> > will return the snippets. * has to be replaced by the name of the fbit.
>
> Yes, love the idea of fbits. However, fbits are about content in the
> page whereas this RT is about the subsequent styling of the page. I do
> not think there is *any* overlap between the two stages of production.
>
...and this point I see different. I see the problem as follow:
In a skin there the content is placed on certain positions.
The skinconf determines whether or not the content should be placed but not where.
ok that is not 100% true because e.g. pelt have two different position for the breadtrail.
I would like to use the skinconf in a way which will determine the position of elements. I see
forrest:views as the next generation skinconf. I can place elements and e.g. the fbits will be then
inserted on this position. I do not need something like <disable-print-link>true</disable-print-link>
because if I do not place the <forrest:nugget name="print-link"/> in my view this link will not get rendered.
Now where I see an overlap is that I could easily add css to the <forrest:nugget name="print-link"/>
like (or similar)
<forrest:nugget name="print-link">
<css>
<background-color value="#ff0000"/>
</css>
</forrest:nugget>
That would solve another thing that I do not like on our current skinconf. The color tags are not self explaining.
I would like them in the element that they are changing.
The last thing that I do not like on skinconf that it is 100% forrest specific and I can not reuse it in e.g. lenya.
Gregor wrote yesterday in the lenya-dev list:
"the plus side of forrest plugins is that they exist today and address an
area where lenya is weak today (resource type packages). on the minus
side, it seems to rely heavily on skinconf.xml (very forrest-specific)
and seems stuck in the DTD world. (note that i did not take a very
close
look, so i might be wrong)"
I have to agree on BOTH minuses. ;-)
>
> It may make sense to move the style configuration stuff into
> forrest:views when it is implemented, but I don't think we need to wait
> for it since I believe such a change will only require a few changes to
> the skining pipelines and stylesheets.
>
> Is there more to it than that?
>
Yes and no. IMO it will be a major break for skins, because there will be no more. Skins are not flexible.
I want something that I can change within a minute without touching xsl code. It should be after the KISS motto.
Keep It Simple and Successful.
A forrest:view can alter a whole site or only pages.
>
> > The only problem that I am facing and that is why I do not really get to
> > the point of releasing it is that I am facing the problem of how to
> > resolve the variables of the snippets before I parse them to the code.
> >
> > e.g. <img class="skin" src="{$skin-img-dir}/poddoc.png" alt="POD -
> > icon" />.
> >
> > I will have to return to work, but fell free to ask question and suggest
> > alternatives.
>
> Sorry, I don't understand your problem, where is the code snippet from,
> is it in the intermediate docs, the XSL. I'd be happy to try and help
> solve this problem but you'll need to explain it more completely
> (probably in a different thread).
>
You already did it (kind of). I was trying to reuse a lot of stuff without major changes, but I think that is not wise.
I will try to hack a solution over the weekend and would be really happy if you (ant others of course) will comment on it.
>
> Ross
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Thu, 2005-02-24 at 10:31 +0000, Ross Gardler wrote:
>
>>Johannes Schaefer wrote:
>>
>>
>>>With what is proposed now would I have to define a
>>>lot of classes like class="color_ff00ff" and define
>>>these classes in the file-specific config?
>>
>>Take a look at the OOo plugin. It does exactly this with a similar file
>>format, although it places the style stiff in the xdoc so this is only a
>>partial solution, but at least it uses classes. Perhaps you can try and
>>replicate for the Excel sheet to see if it works. Here's a where to
>>start looking:
>>
>>In the root template we have
>>
>> <header>
>> <title>
>> ....
>> </title>
>> <xsl:call-template name="style"/>
>> </header>
>>
>>The style template looks like this:
>>
>> <xsl:template name="style">
>> <style>
>> <xsl:apply-templates select="//office:styles/style:style"/>
>> <xsl:apply-templates select="//office:automatic-styles/style:style"/>
>> </style>
>> </xsl:template>
>>
>>The rest of the templates you can easily trace from here. We match all
>>the style information that we want to allow through to the skinning
>>stage, therefore it would be possible to configure which style
>>information we allow and which we disallow on a per document basis.
>>
>>With this RT this style information would be extracted with the request
>>for the plugin config stuff rather than embedded in head.
>>
>>Can this work for Excel sheets?
>>
>>
>>>Or would I need to extend the DTD to validate this
>>>single file and provide an XSL fragment (like extra-XSL)
>>>to translate it?
>>
>>No, we do not want style information in our intermediate format so no
>>extending the DTD.
>>
>
>
> The problem that I see is that if you have a table with many colored
> fields and all have different colors that can be pretty soon overkill. I
> understand that the intermediate format should be clean of style
> information but I reckon it will be pretty hard to achieve.
I disagree, for the use case we have here it is very easy to achieve
since all the CSS style information is generated by the XSL which
extracts it from the original source document. All that is required to
turn the hack solution in the OOo plugin into a solution that produces
valid XDocs is to create a separate pipeline to create the CSS sheet
rather than have it created as par of the intermediate XDoc.
> Now to the promised example, I would place the style information into a
> forrest:view like:
>
> ...
> <forrest:hook name="color_ff0000">
> <css>
> <background-color value="#ff0000"/>
> </css>
> </forrest:hook>
> ...
>
> Then I would add this to fileSpecific.ft (ft = forrest template) add it
> to an aggregation and match it in the xsl.
>
> In the document I would recommend to add an attribute <td
> ft="color_ff0000"/> that will be matched in the xsl.
How is this any different from <td class="color_ff000"> as I was proposing?
I see a different attribute name, but not a different design. Wouldn't
it be better to stay consistent with XHTML2 since that will be our
intermediate format?
The only other difference I see is where the CSS classes are defined. In
your proposal it is in a forrest:views definition file. In mine it is in
some other file (skinconf.xml, pdf-output.xml or whatever):
<org.apache.forrest.plugin.PDF-output>
<disable-print-link>true</disable-print-link>
<disable-pdf-link>false</disable-pdf-link>
<extra-css>
<background-color value="#ff0000"/>
</extra-css>
</org.apache.forrest.plugin.PDF-output>
I feel I must be missing something important about forrest:views ...
> The whole thing do not have much to do with fbits. I am just using the
> forrest:views as config file format for the fbits.
>
> fbits are capsuled code snippets that can be called by a forrest:view.
> The fbit plugin has a method "get.fbits.*" (in form of an URL) which
> will return the snippets. * has to be replaced by the name of the fbit.
Yes, love the idea of fbits. However, fbits are about content in the
page whereas this RT is about the subsequent styling of the page. I do
not think there is *any* overlap between the two stages of production.
It may make sense to move the style configuration stuff into
forrest:views when it is implemented, but I don't think we need to wait
for it since I believe such a change will only require a few changes to
the skining pipelines and stylesheets.
Is there more to it than that?
> The only problem that I am facing and that is why I do not really get to
> the point of releasing it is that I am facing the problem of how to
> resolve the variables of the snippets before I parse them to the code.
>
> e.g. <img class="skin" src="{$skin-img-dir}/poddoc.png" alt="POD -
> icon" />.
>
> I will have to return to work, but fell free to ask question and suggest
> alternatives.
Sorry, I don't understand your problem, where is the code snippet from,
is it in the intermediate docs, the XSL. I'd be happy to try and help
solve this problem but you'll need to explain it more completely
(probably in a different thread).
Ross
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Thorsten Scherler <th...@apache.org>.
On Thu, 2005-02-24 at 10:31 +0000, Ross Gardler wrote:
> Johannes Schaefer wrote:
>
> > With what is proposed now would I have to define a
> > lot of classes like class="color_ff00ff" and define
> > these classes in the file-specific config?
>
> Take a look at the OOo plugin. It does exactly this with a similar file
> format, although it places the style stiff in the xdoc so this is only a
> partial solution, but at least it uses classes. Perhaps you can try and
> replicate for the Excel sheet to see if it works. Here's a where to
> start looking:
>
> In the root template we have
>
> <header>
> <title>
> ....
> </title>
> <xsl:call-template name="style"/>
> </header>
>
> The style template looks like this:
>
> <xsl:template name="style">
> <style>
> <xsl:apply-templates select="//office:styles/style:style"/>
> <xsl:apply-templates select="//office:automatic-styles/style:style"/>
> </style>
> </xsl:template>
>
> The rest of the templates you can easily trace from here. We match all
> the style information that we want to allow through to the skinning
> stage, therefore it would be possible to configure which style
> information we allow and which we disallow on a per document basis.
>
> With this RT this style information would be extracted with the request
> for the plugin config stuff rather than embedded in head.
>
> Can this work for Excel sheets?
>
> > Or would I need to extend the DTD to validate this
> > single file and provide an XSL fragment (like extra-XSL)
> > to translate it?
>
> No, we do not want style information in our intermediate format so no
> extending the DTD.
>
The problem that I see is that if you have a table with many colored
fields and all have different colors that can be pretty soon overkill. I
understand that the intermediate format should be clean of style
information but I reckon it will be pretty hard to achieve.
Now to the promised example, I would place the style information into a
forrest:view like:
...
<forrest:hook name="color_ff0000">
<css>
<background-color value="#ff0000"/>
</css>
</forrest:hook>
...
Then I would add this to fileSpecific.ft (ft = forrest template) add it
to an aggregation and match it in the xsl.
In the document I would recommend to add an attribute <td
ft="color_ff0000"/> that will be matched in the xsl.
The whole thing do not have much to do with fbits. I am just using the
forrest:views as config file format for the fbits.
fbits are capsuled code snippets that can be called by a forrest:view.
The fbit plugin has a method "get.fbits.*" (in form of an URL) which
will return the snippets. * has to be replaced by the name of the fbit.
The only problem that I am facing and that is why I do not really get to
the point of releasing it is that I am facing the problem of how to
resolve the variables of the snippets before I parse them to the code.
e.g. <img class="skin" src="{$skin-img-dir}/poddoc.png" alt="POD -
icon" />.
I will have to return to work, but fell free to ask question and suggest
alternatives.
> > Just my part of RT ;-)
>
...and my. ;-)
> I'm glad you spoke up, it is your post that prompted me to write this RT
> it has been knocking around on my To Do list for some time. Now there
> are three of us with a strong use case (Thorsten is the third) it should
> be easier to discover a suitable solution.
>
yeah I will hope as much as I can ATM.
> Ross
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Ross Gardler <rg...@apache.org>.
Johannes Schaefer wrote:
> With what is proposed now would I have to define a
> lot of classes like class="color_ff00ff" and define
> these classes in the file-specific config?
Take a look at the OOo plugin. It does exactly this with a similar file
format, although it places the style stiff in the xdoc so this is only a
partial solution, but at least it uses classes. Perhaps you can try and
replicate for the Excel sheet to see if it works. Here's a where to
start looking:
In the root template we have
<header>
<title>
....
</title>
<xsl:call-template name="style"/>
</header>
The style template looks like this:
<xsl:template name="style">
<style>
<xsl:apply-templates select="//office:styles/style:style"/>
<xsl:apply-templates select="//office:automatic-styles/style:style"/>
</style>
</xsl:template>
The rest of the templates you can easily trace from here. We match all
the style information that we want to allow through to the skinning
stage, therefore it would be possible to configure which style
information we allow and which we disallow on a per document basis.
With this RT this style information would be extracted with the request
for the plugin config stuff rather than embedded in head.
Can this work for Excel sheets?
> Or would I need to extend the DTD to validate this
> single file and provide an XSL fragment (like extra-XSL)
> to translate it?
No, we do not want style information in our intermediate format so no
extending the DTD.
> Just my part of RT ;-)
I'm glad you spoke up, it is your post that prompted me to write this RT
it has been knocking around on my To Do list for some time. Now there
are three of us with a strong use case (Thorsten is the third) it should
be easier to discover a suitable solution.
Ross
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Johannes Schaefer <jo...@uidesign.de>.
Just let me add my small bit.
I read the discussion and think it goes into
the right direction and that you'll come up
with sth great in the end ...
But I can't see how it fits the needs of the hack
in the Excel plugin, which is a rather special case:
We have color tables to define all the colors that
might be used in a GUI. To make the table with a lot
of hex-triplets and RGB values more useful and
appealing I set the background-color for each cell
that contains a color value in the corresponding color.
There's an example in the plugin's docs.
With what is proposed now would I have to define a
lot of classes like class="color_ff00ff" and define
these classes in the file-specific config?
It would look like Excel saving XML:
<Style ss:ID="s23">
<Font ss:FontName="Courier New" x:Family="Modern"/>
<Interior/>
</Style>
...
<Cell ss:StyleID="s23">
<Data ss:Type="Number">12</Data>
</Cell>
Or would I need to extend the DTD to validate this
single file and provide an XSL fragment (like extra-XSL)
to translate it?
Just my part of RT ;-)
Johannes
Ross Gardler wrote:
> Thorsten Scherler wrote:
>
>> On Wed, 2005-02-23 at 12:00 +0000, Ross Gardler wrote:
>>
>
> <snip/>
>
>> I am doing this with forrest:views. I think that is the way for a
>> on-page basis.
>>
>
> <snip/>
>
>>> fbits
>>> -----
>>>
>>> How does this contribute to/intefere with work on fbits?
>>>
>>
>>
>> fbits are based on forrest:views. Anyway the RT gave me some good ideas
>> for the fbits.
>>
>>> alternatives
>>> ------------
>>>
>>
>>
>> forrest:views
>>
>
> OK, I suspected this would be the case. Care to expand? I'm particularly
> interested in where the config files are placed and how Forrest
> manipulates them.
>
> Also how does forrest:views + fbits address the meta-data issues raised
> in response to Nicola's RT?
>
> Unfortunately, I don't "get" what you are doing with fbits yet. I
> understand the what you are trying to achieve and I like the sound of
> it, but I have to admit to being lost as to the "how". So I seem to have
> come up with my own "how".
>
> I've been waiting for fbits to develop a little so that I could
> understand from the code, but I am getting closer to actually needing a
> solution for this (a few months of yet, but I like to plan in advance).
> Either you make me understand the "how" of fbits and I contribute to
> that or I'll have to get on with implementing something along the lines
> of this RT (and Nicola's). (this sounds a little like a threat, of
> course it isn't it's an attempt to avoid duplication of work. As I said
> I won't actually be implementing this for a month or two anyway so we
> have plenty of time to work out which way to go).
>
> 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
Besuchen Sie uns auf der Hannover Messe 11.-15. April 2005
Halle 2, Stand C14 auf dem MMI Gemeinschaftsstand
www.uidesign.de/hmi2005
Nächstes TAE-Seminar zu User Interface Design
Ostfildern-Nellingen, 07.-08. April 2005
www.tae.de TAE-Veranstaltung Nr. 31189
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Ross Gardler <rg...@apache.org>.
Thorsten Scherler wrote:
> On Wed, 2005-02-23 at 12:00 +0000, Ross Gardler wrote:
>
<snip/>
> I am doing this with forrest:views. I think that is the way for a
> on-page basis.
>
<snip/>
>>fbits
>>-----
>>
>>How does this contribute to/intefere with work on fbits?
>>
>
>
> fbits are based on forrest:views. Anyway the RT gave me some good ideas
> for the fbits.
>
>
>>alternatives
>>------------
>>
>
>
> forrest:views
>
OK, I suspected this would be the case. Care to expand? I'm particularly
interested in where the config files are placed and how Forrest
manipulates them.
Also how does forrest:views + fbits address the meta-data issues raised
in response to Nicola's RT?
Unfortunately, I don't "get" what you are doing with fbits yet. I
understand the what you are trying to achieve and I like the sound of
it, but I have to admit to being lost as to the "how". So I seem to have
come up with my own "how".
I've been waiting for fbits to develop a little so that I could
understand from the code, but I am getting closer to actually needing a
solution for this (a few months of yet, but I like to plan in advance).
Either you make me understand the "how" of fbits and I contribute to
that or I'll have to get on with implementing something along the lines
of this RT (and Nicola's). (this sounds a little like a threat, of
course it isn't it's an attempt to avoid duplication of work. As I said
I won't actually be implementing this for a month or two anyway so we
have plenty of time to work out which way to go).
Ross
Re: [RT] Per document skinconf (was Re: coloring table cells [from
the user list])
Posted by Thorsten Scherler <th...@apache.org>.
On Wed, 2005-02-23 at 12:00 +0000, Ross Gardler wrote:
> Johannes Schaefer wrote:
> > Is there a valid way to specify a specific style for a
> > single element in document-v1.3 (or v2.0)?
> >
> > The only way I see is to use a class attribute but this is
> > not possible because each and every cell may have a
> > different bg-color.
>
> [Note what I am thinking about here is quite a bit of work, I'd suggest
> that if anyone tackles it they should do so in a branch so that there is
> no danger of it messing up the 0.7 release.]
>
> The Problem
> ===========
>
> In Forrest we have always insisted that the source document should not
> contain any style information. However with our increasing support of
> other formats we are losing control of this in some cases. Already there
> are two solutions in two different plugins.
>
> I really don't like the idea of embedding style information into the
> style attribute of the Intermediate format as is the current solution
> for the Excel plugin. Similarly I do not like the solution I hacked for
> the OpenOffice.org plugin (en embedded style element in the header).
>
> I think we need to devise a solution for use in Input plugins that will
> be the "official" way for Forrest to deal with embedded style
> information. Note that I am *not* suggesting we allow style information
> into documents written specifically for Forrest, just that we handle
> documents with embedded style information in a consistent way.
>
> This means that at the intermediate format must allow skin information
> to be extended, but how?
>
> A second, but related problem, is the feature requests we have for per
> page configuration of the skin. Some people want to turn the PDF button
> on or off on a per page basis, others want to change the logo images at
> the top of the page.
>
> fbits are a proposed solution to this. I'm not sure how this RT fits in
> with fbits or if it stomps all over the fbits proposal. That is why this
> is an RT (random thoughts) rather than a proposal. I want to see if it
> all fits together.
>
> Generating skinconf.xml
> =======================
>
> Recently, Bastian Bowe showed us how we can customise skinconfig on a
> per plugin basis
> (http://marc.theaimsgroup.com/?l=forrest-dev&m=110873270020951&w=2). I
> think if we extend this idea a little we could have plugins generate the
> extended config info.
>
> Consider this match (hint: the map:generate of the current sitemap has
> been replaced by map:aggregate):
>
> <map:match pattern="**body-*.html">
> <map:aggregate element="page">
> <map:part src="cocoon:/{1}{2}.xml"/>
> <map:part src="cocoon:/{1}pageconf-{2}.xml"/>
> </map:generate>
> <map:transform type="idgen"/>
> <map:transform type="xinclude"/>
> <map:transform type="linkrewriter"
> src="cocoon:/{1}linkmap-{2}.html"/>
> <map:transform
> src="resources/stylesheets/declare-broken-site-links.xsl" />
> <map:call resource="skinit">
> <map:parameter name="type" value="document2html"/>
> <map:parameter name="path" value="{1}{2}.html"/>
> <map:parameter name="notoc" value="false"/>
> </map:call>
> </map:match>
>
> here we are adding configuration info for individual pages
> (cocoon:/{1}pageconf-{2}.xml). Therefore it can do things like add CSS
> styles or change some default behaviour, such as whether the PDF button
> should be displayed or change the logo's on individual pages etc.
> skinconf.xml now becomes the specification of the default behaviour.
>
> In the event of a conflict between different plugins we would give
> precedence to the one that appears first in the list of plugins in
> forrest.properties (this is reflected in the order that the conf
> elements appear). This conflict resolution may turn out to be too
> simplistic, but I am sure it will work in the short to medium term. A
> longer term solution can be found later.
>
I am doing this with forrest:views. I think that is the way for a
on-page basis.
> Generating page config
> ----------------------
>
> Each plugin must be able to contribute to the page config, so we will
> need a new matcher that will aggregate all the pageconf contributions
> from the individual plugins. I don't think Cocoon is able to do this and
> so this match will have to be created in the same way that the relevant
> plugin mounts are created (see targets/plugins.xml). The pageconf match
> will appear in the generated internal.xmap file and will look like this:
>
> <map:match pattern="**pageconf-*.xml">
> <map:aggregate element="pageconf">
> <map:part src="cocoon:/PLUGINNAME_1-pageconf-{1}{2}.xml/>
> <map:part src="cocoon:/PLUGINNAME_2-pageconf-{1}{2}.xml/>
> <map:part src="cocoon:/PLUGINNAME_3-pageconf-{1}{2}.xml/>
> ...
> </map:aggregate>
> <map:serialize type"xml"/>
> </map:match>
>
> Within each plugin sitemap we will find:
>
> <map:match pattern="PLUGINNAME-pageconf-*.xml">
>
> Since we are using a cocoon match to create the config we can use really
> simple techniques for configuration (like a plugin.properties file) or
> we can do really clever stuff like the include/exclude patterns for
> enabling specific page features such as PDF buttons (as discussed on dev
> list).
>
> The output of each cocoon:/PLUGINAME-pageconf-*.xml would be something like:
>
> <org.apache.forrest.plugin.excel>
> <disable-print-link>true</disable-print-link>
> <disable-pdf-link>false</disable-pdf-link>
> <extra-css>
> ...
> </extra-css>
> </org.apache.forrest.plugin.PDF-output>
>
> In most cases (i.e. all but extra-css) the values in here override those
> in skinconf.xml and other pageconf elements. The extra-css values are
> added to those in skinconf.xml and elsewhere in pageconf.
>
> Using page config
> -----------------
>
> To use this information we simply need to modify any code that works
> with skinconfig.xml. We would first look for a value in the pageconf
> element, if it does not exist we would use the one in skinconf.xml instead.
>
> Issues to Consider
> ==================
>
> Performance
> ----------
>
> There is potentially a large impact on performance here as we are
> considerably increasing the number of matches for each page. This is
> mitigated to some extent by only using the plugins applicable to this
> site, but nevertheless the impact could be quite large. Of course,
> Cocoon's caching will help considerably in most cases.
>
> fbits
> -----
>
> How does this contribute to/intefere with work on fbits?
>
fbits are based on forrest:views. Anyway the RT gave me some good ideas
for the fbits.
> alternatives
> ------------
>
forrest:views
> ????
>
> unforseen problems
> ------------------
>
> ?????
>
>
> Ross
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)