forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Schaefer <johannes.schae...@uidesign.de>
Subject Re: New Plugin: Filtering output
Date Mon, 23 May 2005 07:30:44 GMT
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

Mime
View raw message