You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@forrest.apache.org by David Crossley <cr...@apache.org> on 2006/06/24 02:58:23 UTC

Re: Catalogue application

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.

Yes, i reckon define a default schema and supply the
schema and stylesheets and sitemap for this.

The system is extensible. So the user can add alternative
implementations, or enhancements by extending the default.

Don't forget that you don't need to use DTDs, as they
are just one way. Another option would be to supply
RELAX NG schema. The sitemap can use a SourceTypeAction [1]
content aware pipeline that responds to the namespace.
Validation capabilities can be added if you want it. [2]

[1] http://forrest.apache.org/docs/cap.html
[2] http://forrest.apache.org/howto-dev.html#debug-validation

> >Not sure what you mean here. Plugins can include a DTD's - they go in 
> >resources/schema. You need to reference them in the catalog.xcat file in 
> >the same directory. See the ListLocations plugin for an example.
> >
> >>I really don't know which is easier for a future user of such a 
> >>plugin. I think the most flexible option would be internal support for 
> >>popular schemata with the option of extending the plugin with 
> >>user-defined schemata. Does this sound reasonable?
> >
> >Yes, that is the approach I was planning to take. For my use case I need 
> >to pull the data from an OSCommerce back end. I was planing on 
> >converting it to a "popular schema" and then going from their into XDoc 
> >for Forrest (it's a static publish so performance is not a key issue).
>
> 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'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. It would be nice if the 
> plugin could create the necessary form input methods, but I see no 
> support for this in XDoc.

Would you be able to describe a bit more about your use-case?

This might be possible with Forrest, though i wonder if anyone
has tried it. Cocoon has a "forms" framework.

Now we get into the issue of where does Forrest's scope extend.

Another option, rather than doing everything within Forrest,
might be to create a Cocoon application which runs on a
different port. Then Forrest can obtain its data from there.

-David