cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <d...@yahoo.com>
Subject Re: AW: [C2.1] new SOAP logicsheet
Date Thu, 11 Oct 2001 11:01:30 GMT
My Mistake Stefano. Thanks for the catch.

-- dims

--- Carsten Ziegeler <cziegeler@sundn.de> wrote:
> Hi Ovidiu,
> 
> due to the problems with HTTPClient library, I removed it
> from cvs and commented out the using functions in the SOAPHelper
> class. This of course breaks your logicsheet.
> 
> Could you please take care of this? Another problem with
> your could is that it requires jdk 1.3. Until now, we still
> want to be compatible with 1.2, so you can't use URL.getPath().
> 
> If your code really requires one or both we should think of
> making it optional.
> 
> Carsten
> 
> > -----Ursprungliche Nachricht-----
> > Von: ovidiu@cup.hp.com [mailto:ovidiu@cup.hp.com]
> > Gesendet: Mittwoch, 10. Oktober 2001 23:32
> > An: Davanum Srinivas
> > Cc: cocoon-dev@xml.apache.org
> > Betreff: Re: [C2.1] new SOAP logicsheet 
> > 
> > 
> > On Wed, 10 Oct 2001 14:01:33 -0700 (PDT), Davanum Srinivas 
> > <dims@yahoo.com> wrote:
> > 
> > > Thanks a ton for your contribution. Checked it in. Please cross check. 
> > > - I have added it to the main page too for better visibility. 
> > > - Fixed hard coded /home/ovidiu strings.
> > > - Fixed imports in URLSource that went bad after the merge.
> > 
> > Oops, sorry about this, I forgot to remove them ;-)
> > 
> > > One Request, If we can get rid of the HTTPClient dependency it 
> > will be great!!! Please take a loo
> > > k
> > > at http://www.javaworld.com/javaworld/javatips/jw-javatip34.html.
> > 
> > Yes, I know about URL and URLConnection. However they are rather badly
> > implemented in Sun's JDK. They throw exceptions if the response code
> > from the server is not "200 OK", and as a result I can't obtain the
> > SOAP response from the server. The HTTPClient library gives this
> > ability, plus it provides many more features, like transparent
> > HTTP/1.1 support, proxies (both HTTP proxy and SOCKS), SSL etc. I
> > don't want to reinvent the wheel and write them in SOAPHelper again.
> > 
> > I've also looked at the httpClient from Jakarta common's, but it's
> > still far from being usable. I'll check it out in a few months, and if
> > I have time work a little bit on it.
> > 
> > BTW, did you incorporate the HTTPClient.jar in CVS?
> > 
> > Thanks,
> > Ovidiu
> > 
> > > --- Ovidiu Predescu <ovidiu@cup.hp.com> wrote:
> > > > I sent this patch yesterday, but it bounced back because it 
> > was bigger than
> > > > 100,000 bytes. I've placed the jar file mentioned below at:
> > > > 
> > > > http://www.geocities.com/SiliconValley/Monitor/7464/HTTPClient.jar
> > > > 
> > > > Cheers,
> > > > Ovidiu
> > > > 
> > > > -- 
> > > > 
> > > > Hi,
> > > > 
> > > > This patch adds implements a SOAP logicsheet entirely using 
> > Cocoon concepts. It
> > > > doesn't depend on any SOAP client library to do the 
> > marshaling and unmarshaling
> > > > of the SOAP body.
> > > > 
> > > > The SOAP logicsheet is based on another concept, which I 
> > called XScript. This
> > > > allows one to define pseudo-variables in XSP, whose value can 
> > be inline XML or
> > > > any XML content obtained from an URL resource. Such a value is an
> > > > XScriptObject, and can contain in general case any content, 
> > not only XML.
> > > > 
> > > > <xscript:variable name="var1">
> > > >   <b>this is a title</b>
> > > > </xscript:variable>
> > > > 
> > > > <xscript:variable name="var2" href="docs/samples/data.xml"/>
> > > > 
> > > > Once a variable is defined, you can refer to it by name, and 
> > have its XML
> > > > content inserted in the generated XML.
> > > > 
> > > > <xscript:get name="var1"/>
> > > > 
> > > > You can transform the value of an XScript variable using XSLT 
> > stylesheets.
> > > > Since an XSLT stylesheet is an XML document, it can be 
> > represented as an
> > > > XScript object. XScript provides ways to transform an XScript 
> > object into
> > > > another XScript variable.
> > > > 
> > > > Example:
> > > > 
> > > > // Transform the content of "var1" through "mystyle.xsl" and 
> > insert the
> > > > // resulting XML in the generated XML document.
> > > > <xscript:variable name="mystyle" href="stylesheets/mystyle.xsl"/>
> > > > <xscript:transform name="var1" stylesheet="mystyle"/>
> > > > 
> > > > // Similarly as above, but assign the result of the 
> > transformation to another
> > > > // XScript object
> > > > <xscript:variable name="result">
> > > >   <xscript:transform name="var1" stylesheet="mystyle"/>
> > > > </xscript:variable>
> > > > 
> > > > Each XScript variable can be declared to be visible in a 
> > particular scope. The
> > > > available scopes are:
> > > > 
> > > > - global, you can access the variable from any page, by any user.
> > > > 
> > > > - session, the variable is visible only in the scope of the 
> > session it was
> > > > created in.
> > > > 
> > > > - page, the variable is visible only in the page it was created in.
> > > > 
> > > > The scope is specified using the "scope" attribute:
> > > > 
> > > > <xscript:variable name="var1" scope="session"/>
> > > > <xscript:variable name="mystyle" scope="global"/>
> > > > <xscript:variable name="page-var" scope="page"/>
> > > > 
> > > > The default scope is "session".
> > > > 
> > > > You can create XScript variables using the content of other 
> > XScript variables,
> > > > or using a mixture of inline XML and values of different 
> > XScript variables:
> > > > 
> > > > <xscript:variable name="var3">
> > > >   <body>
> > > >     <title><xscript:get name="var1"/></title>
> > > >     <content><xscript:get name="result"/></content>
> > > >   </body>
> > > > </xscript:variable>
> > > > 
> > > > The SOAP logicsheet is implemented using XScript. It collects 
> > in an XScript
> > > > variable the inline XML fragment representing the SOAP body, 
> > and then it posts
> > > > it to the specified URL.
> > > > 
> > > > I don't have much documentation for it, but I hope I'll come 
> > with something in
> > > > the next few days.
> > > > 
> > > > Besides the patch attached, you also need to place the 
> > HTTPClient.jar library
> > > > from
> > > > 
> > > > http://www.innovation.ch/java/HTTPClient/
> > > > 
> > > > in the lib/ directory. For your convenience I attached the 
> > jar file to this
> > > > email. I tried playing with the jakarta-commons httpClient 
> > library, but I
> > > > didn't get too far with it.
> > > > 
> > > > Regards,
> > > > -- 
> > > > Ovidiu Predescu <ovidiu@cup.hp.com>
> > > > http://orion.rgv.hp.com/ (inside HP's firewall only)
> > > > http://sourceforge.net/users/ovidiu/ (my SourceForge page)
> > > > http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, 
> > Emacs, other stuff)
> > > > 
> > > > 
> > > 
> > > > ATTACHMENT part 2 application/x-gzip name=cocoon.diff.gz
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > > 
> > > 
> > > =====
> > > Davanum Srinivas - http://jguru.com/dims/
> > > 
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Make a great connection at Yahoo! Personals.
> > > http://personals.yahoo.com
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > > 
> > 
> 
=== message truncated ===


=====
Davanum Srinivas - http://jguru.com/dims/

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com

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


Mime
View raw message