Just another use case and some more RTs.
We are writing styleguides with forrest.
Application developers need less information than
component developers, so we are offering different
versions for both. Now we do this with two separate
project sitemaps to create the (static) output.
We would happily adopt some "live" filtering.
In our case it's more like we do know what info is not
needed for a specific user group and so we drop it in a
first transformation step (i.e. from a specialized DTD to
DocBook). Thus the filtering applies only to specialized
parts of the document (e.g. matches **-ABC.html) and the
rest is handled normally. There is no special markup
(like class="dirCut"/"actorCut").
Ideally the reader can adjust the filtering, like: give
me all information about version A; give me my information
about versions A, B, D. The information about this is
in the specialized markup, so, theoretically it can be
done.
Our "writers" don't care about filtering, they provide
the full information anyway (each one his/her bit).
It's the "admin" or "publisher" who creates the published
version(s).
We would like to do 'forrest run' and access the
versions using the same instance, e.g. like
http://localhost:8888/app-dev/ and
http://localhost:8888/core-dev/
(see also: http://issues.cocoondev.org/browse/FOR-490)
I'd agree with Ross, that this is not a output/skinning
step, but an internal one. For us it would be sooner than
xdoc->skin because it'll be hard to preserve all the
semantics up to the xdoc-format.
Cheers
Johannes
Ferdinand Soethe schrieb:
Two quick responses since I'm still working on the apachecon
presentation:
- I'm happy for this to be a part of views and I hope after apachecon
I'll know how to use them for this purpose.
- I agree that the filter could and perhaps should be configured as
part of the configuration.
...and content writer != admin (site.xml)
- I do not agree that editing site.xml is admin work as Thorsten
seems to suggest since it is the only way a user can make Forrest
show his page.
- And since I (with the content writer hat) usually make the decisions about
which file to show in which menu and what filter should be applied
to it (e.g. show the directors version of Shakespeare in my 'Directors
resources' menu while the full version is in the 'Popular
Dramas') I (user) need a way simply apply a filter to a given
resource.
To determine which filters to apply to which resources (by the list of
patterns in the plugin config that Ross suggested) does not seem an
ideal solution to me as it requires an understanding of patterns
that users don't usually have and also makes it much harder to see
what will actually the outcome of a certain site.xml (because you
have to also look at the filter patterns in the plugin (and apply
that knowledge to site) to know what will actually show.
Very difficult and not easy to maintain.
I understand the objective not to extend site-grammar for every new
plugin (and share it), but I'd raise the question if it wouldn't be a
good idea to consider it at least for some basic operations like
filtering, pdf-aggregation and ...
And if that is not agreeable, to find some other way of keeping the
selection of a given filter closely with the site-element.
--
Ferdinand Soethe
--
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
