cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <>
Subject [Announcement] Embedding One Web Site in Another with Cocoon (new Component)
Date Thu, 04 Jul 2002 21:35:09 GMT
|                                                     |
|             New Cocoon Generator                    |
|                                                     |
|    allows integration of content and behavior       |
|                                                     |
            between remote web sites.                 |
|                                                     |

For quite some time web sites are exchanging news feeds and other one way
content via RSS. Some portals are even outsourcing and co-branding web
As appealing and feasible as this may seem, most of today's implementations
are quite rugged.

Let's follow a typical scenario:
User logs in to a familiar portal and happily browses around.
At some point the user clicks on a link which leads to a strange page.
It has the portal logo, might even show the user login id but looks very
different and unfamiliar... After some time and frustration the user gets
used to switching back and forth between the two faces of the portal...
while looking for another provider which offers both services in a coherent
graphical interface.

This story is not uncommon and is an inherent problem with the traditional
HTML based publishing.

Outsourcing interactive components to a third party site, while preserving
the look & feel of the original portal is still possible when done right.
Cocoon has a solution.

The new Web Service Proxy component is built to help with this very problem.
Once plugged in the sitemap, it transparently pipes browser requests to a
remote web app and returns the response back to the sitemap.

WebServiceProxyGenerator is available in Cocoon 2.1-dev HEAD.
To try the demo, build the latest CVS HEAD code and point to:


More for the component (from the demo page):

WebServiceProxyGenerator combined with the XMLForm framework and XSLT,
allows vendors to share interactive content with little effort.
The Web Service Proxy takes advantage of the fact that a Cocoon web
application produces XML content which is later translated into multiple
presentation formats, like HTML or WML.

The demo embeds the Cocoon Feedback Wizard application, which produces an
XML view containing both static data and interactive forms. Having a client
independent content format, allows this view to be pulled to the embedding
web site (this demo) and styled with XSLT in the Look & Feel of the site.

Ok, styling presentation is easy to understand, but how is a form submitted
to the original site?
Since the form markup in the XML content of an embedded page uses relative
URL address for the target, once the end user submits, the form data is sent
to the containing site, which captures the form data and the relative URL.
The Web Service Proxy then takes this information and re-submits it to the
original site. It then reads the XML response and makes it available to the
sitemap for styling again.

Hm, but the Feedback Wizard example maintains a session while going through
multiple pages. So, how is the containing site propagating the end user
session to the to the embedded site?
The answer is simple. The Web Service Proxy simply hooks to the end user
session, and automatically starts its own session with the remote site. If
the remote site does not require authentication, then everything is
transparent to the developer of the containing web site. Otherwise the
WebServiceProxyGenerator has to be extended to override the procedure for
imitating session with the remote site.

What transport protocols are supported?
HTTP 1.0, HTTP 1.1, HTTPS.

Have more questions? Look at the code, it is really simple. If you need
advise, search through the Cocoon mailing lists archives. If you can't find
the answer, email your question to the Cocoon mailing lists. Finally, if you
need to contact me, send email to Ivelin Ivanov,

If you like this component, please help with documentation. Write an FAQ,
HOW-TO or User Guide.

------------- End of overview ------------

I am hoping to see this component used in Ugo's CocoBlog app and possibly
Carsten and Matthew's portal apps.

I also feel that it provides solution to some of the problems we were
recently addressing with Cocoon Blocks.

Stay tuned for more exciting news ... ;)



To unsubscribe, e-mail:
For additional commands, email:

View raw message