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?
Brian
- OSCommerce input plugin Brian M Dube
-
