Thorsten Scherler wrote:
El mié, 16-11-2005 a las 16:24 +0000, Ross Gardler escribió:
Thorsten Scherler wrote:
El jue, 10-11-2005 a las 16:36 +0100, Thorsten Scherler escribió:
Hi all,
I am working on some java classes that should become the dispatcher
core. While doing it I thought about the usage of contracts. We are now
doing a parallel processing which has influence on the performance.
Introducing jx:import reduced a wee bit the build time and the recent
update of the lm a lot more. Still it is too slow. Doing some process
consulting on v2 we pointed out that the xsl magic is slowing as well
things down. The idea has to be to slim down the processing.
IMO contracts have to work standalone. Meaning that the dispatcher will
call the contract with the given properties and include the *result* and
not raw-data and xsl.
...
[WARNING - these are off the top of my head thoughts with very little
consideration - beware of deep potholes]
...
d) transform hooks into format specific markup
e) transform all above to the final page
The question is how can we make contracts more generic. One way is to
get rid of head|body="true|false". I thought that each contract has to
provide this information from the resulting transformation.
...
How about:
<content xpath="/html/body">
<!-- the HTML generated by the contract -->
</content>
...
Assuming forrest:hook will be transformed to div id="test" the location
would be
xpath="html/body/[EMAIL PROTECTED]'test']"
I call this <content xpath="html/body"/> xpath structure aware, because
it is more a xpath prefix then a fixed location.
Now think you would add
<content xpath="html/head">
<something/>
</content>
That should not be aware of the structure. It should be insert in the
fixed location "html/head" otherwise you would get invalid markup.
To solve this problem I would like to propose to add an attribute
fixedLocation="true|false". So this makes
<content xpath="html/head" fixedLocation="true">
<something/>
</content>
I propose to make the default fixedLocation="false". That means the
content will be injected in the overall structure defined by the
structurer (*.fv), the content is structure aware.
I only have a minor objection, and that is the name of the attribute. It
doesn't convey its meaning to me. How about one of these (or any other
you come up with)
@appendStructurePath
@appendStructure
@appendPath
@addStructurePath
@addStructure
@addPath
@structureAware
NOTE: some need us to flip the default value
Ross
