cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "JD Daniels" ...@datatrio.com>
Subject RE: XMLizing your business obejcts
Date Sat, 15 Nov 2003 02:56:28 GMT
I think this is where quite a few of us are at.

for me, flow + woody + OJB is my ideal solution. The model controller, flow,
instantiates your business objects and passes bean states to cocoon
pipelines.. which at this point would be only views of data (with jxpath and
such, they only contain place holders) , which are transformed into well,
whatever you need. Unfortuneately, I am a java newbie, so am still
struggling with OJB and actually making my beans in general :S

however, even though i have to use xsp ATM, when I get ojb figured out, it
should be a simple matter of changing my flow.. my xsl and xml dtds do not
need to change. Already there is a great separation of concerns for me.

Right from the petstore sample:

function viewItem() {
    var itemId = cocoon.request.getParameter("itemId");
    var item = getPetStore().getItem(itemId);
    cocoon.sendPage("view/Item" + EXT, {
             accountForm: accountForm,
             cartForm: cartForm,
             item: item,
             quantity:
getPetStore().getItemRowCountByProduct(item.productId),
             product: item.product,
             fmt: fmt
    });
}

Obviously, the petstore.item class does not know where its data is coming
from or going.

So in short.... I think you are looking for flow :)

JD

-----Original Message-----
From: Justin Fagnani-Bell [mailto:justin@paraliansoftware.com]
Sent: Friday, November 14, 2003 5:35 PM
To: users@cocoon.apache.org
Subject: XMLizing your business obejcts


As I'm rethinking the object-persistence persistence for my web app,
I'm also looking for a better way to output XML from my java objects.
Can't really find much on the wiki.

Currently the XML is output in my presentation layer (something like
XSPs), but this is leading to too much copy-and-paste and not enough
reuse right now. Let's use a shopping cart system as an example.

We'll have classes like Customer, Order, Product, and pages or views
like ViewProduct, ListProducts, EditProduct.

For each of the views I need basically the same XML representation of
the product (though I may want a stripped down version for the list).
Right now I have code in each view that's something like:

<product>
	<xsp:attribute
name="id"><xsp:expr>product.getID()</xsp:expr></xsp:attribute>
	<xsp:attribute
name="code"><xsp:expr>product.getCode()</xsp:expr></xsp:attribute>
</product>

I'd rather just say something like product.printXML(contentHandler), or
MyUtilityClass.printXML(product) but I have issues with every way, so
I'm wondering what the Official Cocoon Best Practices are...

I see a few basic methods and variations to accomplish this:
1) The class outputs the XML to a ContentHandler
	This method is nice and clean, but I have a problem with the class
outputing the XML. I just don't think the application object should be
concerned with the presentation layer. In the next few months I'll be
working on a project where the business objects are already implemented
(i'm just creating a new front end) and I want to apply my method
there.

1a) A subclass handles the XML output.
	This seems cleaner to me than 1) since the base class doesn't have to
know about XML, but it seems like some problems could crop up. First
you won't always know that you're getting an XML enabled class from
certain methods. If my persistance layer knows to instantiate the XML
capable classes then things are fine, but if one of the business
obejcts constructs another business object using the base class then
things break. I think this method would require a contract that all
business objects be created through a factory.

The main advantage of 1) is that if I add a new class to the system, I
implement the XML output with he class and drop it in. I don't have to
modify a utility class.

2) A third class handles the output
2a) A single utility class handles output for all application classes
with methods like printProduct(Product p, ContentHandler ch)
	Seperates the XML layer from the business objects
2b) A seperate class for each business class handles the output.
	Potentially lots of classes. Adding a new class requires updating of
the utility class.

2c) Every business object is a Bean and you have one method that will
print the properties of a bean to XML
	Nice and general, works for classes that aren't created with XML in
mind. Could be innefficient, not every property needs to be output.
Can't specify the element and attribute names. Can't specify how to
handle collections.

Ok, this email is getting long... so I'll wrap it up :) I know Cocoon
makes use of XMLizers in some of the generators. Is this the best way
to go for business objects too? I haven't fond too much information on
it yet. Does it require a lookup method for finding the right XMLizer
to use?

Thanks ahead of time,
   Justin


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



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


Mime
View raw message