Tim Williams a écrit :
On 12/2/05, Ross Gardler <[EMAIL PROTECTED]> wrote:
Tim Williams wrote:
On 12/2/05, Thorsten Scherler <[EMAIL PROTECTED]> wrote:
Hi all,
I've unfortunately been too busy to properly keep up with all of your
progress so this may not be worth much.
lately we proposed a new attribute @element for the forrest:hook
element. Now it is possible to have any markup as hook.
I didn't catch this but now that I understand it, it makes me think
that we might be letting our templating language make too many
assumptions about the output (e.g. that it is markup). Same thing for
the new hooksXPath attribute. How are these supportive of non-markup
output formats like text/rtf?
This is markup to create an internal representation of the document for
later output. RTF is generated from XSL/FO (markup) and text is from our
internal document format (markup).
We are an XML publishing framework, it is fair to assume everything we
publish will, at some point in the lifecycle, be markup ;-)
From your comments, I gather I'm missing something. I think of these
*.fv as output not internal format. They are manipulating the
internal format to produce a certain output, thus the need for the
@type on view element. Of course, it's fair to assume the internal
will be markup but why have a type attribute on a view if it cannot be
anything other than markup? From my understanding some of these
markup-related attributes (e.g. hooksXPath, element) don't make sense
to me when @type != html/xml.
Think of a structured document :
hooksXPath can have values such as : document/header, document/footer,
document/body, document/body/addresses, document/footer/notes...
- would it not be sufficient to have forrest:view and forrest:contract?
If you had two contracts that needed the same output style how could
you do it without having a hook to contain them?
In use, a single contract provides a single output style. There may be
multiple implementations of the contract for different outputs but only
one is used at any one time.
That is, if you want two different outpus, you will have two different
views, one for each output.
I mean two different contracts that were to be bound together on the
output (e.g. nav-section and search-input). For output purposes they
need to be "contained" together somehow -- accomplished through a
hook->div right now (or at least it was).
Correct, but the question of thorsten was - I think - do we need to have :
<forrest:hook name="MyOwnHook">
Or simply :
<MyOwnHook>
...
</MyOwnHook>
By the way, I have made a test on my fichier.fv (replace all my
forrest:hook tags by the direct tag - just to see what the file looks like)
And I have no conclusion :-P .
I mean, with the direct tags inclusion, the file is smaller but in fact,
I am not sure it is easier to read...
Salutations,
Cyriaque,
I will later post my views before I hear some opinions.
I reckon I think the hooks are needed, but that's based on a dated
understanding of this stuff.
I'm on the fence, I want to see more discussion and see some actually
implementations of this stuff. So far all I can see is a load of code
with no real example usage (sure we have the v2 seed, but it is not
exactly comprehensive). I'd like to see some real use of views in
whiteboard, this will help us address these kinds of issues.
I've made a start with the Notes plugin and we should convert the voice
plugin to views. The resume plugin and the ECS plugin both have version
1 views stuff, they need bringinng up to date with views 2.
Ross
--tim
