I haven't had time to implement the Amazon xsl. I could use some help with it. Any takers?
Ivelin ----- Original Message ----- From: "Christopher Watson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, July 05, 2002 4:20 AM Subject: RE: [Announcement] Embedding One Web Site in Another with Cocoon (new Component) > 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:[EMAIL PROTECTED]] > > Sent: 04 July 2002 22:35 > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > 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, [EMAIL PROTECTED] > > > > 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: <[EMAIL PROTECTED]> > > For additional commands, e-mail: <[EMAIL PROTECTED]> > > > > > > > --------------------------------------------------------------------- > 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: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
