I am not particularly fond of XSP. I fail to understand how does XSP is any
better than JSP scripts designed to produce XML -- apart from a better
integration with Cocoon's SAX pipeline. I feel that JSP tends to have better
support, a larger development community and available codebase. J2EE
integration, and EJB call methods are an excellent example of JSP having a
larger codebase available. JSPs are an integral part of the J2EE platform and
can easily cooperate with EJB containers.
I hate bashing on good work. I have used XSPs in the past, both in C1 and C2,
and I know they are powerful, solid and overall an excellent work. The question
here is that, in my opinion, they do not provide enough of a "paradigm shift" to
justify choosing XSPs over the de facto standard - JSPs.
So, to sum up my option, I justify the positioning of EJB integration at the
generator level, by looking at EJB calls as calls to the business layer. If they
are calls to the business layer, no more processing is to be done on the upper
layers. Only input validation, and output aggregation and presentation
processing should happen. A generator fits this scenario in the simplest form
possible.
Cocoon may provide more than the presentation layer, however, and in this case,
a logicsheet is called for. However, implementing an XSP logicsheet, we would be
duplicating the effort done in the JSP implementation, which is satisfactory.
Cheers,
Sergio
On Fri, 21 Sep 2001 09:41:03 +0200, Michael Homeijer wrote:
From: Michael Homeijer <[EMAIL PROTECTED]>
--
> After a quick look at the files, I have to following question about your
> solution:
>
> Why did you choose not to write a logic sheet? One of the benefits of a
> logic sheet
> would be that you can add your own code in xsp in addition to the code that
> will
> be generated to call the EJB.
>
>
> Other comment on Cocoon and J2ee:
> One of the things that we did to interact with bean was to standardize
> result sets
> that were returned by beans. These result are transformed by an object that
> implements
> xmlfragment and while the resultset is transformed to XML, additional custom
> processing
> can be done by writing custom classes (eg. whe have an inner class that can
> URLEncode attributes).
>
> The code we write is now as easy as (in an xsp page):
>
> InitialContext ic = new InitialContext();
> WebPollXMLHome eh = (WebPollXMLHome)ic.lookup("WebPollXML");
> WebPollXMLRemote er = eh.create();
>
> Collection poll = er.getCurrentPoll();
>
> <xsp:content><getCurrentPol><xsp:expr>new
> XMLObject(poll)</xsp:expr></getCurrentPol></xsp:content>
>
> A logic sheet could even simplify this a bit more.
>
> For the bean side, we generate so called DataAccessObject's (See j2ee
> pattern catalog from sun) based on
> sql in a xml component definition file.
>
> I have thought about how something like this would fit into Cocoon (even
> some sort of xsp language for EJBs,
> but lets stay on the ground for now ;-)) but the approach we now have uses a
> proprietary ejb result format we defined ourselves.
> (Maybe this could be handled by some construction <xsp:expr> in the xsp
> logic sheet uses).
>
> If anybody is interested in integrating EJB support in Cocoon, i'd be
> willing to help.
>
> Any ideas on how to set this up? Do we need some kind of voting on the
> mechanism used? Other ideas?
>
> TIA,
> Michael
>
> -----Original Message-----
> From: Sergio Carvalho [mailto:[EMAIL PROTECTED]]
> Sent: donderdag 20 september 2001 15:08
> To: [EMAIL PROTECTED]
> Subject: Re: Cocoon and J2EE
>
>
>
> Ok, just posted it here:
> http://sergio.insuasoftware.com/CocoonEjbProofOfConcept.tgz
>
> On Thu, 20 Sep 2001 14:18:41 +0200, Martin Kavalar wrote:
> From: Martin Kavalar <[EMAIL PROTECTED]>
> --
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <[EMAIL PROTECTED]>
> For additional commands, e-mail: <[EMAIL PROTECTED]>
>
--
Sergio Carvalho
---------------
[EMAIL PROTECTED]
If at first you don't succeed, skydiving is not for you
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
