cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tagunov Anthony" <atagu...@nnt.ru>
Subject Re: [RT] Content Aggregation-another spin (long)
Date Sat, 27 Jan 2001 15:25:44 GMT
On Wed, 24 Jan 2001 09:38:16 -0500, Berin Loritsch wrote:

BTW: I beleive that we could speak of 
 -- not blind aggregation (if while we're recursing the sitemap we retain the same, say
           HttpServletRequest object, with it's set of coocies, headers, and parameters)
--  blind aggregation (after the recursion has started the HttpServletRequest object is not
accessible)
     In this case some other way of passing parameters is desirable. Maybe something
     like    <map:part src="cocoon://beauty?a=18&b={zzz}"/>
     Here I don not mean that "beauty" is an URL that gets via the matching rules
     but rather a name (similar to those given to resource pipelines). 
     Nevertheless, after such an URI ("cocoon://name-of-the-pipeline") I propse
     to allow writing parameters. Let those paramters to be accessible to the 
     generator and translators and not those from the original httpservletrequest.
     (This way implies that we have no way of passing cocoocies except for
      converting them into parmaters.
      This can be solved at least in two ways:
        -- establish a common interface for accesssing all kinds of parameters
              say smth.get("aaa") would allow to access http servlet request parameter "aaa"
                     smth.get("C_aaa") will provide access to a cocoocie
                     smth.get("H_aaa") will provide access to a header (as is done in C1 in
xslt transform)
         then we can easily pass <map:part src="cocoon://beauty?a=18&H_aaa=3"/>.
     )
     An alternative sytax could be 
            <map:part src="cocoon://beauty">
               <param name="a">18</param>
            </map:part>
     This way we get rid of problems of escaping our values from "aaa bbb" to "aaa+bbb" and
even worth with cirillics  :)

     If we use this alternative syntax, we can use
           <map:par....>
                <param ..
                <cocoocie..
                <http-header..

Best regards Tagunov Anthony.

P.S. At our company we have already developed content aggregation 
for C1 that's why it's easy for me to come up with ideas: we've
already got some experience in this area.


>Stuart Roebuck wrote:
>> 
>> On Wednesday, January 24, 2001, at 01:32 PM, Berin Loritsch wrote:
>> 
>> > Now we have a couple of issues, the recursiveness of the sitemap
>> > (generators calling the sitemap to get results) and the visibility
>> > of the parts of the document--no way of hiding the portions.
>> > That might be resolvable with the use of resources.  That is assuming
>> > that the end result will always be HTML, or easily merged in it's
>> > final state.
>> 
>> When you say "the end result will always be HTML" you really meant "XML" - yes?
>> 
>> I really should look up resources and find out what they are, but from what is being
said, am I right in saying that resources can result in non XML output?  
If this is the case then feeding a resource into an aggregation (or anywhere else for that
matter) would require a redundant serialisation and deserialisation.  
I'm not offering a solution here, just raising an issue!
>
>Thanks for raising that issue.  Basically, it would help if we new for certain
>whether the resources are "serialized" versions of a resource, or simply a source
>for XML inclusion.  Personally for Aggregation to work smoothly, that is what
>we need.  A way to specify a non-serialized source to include into the document.
>The source needs to be able to have undergone it's own processing (XSP, transformation
>into an intermediate result, etc) and include those results.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>For additional commands, email: cocoon-dev-help@xml.apache.org
>
>




Mime
View raw message