Brian M Dube wrote:
Regarding the data extraction, I've found it necessary to add attributes
to the OSCommerce templates to trigger the transformation rules. The
output is otherwise rather ambiguous and difficult to parse. How do you
feel about requiring these changes to use the plugin? The alternative
would have to include very clever stylesheets to account for the user's
settings: various default OSCommerce boxes turned off or custom boxes
added. Your thoughts?
It sounds to me like you are planning on scraping the output of the
OSCommerce PHP scripts. I'm not keen on this for two reasons:
1) it requires the user to modify their OSCommerce installation
2) it will be difficult to keep up with all the potential customisations
users may add.
Instead of scraping, I was thinking of extracting the content directly
from the OSCommerce back end. I don't want to be completely tied to
OSCommerce, in fact, ultimately, I want a plugin that will work with any
shopping cart system with the minimum of configuration.
To achieve this I was planning on the following (slightly simplified for
clarity):
.--------.
.------. .-----------. .------------. .---------. | HTML |
| | | | | | | |-->`--------'
| DB |<--->| Hibernate |--->| Generator |--->| Forrest | .--------.
| | | | | | | |-->| PDF |
`------' `-----------' `------------' `---------' `--------'
| | .--------.
`----------------`------->| XML |
`--------'
My reasoning for this design is because I need to provide a variety of
custom interfaces to the system, Forrest is only being used for the
publication of static versions of the catalogue and for B2B publishing.
In my case there is already a Struts front end that needs to be
integrated, we also need to develop a custom app for PDA's (this will
probably be done with Cocoon Forms). These alternative clients, which
include OSCommerce and the custom PHP scripts you mention, would plugin
in like this:
.--------.
.------. .-----------. .------------. .---------. | HTML |
| | | | | Cocoon | | |-->`--------'
| DB |<--->| Hibernate |--->| Generator |--->| Forrest | .--------.
| | | | | | | |-->| PDF |
`------' `-----------' `------------' `---------' `--------'
| | | .--------.
| `----------------`------->| XML |
| `--------'
| .------------.
`---------->| Client |
`------------'
The Cocoon generator outputs a custom XML format (actually it is just an
XML dump of the bean, but it could be a defined format). Forrest uses an
internal stylesheet to convert this to XDoc and then we use the normal
skinning/dispatcher frameworks to create the output.
Previously I had built custom generators for each type of information
(product, category, feature etc.), but this got too difficult to
maintain so I have scrapped the idea. The above is much cleaner since
the majority of the work is done in an base generator class that,
through the magic of Spring, can create XML from pretty much any Data
access object (one of the simplifications in the above diagram is that
the DAO layer is missing between hibernate and Cocoon).
I played around with this last night. It works well. Currently my plugin
only creates a base Product XML document, but as a proof of concept it
works well.
What do you think?
Ross
