forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian M Dube <>
Subject OSCommerce input plugin
Date Tue, 27 Jun 2006 01:41:32 GMT
Ross Gardler wrote:
> Brian M Dube wrote:
>> Ross Gardler wrote:
>>>> Brian M Dube wrote:
>>>> I have seeded a plugin locally. I have some questions. Does this 
>>>> master file need to validate?
>>> If there is a DTD defined in the document then it must validate.
>>>> If so, does the plugin define the schema or does the user?
>> I worded that poorly. I was asking whether the plugin should provide 
>> the DTD and thereby define the structure of the catalogue, or leave it 
>> up to the user to provide the data as well as its DTD. After some 
>> thought, the latter option doesn't make much sense. The user would 
>> also have to supply the transformation rules to get the intermediate 
>> XDoc.
> Agreed.
> ...
>> I think I will also use OSCommerce. Does that make it an OSCommerce 
>> plugin, or should the scope remain neutral in the choice of backends?
> I guess it does.
>>> I've done no research into which schema to use, so if you have one in 
>>> mind I'll just go with that - no point in splitting our efforts.
>> I haven't found anything particularly useful yet. My use case requires 
>> a choice of options for most of the products. 
> In that case I would say lets build our own internal format based on 
> XDoc. This will minimise our work. Should we need to export in some 
> standard format we can handle that in the normal Forrest way with an 
> output plugin.
> Defining our own internal format will mean we can leverage the full 
> power of Forrests data translation engine.

Yes, an internal format based on XDoc is what I was thinking. Adding 
output plugins for potential needs sounds like a good idea.

>> It would be nice if the plugin could create the necessary form input 
>> methods, but I see no support for this in XDoc.
> No, XDoc has no direct support for forms, but there are ways of 
> generating froms within Forrest as long as the internal representation 
> contains enough information to build that form.
> David replied to this message and suggested that it may not be the best 
> idea to do everything in Forrest. I agree. Forrest is a publishing 
> engine only, it is not a web application framework. It would make more 
> sense to build any dynamic stuff you need in, for example, Cocoon Forms.

With this project I don't have the time to learn how to get a Cocoon 
application running. I plan on publishing the catalogue, including the 
necessary forms, with Forrest and then implementing the form handlers 
and business logic in PHP. The catalogue will be static other than the 
PHP code to handle purchases and user data.

> Perhaps it would make sense for us to move this thread to the dev list 
> and find the common ground in our use cases, this will, at the very 
> least, be the extraction of data from an OSCommerce back end, it's worth 
> noting that I also have a need to generate limited HTML forms from the 
> data, but my main motivation for using Forrest is that I want to 
> generate careully structured PDF as well as HTML.

I also have use for PDF documents generated from the catalogue data. 
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?


View raw message