Hi, Even after reading the exhaustive OPS documentation, I am afraid
it is still not very clear to me as to what is the recommended way of using a
java object as a dynamic xforms instance in the PFC view. To give some
background, if an application is already following MVC architecture (say,
Struts or WebWorks), the following scenario is possible: 1) The MVC
controller (struts/WW action) receives the original request, say for displaying
a “Loan” business object. 2) The action
retrieves the business object, which is just a POJO. 3) The action
now somehow makes this POJO available to the PFC model as an XForrms instance,
so that the model can process it (if required) and pass it over to the PFC
view. 4) The PFC view
uses the XForms instance along with associated xhtml, to render the final view. My question, hence, is w.r.t Step (3). What is the best way for the action to pass the
bean to the PFC? For the time being, we are going by this approach: 1) WebWork Action
retrieves the bean, puts it in request/session scope and then redirects to a
PFC page flow. 2) The page
flow’s model is an XPL that chains the “Scope Generator” and “Scope
Serializer” processors respectively in that order; so as to eventually
get the xml’ized bean as the model output. 3) The page
view uses this instance (using the “xi:include href=input:data” directive)
to render the final UI. However, we are not very comfortable with this approach and
were wondering if there is a way by which we can pass this object directly to
OPS. Any help/suggestions would be really appreciated. Thanks in advance, Vikas "Quidquid latine dictum
sit, altum sonatur" -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Vikas,
I've been doing something very closely resembling this. The problem you need to solve here is really about how to map java objects to xml. This is not straightforward, and probably requires an explicit mapping. In fact, I see this OO/XMl mismatch as the same problem as the OO/RDBMS problem (which also requires explicit mapping). Here is how I did this, end-to-end: 1. All my business and process logic are done in java. 2. I use the java processor in XPL to bridge the OPS application framework to my backend java services code. 3. I use JiBX to map a java object to XML 4. I use Hibernate to map a java object to the RDBMS Some sample code: My orbeon API connector in Java: ================================== package org.cruk.aspic.editor.api.orbeon ; import org.apache.log4j.Logger; import org.cruk.aspic.editor.exception.EditorException; import org.cruk.aspic.editor.model.Claim; import org.cruk.aspic.editor.model.ClaimIdentifier; import org.cruk.aspic.editor.util.OrbeonUtil ; import org.dom4j.Document; import org.orbeon.oxf.pipeline.api.PipelineContext; import org.orbeon.oxf.processor.ProcessorInputOutputInfo; import org.orbeon.oxf.processor.SimpleProcessor; import org.xml.sax.ContentHandler ; import org.xml.sax.SAXException; public class GetNextClaimEditorTokens extends SimpleProcessor { public GetNextClaimEditorTokens() { addInputInfo(new ProcessorInputOutputInfo(INPUT_DATA)); addOutputInfo(new ProcessorInputOutputInfo(OUTPUT_DATA)); } public void generateData(PipelineContext context, ContentHandler contentHandler) throws SAXException, EditorException { Document inputDoc = readInputAsDOM4J(context, INPUT_DATA); Claim claim = (Claim) OrbeonUtil.fromXml(inputDoc); //JiBX mapping org.cruk.aspic.editor.workflow.GetNextClaimEditorTokens.execute (claim); Document returnedDoc = OrbeonUtil.toXml(claim); //JiBX mapping OrbeonUtil.returnToOrbeon(contentHandler, returnedDoc); } } A sample domain class: =================== package org.cruk.aspic.editor.model; import java.util.List; import java.util.Vector; public class Claim extends BaseModel{ private String plural = "claims"; private String expression ; private List nextTokens = new Vector(); private List identifiers = new Vector(); private List variables = new Vector(); private ClaimSelectedToken selectedToken; private ClaimIdentifier identifier; public ClaimIdentifier getIdentifier() { return identifier; } public void setIdentifier(ClaimIdentifier identifier) { this.identifier = identifier; } public ClaimSelectedToken getSelectedToken() { return selectedToken; } public void setSelectedToken(ClaimSelectedToken selectedToken) { this.selectedToken = selectedToken; } public List getJibxNextTokens(){ List l = new Vector(); if (nextTokens != null){ l.addAll(nextTokens); } return l; } public List getJibxIdentifiers(){ List l = new Vector(); if (identifiers != null){ l.addAll(identifiers); } return l; } public List getJibxVariables(){ List l = new Vector(); if (variables != null){ l.addAll(variables); } return l; } public String getExpression() { return expression; } public void setExpression(String expression) { this.expression = expression; } public String getPlural() { return plural; } public void setPlural(String plural) { this.plural = plural; } public List getIdentifiers() { return identifiers; } public void setIdentifiers(List identifiers) { this.identifiers = identifiers; } public List getVariables() { return variables; } public void setVariables(List variables) { this.variables = variables; } public List getNextTokens() { return nextTokens; } public void setNextTokens(List nextTokens) { this.nextTokens = nextTokens; } } A sample JiBX XML-OO mapping ========================== <mapping name="claim" class=" org.cruk.aspic.editor.model.Claim"> <value name="id" field="id"/> <value name="expression" field="expression"/> <structure name="nextTokens"> <collection field="nextTokens" type="java.util.Vector" get-method="getJibxNextTokens"> <!-- JiBX croaks on the default hibernate collections implementation --> <structure name="nextToken" type="org.cruk.aspic.editor.model.ClaimToken" ordered="false" allow-repeats="true" usage="optional"> <value style="attribute" name="enabled" field="enabled"/> <value name="id" field="id" usage="optional"/> <value name="syntax" field="syntax" usage="optional"/> </structure> </collection> </structure> <structure name="variables"> <collection field="variables" type="java.util.Vector" get-method="getJibxVariables"> <structure name="variable" type="org.cruk.aspic.editor.model.ClaimVariable" ordered="false" allow-repeats="true"> <value name="id" field="id"/> <value name="name" field="name"/> </structure> </collection> </structure> My Hibernate Mapping: ======================== <hibernate-mapping> <class name="org.cruk.aspic.editor.model.Claim" table="claim" > <id name="id" type="long" column="ID" length="11" unsaved-value="-1"> <generator class="identity"/> </id> <property name="queryString" type="string" column="querystring" length="2000"/> </class> </hibernate-mapping> My XPL: ============ <p:config xmlns:p="http://www.orbeon.com/oxf/pipeline" xmlns:oxf="http://www.orbeon.com/oxf/processors " xmlns:aspic="http://www.cruk.com/aspic/editor/v1"> <p:param name="instance" type="input"/> <p:param name="data" type="output"/> <p:processor name="oxf:java"> <p:input name="config"> <config sourcepath="oxf:/java" class="org.cruk.aspic.editor.api.orbeon.GetNextClaimEditorTokens "/> </p:input> <p:input name="data" href="#instance"/> <p:output name="data" ref="data" debug="output"/> </p:processor> ... And that's how I did it. The main point is to get the mapping from OO to XML done properly :-) Hope this helps. Henrik On 8/22/06,
Vikas Sasidharan <[hidden email]> wrote:
-- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Administrator
|
In reply to this post by Vikas Sasidharan
Vikas,
> Even after reading the exhaustive OPS documentation, I am afraid it > is still not very clear to me as to what is the recommended way of > using a java object as a dynamic xforms instance in the PFC view. That's probably because we try to encourage OPS users to deal with as little Java as possible, ideally none ;-) This is not to say that what you are trying to do is valuable, of course. > My question, hence, is w.r.t Step (3). What is /the /best way for > the action to pass the bean to the PFC? > > For the time being, we are going by this approach: > > 1) WebWork Action retrieves the bean, puts it in request/session > scope and then redirects to a PFC page flow. So far so good. > 2) The page flow$(Bs (Bmodel is an XPL that chains the "Scope Generator" > and "Scope Serializer" processors respectively in that order; so as > to eventually get the xml$(Biz(Bed bean as the model output. The Scope generator can directly produce XML from a Java object in the request or session. Why do you need the Scope serializer at all? > 3) The page view uses this instance (using the "xi:include > href=input:data" directive) to render the final UI. This is fine, but you can do better and have your model send the XML document on its "instance" output, and then access it from XForms with: <xforms:instance src="input:instance"/> (Using input:data should ideally work as well, but that connection is not yet implemented in the PFC.) The drawback of XInclude is that from the XForms engine's perspective the result is a completely new XForms document, while with @src it is the same XForms document, just with a different initial instance. > However, we are not very comfortable with this approach and were > wondering if there is a way by which we can pass this object > directly to OPS. Any help/suggestions would be really appreciated. Overall I don't think the approach above is bad. I think the key is to make sure you write as little code as possible, and in fact I think the code in the page model can be as small as one call to the Scope generator (assuming you only have one Java object to work with). I can see an issue from an architecture point of view, which is that you have two levels of MVC: the good old Java Model 2 MVC, and the XForms MVC (with XForms models/instances vs. XForms controls). With XForms, initialization of instances is typically done either with xforms:instance/@src, or with a submission on xforms-ready. If you opt, instead of a "double-MVC" approach, for a service approach (i.e. your XForms pages "pulls" data in by calling services written in Java, PHP or whatever you like), implemented as services, I think the architecture becomes cleaner. -Erik -- Orbeon - XForms Everywhere: http://www.orbeon.com/blog/ -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
In reply to this post by Vikas Sasidharan
Hi Erik/Henrik,
Thanks a lot for your guidance. We are going ahead with the "double MVC" approach for the time being. BTW Erik, regarding your question about Scope Serializer, sorry but that was a typo from my side. We are actually chaining Scope Generator with XML Serializer (a custom one, since Castor doesn't fit our requirements). Off the topic, I would just like to add that I was really impressed by the promptness and helping mentality of the forum users including yourselves. It's great to be here. :-) Rgds, Vikas -----Original Message----- From: Erik Bruchez [mailto:[hidden email]] On Behalf Of Erik Bruchez Sent: Thursday, August 24, 2006 12:07 AM To: [hidden email] Subject: Re: [ops-users] Best practice for using java object as dynamic xforms instance in PFC view.. Vikas, > Even after reading the exhaustive OPS documentation, I am afraid it > is still not very clear to me as to what is the recommended way of > using a java object as a dynamic xforms instance in the PFC view. That's probably because we try to encourage OPS users to deal with as little Java as possible, ideally none ;-) This is not to say that what you are trying to do is valuable, of course. > My question, hence, is w.r.t Step (3). What is /the /best way for > the action to pass the bean to the PFC? > > For the time being, we are going by this approach: > > 1) WebWork Action retrieves the bean, puts it in request/session > scope and then redirects to a PFC page flow. So far so good. > 2) The page flow$(Bs (Bmodel is an XPL that chains the "Scope Generator" > and "Scope Serializer" processors respectively in that order; so as > to eventually get the xml$(Biz(Bed bean as the model output. The Scope generator can directly produce XML from a Java object in the request or session. Why do you need the Scope serializer at all? > 3) The page view uses this instance (using the "xi:include > href=input:data" directive) to render the final UI. This is fine, but you can do better and have your model send the XML document on its "instance" output, and then access it from XForms with: <xforms:instance src="input:instance"/> (Using input:data should ideally work as well, but that connection is not yet implemented in the PFC.) The drawback of XInclude is that from the XForms engine's perspective the result is a completely new XForms document, while with @src it is the same XForms document, just with a different initial instance. > However, we are not very comfortable with this approach and were > wondering if there is a way by which we can pass this object > directly to OPS. Any help/suggestions would be really appreciated. Overall I don't think the approach above is bad. I think the key is to make sure you write as little code as possible, and in fact I think the code in the page model can be as small as one call to the Scope generator (assuming you only have one Java object to work with). I can see an issue from an architecture point of view, which is that you have two levels of MVC: the good old Java Model 2 MVC, and the XForms MVC (with XForms models/instances vs. XForms controls). With XForms, initialization of instances is typically done either with xforms:instance/@src, or with a submission on xforms-ready. If you opt, instead of a "double-MVC" approach, for a service approach (i.e. your XForms pages "pulls" data in by calling services written in Java, PHP or whatever you like), implemented as services, I think the architecture becomes cleaner. -Erik -- Orbeon - XForms Everywhere: http://www.orbeon.com/blog/ -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Administrator
|
Vikas Sasidharan wrote:
> Hi Erik/Henrik, > > Thanks a lot for your guidance. We are going ahead with the "double MVC" > approach for the time being. > > BTW Erik, regarding your question about Scope Serializer, sorry but that > was a typo from my side. We are actually chaining Scope Generator with > XML Serializer (a custom one, since Castor doesn't fit our > requirements). > > Off the topic, I would just like to add that I was really impressed by > the promptness and helping mentality of the forum users including > yourselves. It's great to be here. :-) -Erik -- Orbeon - XForms Everywhere: http://www.orbeon.com/blog/ -- You receive this message as a subscriber of the [hidden email] mailing list. To unsubscribe: mailto:[hidden email] For general help: mailto:[hidden email]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws |
Free forum by Nabble | Edit this page |