cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Watson" <c.wat...@zen.co.uk>
Subject RE: [Announcement] Embedding One Web Site in Another with Cocoon (new Component)
Date Fri, 05 Jul 2002 09:20:30 GMT
Ivelin

Impressive !

In your readme.txt you mention some xsl files ...
amazonform2html.xsl
AmazonForm2html.xsl

Thanks for including AmazonForm.xml in the text of the readme.
Could you include or email the .xsl files named above

Thanks

Christopher


> -----Original Message-----
> From: Ivelin Ivanov [mailto:ivelin@apache.org]
> Sent: 04 July 2002 22:35
> To: cocoon-dev@xml.apache.org
> Cc: cocoon-users@xml.apache.org
> Subject: [Announcement] Embedding One Web Site in Another with Cocoon
> (new Component)
>
>
> +=====================================================+
> |                                                     |
> |             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
> applications.
> 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:
>
> http://localhost:8080/cocoon/samples/webserviceproxy/
>
>
> 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, ivelin@apache.org.
>
> 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 ... ;)
>
>
>
> Enjoy,
>
> Ivelin
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> Please check that your question  has not already been answered in the
> FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
> For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>
>
>


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message