forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: OSCommerce input plugin
Date Tue, 27 Jun 2006 09:03:03 GMT
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 

.------.     .-----------.    .------------.    .---------.   |  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?


View raw message