forrest-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Catalogue application (Re: Dispatcher ClassCastException)
Date Sun, 25 Jun 2006 19:20:15 GMT
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.

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

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.

Ross

Mime
View raw message