You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Andy Lewis <aj...@ascii27.net> on 2003/01/10 15:24:36 UTC

InputModules and Transformers

I've been watching the extensive discussions about input modules for some time now, and if I
understand them corectly, it brings me to a couple of questions...
Is there / should there be / can there be a transformer that allows access to data from input
modules? Something that allows values to be accessed and placed in the SAX stream?
How does this compare to ro correlate with the session transformer that originated with the portal
component donation? Are they / should they be the same?
I have found the session transformer invaluable in many cases, but it seems to me that extending
it to use input modules would REALLY be useful....
thoughts?

-- 
"The heights of genius are only measurable by the depths of stupidity."



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: InputModules and Transformers

Posted by Vadim Gritsenko <va...@verizon.net>.
Jeff Turner wrote:

>On Fri, Jan 10, 2003 at 09:24:36AM -0500, Andy Lewis wrote:
>  
>
>>I've been watching the extensive discussions about input modules for
>>some time now, and if I understand them corectly, it brings me to a
>>couple of questions...  Is there / should there be / can there be a
>>transformer that allows access to data from input modules? Something
>>that allows values to be accessed and placed in the SAX stream?
>>    
>>
>
>There is a LinkRewriterTransformer which does this for certain
>attributes:
>
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15611
>
>(and Chris just committed.. thanks)
>
>It would be simple to modify this to replace ${module:key} tokens in the
>SAX characters() method,
>

If you do this - don't forget to buffer all characters() before doing 
replacements.

Vadim



> rather than attribute values.
>
>  
>
>>How does this compare to ro correlate with the session transformer that
>>originated with the portal component donation? Are they / should they
>>be the same?
>>    
>>
>
>Didn't know about it, hidden away in a block.. it looks quite powerful.
>Anything based on InputModules can only do string->string conversion, so
>I don't think there's too much overlap.
>
>--Jeff
>
>  
>
>>I have found the session transformer invaluable in many
>>cases, but it seems to me that extending it to use input modules would
>>REALLY be useful....  thoughts?
>>
>>-- 
>>"The heights of genius are only measurable by the depths of stupidity."
>>
>>    
>>



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: InputModules and Transformers

Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 11.Jan.2003 -- 02:08 AM, Jeff Turner wrote:

> Anything based on InputModules can only do string->string conversion, so

This ought to be string -> object

If it's XMLizable, it could be included for example.

String -> string is valid when used in the sitemap, though.

But I can't comment on the SessionTransformer.

	Chris.
-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: InputModules and Transformers

Posted by Jeff Turner <je...@apache.org>.
On Fri, Jan 10, 2003 at 09:24:36AM -0500, Andy Lewis wrote:
> 
> I've been watching the extensive discussions about input modules for
> some time now, and if I understand them corectly, it brings me to a
> couple of questions...  Is there / should there be / can there be a
> transformer that allows access to data from input modules? Something
> that allows values to be accessed and placed in the SAX stream?

There is a LinkRewriterTransformer which does this for certain
attributes:

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15611

(and Chris just committed.. thanks)

It would be simple to modify this to replace ${module:key} tokens in the
SAX characters() method, rather than attribute values.

> How does this compare to ro correlate with the session transformer that
> originated with the portal component donation? Are they / should they
> be the same?

Didn't know about it, hidden away in a block.. it looks quite powerful.
Anything based on InputModules can only do string->string conversion, so
I don't think there's too much overlap.

--Jeff

> I have found the session transformer invaluable in many
> cases, but it seems to me that extending it to use input modules would
> REALLY be useful....  thoughts?
> 
> -- 
> "The heights of genius are only measurable by the depths of stupidity."
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: RequestDispatcher with Cocoon

Posted by Andy Lewis <aj...@ascii27.net>.
If I actually get it working, I would certinaly contribute it. Yeah, ugly, but probalby no really
CLEAN way to achieve it.
At any rate, many thanks for the guidance - I'll go with a reader. I suspected that using the
wrong componenet would cause me grief....
> Vadim Gritsenko wrote:
>
>> Andy Lewis wrote:
>>
>>> I have a need to, under specific circumstances, do a
>>> RequestDispatcher.forward out of Cocoon. I've
>>> not found any support for this in Cocoon. Alternatives won't work  since I need to do this
>>> while
>>> preserving request attributes. I would expect to be able to code this  as an Action without
>>> extreme
>>> difficulty, but I thought I would thorw the idea to the list first  and see if anyone has any
>>> ideas, comments, or suggestions...(something other than "No!  Don't  do it!" :)
>>> Many thanks....
>>>
>>
>> Why do I think that reader is much better place for something like  this (...assuming that
>> it's possible...)?
>
>
> Because forwarding delegates the production of the output to the target  resource. But Cocoon
> expects the sitemap to produce something or an  error is displayed.
>
> So the only place where such forwarding is possible is in a Cocoon  component that feeds the
> output with abitrary binary data, and Cocoon  names it a reader ;-)
>
> Andy, would you like to contribute a "ForwardReader", how ugly and  servlet-tied as it may be ?
>
> Sylvain
>
> --
> Sylvain Wallez                                  Anyware Technologies
> http://www.apache.org/~sylvain           http://www.anyware-tech.com { XML, Java, Cocoon,
> OpenSource }*{ Training, Consulting, Projects }
>
>
>
> --------------------------------------------------------------------- To unsubscribe, e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


-- 
"The heights of genius are only measurable by the depths of stupidity."



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: RequestDispatcher with Cocoon

Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:

> Vadim Gritsenko wrote:
>
>> Andy Lewis wrote:
>>
>>> I have a need to, under specific circumstances, do a 
>>> RequestDispatcher.forward out of Cocoon. I've
>>> not found any support for this in Cocoon. Alternatives won't work 
>>> since I need to do this while
>>> preserving request attributes. I would expect to be able to code 
>>> this as an Action without extreme
>>> difficulty, but I thought I would thorw the idea to the list first 
>>> and see if anyone has any
>>> ideas, comments, or suggestions...(something other than "No!  Don't 
>>> do it!" :)
>>> Many thanks....
>>>
>>
>> Why do I think that reader is much better place for something like 
>> this (...assuming that it's possible...)?
>
>
>
> Because forwarding delegates the production of the output to the 
> target resource. But Cocoon expects the sitemap to produce something 
> or an error is displayed.
>
> So the only place where such forwarding is possible is in a Cocoon 
> component that feeds the output with abitrary binary data, and Cocoon 
> names it a reader ;-)


Thanks for explaining my thoughts ;)

Vadim



> Andy, would you like to contribute a "ForwardReader", how ugly and 
> servlet-tied as it may be ?
>
> Sylvain



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: RequestDispatcher with Cocoon

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:

> Andy Lewis wrote:
>
>> I have a need to, under specific circumstances, do a 
>> RequestDispatcher.forward out of Cocoon. I've
>> not found any support for this in Cocoon. Alternatives won't work 
>> since I need to do this while
>> preserving request attributes. I would expect to be able to code this 
>> as an Action without extreme
>> difficulty, but I thought I would thorw the idea to the list first 
>> and see if anyone has any
>> ideas, comments, or suggestions...(something other than "No!  Don't 
>> do it!" :)
>> Many thanks....
>>
>
> Why do I think that reader is much better place for something like 
> this (...assuming that it's possible...)?


Because forwarding delegates the production of the output to the target 
resource. But Cocoon expects the sitemap to produce something or an 
error is displayed.

So the only place where such forwarding is possible is in a Cocoon 
component that feeds the output with abitrary binary data, and Cocoon 
names it a reader ;-)

Andy, would you like to contribute a "ForwardReader", how ugly and 
servlet-tied as it may be ?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: RequestDispatcher with Cocoon

Posted by Vadim Gritsenko <va...@verizon.net>.
Andy Lewis wrote:

>I have a need to, under specific circumstances, do a RequestDispatcher.forward out of Cocoon. I've
>not found any support for this in Cocoon. Alternatives won't work since I need to do this while
>preserving request attributes. I would expect to be able to code this as an Action without extreme
>difficulty, but I thought I would thorw the idea to the list first and see if anyone has any
>ideas, comments, or suggestions...(something other than "No!  Don't do it!" :)
>Many thanks....
>

Why do I think that reader is much better place for something like this 
(...assuming that it's possible...)?

Vadim



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RequestDispatcher with Cocoon

Posted by Andy Lewis <aj...@ascii27.net>.
I have a need to, under specific circumstances, do a RequestDispatcher.forward out of Cocoon. I've
not found any support for this in Cocoon. Alternatives won't work since I need to do this while
preserving request attributes. I would expect to be able to code this as an Action without extreme
difficulty, but I thought I would thorw the idea to the list first and see if anyone has any
ideas, comments, or suggestions...(something other than "No!  Don't do it!" :)
Many thanks....


-- 
"The heights of genius are only measurable by the depths of stupidity."



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org