cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "manoj" <ma...@omnesysindia.com>
Subject [HELP]Cocoon Portal Framwork Integration Problem
Date Tue, 15 Apr 2003 13:42:02 GMT
Hi Folks,

Cocoon framework is real great indeed and you folks are really making it as a defacto standard
in web publishing. I started working on the capabilities of cocoon and its pluggable blocks
for an anticipated web integration project in near future for which i feel this framework
is the right bet. But during test trial I noticed following observations with portal framework.

01. Portal accepting input feeds as xml or its variety or html. I was trying to include a
asp (active server page) as a coplet it does not get displayed in the portal framework. Following
pattern which i tried to use for html by passing the source as it as has worked for html.
But when we replaced *.html with *.asp it did not work

<map:match pattern="*.html">
            <map:generate src="{1}.html"/>
            <map:transform/>
            <map:serialize/>
          </map:match> 

Since our client has mixed bag web applications in ASP/JSP/PHP all generating the html output
I tried to pass the same as it is in the pipeline delegating the cocoon to decide how it should
be transformed.
<map:match pattern="*.asp">
            <map:generate src="{1}.asp"/>
            <map:transform type="cinclude"/>
            <map:serialize type="html"/>
          </map:match> 
This also did not work returning coplet not available. (while this accessible from web browser).

In case of JSP it display the complete source code rather than parsed data when this pattern
was used.
<map:match pattern="*.jsp">
            <map:generate src="{1}.jsp"/>
            <map:transform type="cinclude"/>
            <map:serialize type="xhtml"/> // because HTML4.0 compliant pages are generated
by jsp.
          </map:match> 

 
For PHP application I am yet to try. Since the framework is soo generic I am sure there will
be a generic mechanism to handle various types of feeds generated by different type of technologies.
Here I agree with you all that we can go for xml derivatives ie asking the different applications
to deliver xml based output. But to protect the existing investment of the client , as is
based approch is better. Any suggestions or thought process is greatly appreciated which can
integrate diffferent types of feeds as is based into the portal framework.


Rgs,
Manoj

Mime
View raw message