At 8:27 am +0100 7/3/02, Michael Homeijer wrote:
>Hi Sam,
>
>I think I asked the same question in the discussion about "Pipe-aware
>Selectors". Maybe you can add your input and join the discussion?
Sorry to seem mysterious about this .... I just don't have all the ideas
working yet .....
I hope very soon to commit a new version of <slash-edit/> that could
provide clues to a different approach to this proposal. Or to put it
another way, it could provide clues as to how I am thinking, trying to
solve similar problems.
I am moving my application logic out of the sitemap, into XSLT.
I hope this is not considered too lazy .... but here is a snippet from a
conversation I have been having off-list:
(name withheld to protect the innocent ;)
----------------------------- quote -----------------------------
I was experimenting this weekend with new pipelines for <slash-edit/>.
Apart from adding an extra param into the url, so that different
"sub-editors" can be used "get(sub-editor)/the/file/to/edit.xml"
get(page)/the/file/to/edit.xml
--- ---- ----------- --------
| | | |
verb sub-editor dir file
Where sub-editors might handle different ways of editing the same DTD
(whole file, XML broken down into fields etc.), or allow editing different
DTDs, or perform different action (append comment, edit whole document
etc.).
I was also exploring the issue of more "multi-purpose" reactive pipelines,
where tags in the stream are generated (during aggregation) that specify
the job a later XSLT has to perform. Instead of passing (so many)
parameters to the StyleSheet. It is looking interesting!
Nothing working or committed yet .....
(Untested) Sitemap snippet to show my approach:
<map:match pattern="*(*)/**/*">
<map:aggregate element="{1}" label="content">
<map:part src="editor/docs/{2}-editor.xml"/>
<map:part
src="cocoon:{1}-content({2},{3},{4})" element="{2}"/>
</map:aggregate>
<map:transform type="sourcewriter"/>
<map:transform
src="editor/stylesheets/editor-page2html.xsl">
<map:parameter name="target-file" value="{4}"/>
<map:parameter name="target-dir"
value="/{3}/"/>
</map:transform>
<map:serialize type="xhtml"/>
</map:match>
The XML tells 'editor-page2html.xsl' what to do:
<get> - verb (get|put|dir|new|view)
<editor>config stuff</editor>
- shared config
<page>
-
sub-editor to use
<root-of-editable-fragment/>
</page>
</get>
The second line of aggregation is a call to different internal pipelines
that generates xml from the request, a stream, a file, XIndice etc.
depending on the 'verb' and 'sub-editor' as appropriate, and uses an XSLT
pass to turn that XML into a standard document, regardless of how it was
generated.
The 'sourcewriter' transformation step is only used occasionally, ie. when
something 'before' it decides it needs to output a <source:write/> tag
because it has something it would like to write. ie. the 'put' verb.
Your application logic moves out of the sitemap, into XSLT.
----------------------------- /quote -----------------------------
The other thread, that I am trying to work into this, is a "Form Contract"
document. Whereby an XML document specifies all of the information needed
to make and handle a form for editing particular data.
I do not want to go so far as to create a language like XUpdate that will
be interpreted by the XSLT to construct/deconstruct forms, merely a set of
clues used by all components.
This is beginning to happen with XSLT in <slash-edit/> but this contract
file could also be shared by a hypothetical RequestParsingGenerator (what
formfields to turn into what xml?), the Validating Actions (are these
fields valid?), etc. etc. each different component using it's own namespace
within the same file, providing a central repository for all clues about
the form.
Anyway, these ideas are not quite ready for public consumption yet, hence
my tentativeness ...... I could hold off no longer from this public
discussion however ;)
I just hope I have not put you off already, with my shoddy explanation ;)
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<mailto:[EMAIL PROTECTED]> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pager:[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
