Best practice for using java object as dynamic xforms instance in PFC view..

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Best practice for using java object as dynamic xforms instance in PFC view..

Vikas Sasidharan

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"
Whatever is said in Latin, sounds profound

 



--
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
Reply | Threaded
Open this post in threaded view
|

Re: Best practice for using java object as dynamic xforms instance in PFC view..

Henrik Pettersen
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:

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"
Whatever is said in Latin, sounds profound

 



--
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: <a onclick="bluecoat_allow_popup=true;try{ return top.js.OpenExtLink(window,event,this) }finally{bluecoat_allow_popup=false;}" href="http://www.objectweb.org/wws" target="_blank">http://www.objectweb.org/wws





--
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
Reply | Threaded
Open this post in threaded view
|

Re: Best practice for using java object as dynamic xforms instance in PFC view..

Erik Bruchez
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
Reply | Threaded
Open this post in threaded view
|

RE: Best practice for using java object as dynamic xforms instance in PFC view..

Vikas Sasidharan
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
Reply | Threaded
Open this post in threaded view
|

Re: Best practice for using java object as dynamic xforms instance in PFC view..

Erik Bruchez
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. :-)
Thanks, that's very much appreciated :-)

-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