cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivanov, Ivelin" <Ivelin_Iva...@bmc.com>
Subject RE: Cocoon, XForms, Web Services, etc.
Date Mon, 18 Feb 2002 21:34:05 GMT


I guess we can keep the discussion on this list until we're told otherwise.

I've spent some time this weekend to study the current state of Axis
(xml.apache.org/axis)
Recently there was a hot discussion on this list concerning integration
between Axis and Cocoon.
Again, with my very humble Cocoon background, I think there's yet another
good reason for connecting these two projects.

>> On the other hand you're right that extending from 
>ActionForm shouldn't be
>> enforced.
>> All that's needed is xml mapping descriptor.
>
>Yes, agree.

More on that note. Axis seems to fulfill the generic validation and
population handling role big time, through simply following the web services
specs. Validation is generally based on XML Schema types, but cusomization
is possible. Population is also standardized through JavaBeans support, but
again custom Serializers and Deserializers can be provided by the developer.

>XForm) description from the EJB layer where business logic is 
>implemented.
>In this case form JavaBean will look like a hierarchical Map of simple
>types, Maps and Collections - so it'll be more natural to use 
>XML for that.

I am not quite seing how something like this can be resolved in the general
case.

>Never used XSLTC, but I know that XPath expressions can be prepared and
>reused next time without parsing. This should improve 
>perfomance a little.
>
>> For example
>>   <c2form:input name="/person/first_name[2]" value="Joe"> 
>could result in
>> xslt code which modifies
>> the original xml form. XSLTC can convert the xslt into quick 
>bytecode.
>>   - From my humble XSLT experience I understand that maybe 
>xsl:key() can
>be
>> efficiently used for static xpath expressions like that 
>which are known at
>> build time.
>
>That would be fine.
>> Apology for repeating myself. An ActionForm is a JavaBean. I feel
>> comfortable with
>> creating UI specific beans as long as I don't need to worry about
>HTML/Java
>> conversion.
>
>But your UI specific beans duplicate your value objects, don't they?

Yes, sometimes. The UI specific beans usually contain some combination of
domain beans.
This certainly doesn't always work though.

>> I'm hoping that this layer can be skipped through sax events 
>between xpath
>> and JAXB.
>
>Yes, agree again.

I'd like to paraphrase this now. 


After looking at Axis, even though still in alpha, I also believe it is
ultimately a tool Cocoon should integrate with.

Cocoon is great at multi-layer XML content processing, while Axis is focused
on web services framework for java.

Please excuse my naiveté and correct me if the following set of thoughts is
unrealistic:

HTML Form field names can be represented with XPath expressions.
We can borrow and extend Struts' Action concept to serve as a wrapper for
web service calls.
The wrapper can convert HTML Form submits into xml DocumentProducer which
can be then piped into Axis to handle as a web service call through SAX
events.

On the way out of course, Cocoon's mighty presentation power comes to play
and render an otherwise plain XML response into a colorful web page suit
best for the requesting browser type.


I'm hoping that this way, the domain development team can focus on content
interface which is shared and reused between web services clients, rich
browsers, thin PDA's, etc.
That would hopefully be a better architecture than having to code up
separately content layers for web pages and web services. 


Fire at will.


Cheers.

--Ivelin


>Btw, do you speak Russian?

Some. Reading/listening is decent. I'm from Bulgaria.


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


Mime
View raw message