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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
