Thorsten Scherler wrote:
El vie, 18-11-2005 a las 08:48 +0000, Ross Gardler escribió:
Thorsten Scherler wrote:
El mié, 16-11-2005 a las 16:24 +0000, Ross Gardler escribió:
Thorsten Scherler wrote:
...
Have you considered making the contractTransformer a standard Cocoon
transformer rather than an Element?
...
Perhaps one for a future enhancement then.
+1
(after you have seen the code we will talk again, ok?)
+1
What is the "properties container"? I ask because my attention is
starting to turn to the new properties definition system (going to do it
until after locationmap is complete and 0.8 is out the door).
It seems this is going to need to be considered.
Yes, actually we have since the beginning properties in the
structurer.fv. IMO we should use this mechanism to pass non-location
variables (like theme-name). ...
My current thinking is that the vast majority of properties can now be
removed by having variables in the locationmap. I'm not sure that this
will fit with your "properties container" concept above.
The locationmap is IMO only capable of returning locations and not
non-locations strings. I mean some properties are not based on a
location, but for the rest I strongly agree.
OK, it makes sense to separate location properties from "other"
properties. We can both proceed as we are understanding where we start
to overlap one another.
IMO we want to implement a locationmap source protocol. This way it
would be possible to use it like:
Source s = sourceResolver.resolveURI(location);
and everywhere (sitemap,...) like lm://my.property. That makes the usage
within java a lot nicer because I do not have to first contact the input
module.
+1
I have shorten the definition of nugget-contracts in the structurer:
<forrest:contract name="nav-main-testing"
nugget="cocoon://#{$cocoon/parameters/getRequest}.navigation.xml"/>
...
Why nugget="",
...
why not src=""?
...because that gives the impression that it is the src file of the
contract implementation and not the requested raw data.
...
Good reasoning for not having src. Given this reasoning what is wrong
with the more "usual" @href?
Yeah, href sounds good but still one can confuse that the actual
contract is coming from the href. Maybe we should use something more
explicit like @dataURI or @dataSrc or dataHref. That reflects what the
attribute actually is doing (personally I think @dataURI would be the
best option).
WDYT?
+1 for @dataURI
Ross
