forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [RT] future of v2
Date Fri, 18 Nov 2005 12:15:18 GMT
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


Mime
View raw message