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