You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@forrest.apache.org by Brian M Dube <br...@gmail.com> on 2006/06/22 04:58:30 UTC
Dispatcher ClassCastException
I'm building a site with 0.8-dev using dispatcher. I created a free-form
(well-formed, but no DTD) XML file that describes the items for sale
along with their options. I'm using the locationmap and sitemap to
provide virtual URLs to view the items in the master file. When I
request a resource that exists, such as
http://localhost:8888/index.html, everything works fine. When I request
one of the virtual URLs, such as
http://localhost:8888/products/categoryX/itemY.html, it works as
intended but this error is also produced on the console:
cocoon://resolve.contract.html.nav-section; Line #0; Column #0;
java.lang.ClassCastException. Static mode also builds successfully while
reporting the same exception.
In either case the resource is rendered, but the nav-section contract
doesn't finish and the menu is compromised. I haven't been able to trace
the exception to its cause. Has anyone seen this? I have a custom theme
but I'm not implementing a custom nav-section contract.
Brian
Re: Catalogue application
Posted by David Crossley <cr...@apache.org>.
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
Re: Another Forrest reference site: G11NToolKit
Posted by David Crossley <cr...@apache.org>.
I added that, thanks.
-David
bill/wilandra wrote:
> The home page for the G11NToolKit project on SourceForge is generated using
> Forrest.
> http://g11ntoolkit.sourceforge.net
>
> I am still learning how to use Forrest so any constructive critisism is
> welcome.
>
> Thanks. Bill
>
> Bill Rich
> Wilandra Consulting LLC
> 421 34th Avenue
> Santa Cruz, CA 95062-5102
> mobile: +1 408 410-9713
> Santa Cruz: +1 831 464-9007
> eFax: +1 413 669-9716
> Skype: wfr0766
> bill@wilandra.com
> http://www.wilandra.com
>
Re: OSCommerce input plugin
Posted by Brian M Dube <br...@gmail.com>.
Ross Gardler wrote:
> Brian M Dube wrote:
>> I'm sorry I failed to mention that I'm now using
>> whiteboard/org.apache.forrest.plugin.Database to generate the data.
>> Thank you for pointing out that it is possible, and better, to access
>> the back end directly.
>
> Cool, but my new approach for talking to the database (i.e. hibernate)
> is better from a maintenance point of view as it doesn't tie us to a
> specific back end. Furthermore it provides POJO's for manipulating the
> data. It works in a limited fashion and is already more complete with
> respect to getting data out of an OSCommerce back end than the raw
> database plugin.
> Would you like me to send it to you offlist so you can have a look at
> the proof of concept?
Thank you, I would like to see it.
> Since you still seem to be at a very early stage I'd love for us to work
> together on this code, I can put it in an SVN repository and make it
> available under LGPL (hibernate restriction). I'd prefer to make it
> ASL2, but would need more time to cleanly separate the dependencies so
> that will have to come later.
>
> I don't think July 18th will be a problem unless you are a long way down
> the road to implementation using the database plugin. In which case we
> should go our separate ways until you have more breathing space then we
> can bring the two solutions together into a finished product.
I don't have much time invested in the database plugin. I only recently
got it working. When I look at how you're using Hibernate, I'll have a
better idea whether I should switch now or keep going with what I have.
Brian
Re: OSCommerce input plugin
Posted by Ross Gardler <rg...@apache.org>.
Brian M Dube wrote:
> Ross Gardler wrote:
>
>> Brian M Dube wrote:
>>
>>> Due to the approaching deadline for this project, I'm going to
>>> proceed with the code in place.
>>
>>
>> When is your deadline and exactly what do you need Forrest to output
>> by that date? Unless you are a long way down the road with your
>> scraping code I would suggest that using the plugin woud be faster for
>> you as it only involves writing stylesheets to provide the required
>> output format. Well, that's not wuite true, there is some Java code
>> that needs writing too, but the framework is in place so the code
>> needed is pretty much "standard fare", such as creating the XML
>> representatin of each bean as a string.
>
>
> We leave for an extended business trip 18 July. The powers that be would
> like to see the catalog done before we leave.
>
> I'm sorry I failed to mention that I'm now using
> whiteboard/org.apache.forrest.plugin.Database to generate the data.
> Thank you for pointing out that it is possible, and better, to access
> the back end directly.
Cool, but my new approach for talking to the database (i.e. hibernate)
is better from a maintenance point of view as it doesn't tie us to a
specific back end. Furthermore it provides POJO's for manipulating the
data. It works in a limited fashion and is already more complete with
respect to getting data out of an OSCommerce back end than the raw
database plugin.
>> I can't put the code in our SVN as it uses Hibernate which is LGPL. I
>> can make it available in a private repository, and move it into a
>> plugins project on sourceforge when it is set up.
>
>
> I get an error running the Hibernate example, java.sql.SQLException:
> Duplicate entry. That sounds like an issue with the test data, so I
> think the installation is fine. I haven't yet grasped how to add it into
> the mix.
Not sure what you mean by the "hibernate example", but my current plugin
work already has that sorted out so you can pretty much leave this part
to me. You can focus on the POJO's to represent the model and the XSLT's
to render the model as you need it. I can focus on the glue between the
database the POJO's and Forrest.
Would you like me to send it to you offlist so you can have a look at
the proof of concept?
Since you still seem to be at a very early stage I'd love for us to work
together on this code, I can put it in an SVN repository and make it
available under LGPL (hibernate restriction). I'd prefer to make it
ASL2, but would need more time to cleanly separate the dependencies so
that will have to come later.
I don't think July 18th will be a problem unless you are a long way down
the road to implementation using the database plugin. In which case we
should go our separate ways until you have more breathing space then we
can bring the two solutions together into a finished product.
Ross
Re: OSCommerce input plugin
Posted by Brian M Dube <br...@gmail.com>.
Ross Gardler wrote:
> Brian M Dube wrote:
>> Due to the approaching deadline for this project, I'm going to proceed
>> with the code in place.
>
> When is your deadline and exactly what do you need Forrest to output by
> that date? Unless you are a long way down the road with your scraping
> code I would suggest that using the plugin woud be faster for you as it
> only involves writing stylesheets to provide the required output format.
> Well, that's not wuite true, there is some Java code that needs writing
> too, but the framework is in place so the code needed is pretty much
> "standard fare", such as creating the XML representatin of each bean as
> a string.
We leave for an extended business trip 18 July. The powers that be would
like to see the catalog done before we leave.
I'm sorry I failed to mention that I'm now using
whiteboard/org.apache.forrest.plugin.Database to generate the data.
Thank you for pointing out that it is possible, and better, to access
the back end directly.
> I can't put the code in our SVN as it uses Hibernate which is LGPL. I
> can make it available in a private repository, and move it into a
> plugins project on sourceforge when it is set up.
I get an error running the Hibernate example, java.sql.SQLException:
Duplicate entry. That sounds like an issue with the test data, so I
think the installation is fine. I haven't yet grasped how to add it into
the mix.
Brian
Re: OSCommerce input plugin
Posted by Ross Gardler <rg...@apache.org>.
Brian M Dube wrote:
> Ross Gardler wrote:
>
>> Sorry, that is incorrect. OSCommerce plugs directly into the DB. I
>> don't know PHP so I'm not sure if you can make it talk to a hibernate
>> back end, so your PHP scripts may need to talk directly to the DB as
>> well. Although it could pull formatted data or raw XML from the
>> Forrest app if it needs to. This would give us:
>
>
> In my case, neither the database nor the Forrest application is
> available for PHP to query. These are separate environments. This is
> what I meant by a static publish. In the development environment is
> where I have Forrest and OSCommerce. The production environment will
> host the published documents with accompanying PHP scripts. I'll use
> MySQL in the production environment as well, but this is unrelated to
> the OSCommerce database. This difference in use cases may or may not
> impact the details of the plugin. More on that below.
>> It would be more robust, and most likely faster, to use Cocoon Forms
>> to create your client apps in the way the above diagram shows.
>> However, I understand your point about "time to learn Cocoon Forms",
>> that implementation decision is, of course, your own.
>
>
> As stated above, learning Cocoon isn't the only issue. The production
> environment makes the use of a Cocoon application very unlikely. Unless
> I misunderstand you, the client applications you describe would run in
> some sort of servlet container, right? Given the tools available in my
> production environment, the only one I'm already comfortable with is
> PHP. That makes the choice easy and I hope it clarifies my use case.
I get it. The communications with Forrest publication need not be
dynamic. For example, if you need a particular representation of a
product for a client app, just have Forrest publish it statically like
any other page and point your client at the relevant static URL.
> Due to the approaching deadline for this project, I'm going to proceed
> with the code in place.
When is your deadline and exactly what do you need Forrest to output by
that date? Unless you are a long way down the road with your scraping
code I would suggest that using the plugin woud be faster for you as it
only involves writing stylesheets to provide the required output format.
Well, that's not wuite true, there is some Java code that needs writing
too, but the framework is in place so the code needed is pretty much
"standard fare", such as creating the XML representatin of each bean as
a string.
I can't put the code in our SVN as it uses Hibernate which is LGPL. I
can make it available in a private repository, and move it into a
plugins project on sourceforge when it is set up.
Ross
Re: OSCommerce input plugin
Posted by Brian M Dube <br...@gmail.com>.
Ross Gardler wrote:
> Sorry, that is incorrect. OSCommerce plugs directly into the DB. I don't
> know PHP so I'm not sure if you can make it talk to a hibernate back
> end, so your PHP scripts may need to talk directly to the DB as well.
> Although it could pull formatted data or raw XML from the Forrest app if
> it needs to. This would give us:
In my case, neither the database nor the Forrest application is
available for PHP to query. These are separate environments. This is
what I meant by a static publish. In the development environment is
where I have Forrest and OSCommerce. The production environment will
host the published documents with accompanying PHP scripts. I'll use
MySQL in the production environment as well, but this is unrelated to
the OSCommerce database. This difference in use cases may or may not
impact the details of the plugin. More on that below.
> It would be more robust, and most likely faster, to use Cocoon Forms to
> create your client apps in the way the above diagram shows. However, I
> understand your point about "time to learn Cocoon Forms", that
> implementation decision is, of course, your own.
As stated above, learning Cocoon isn't the only issue. The production
environment makes the use of a Cocoon application very unlikely. Unless
I misunderstand you, the client applications you describe would run in
some sort of servlet container, right? Given the tools available in my
production environment, the only one I'm already comfortable with is
PHP. That makes the choice easy and I hope it clarifies my use case.
Due to the approaching deadline for this project, I'm going to proceed
with the code in place. I'll gladly collaborate in the meantime and I
still plan on switching to a plugin once it's clear the deadline will be
met. From your diagrams I think it is possible for one plugin to meet
both our needs. I haven't made use of Hibernate yet, but I'll look into it.
Brian
Re: OSCommerce input plugin
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
>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 |
> `------------'
Sorry, that is incorrect. OSCommerce plugs directly into the DB. I don't
know PHP so I'm not sure if you can make it talk to a hibernate back
end, so your PHP scripts may need to talk directly to the DB as well.
Although it could pull formatted data or raw XML from the Forrest app if
it needs to. This would give us:
.-------------.
| non-Cocoon |
.--------------.---------->| Client |
| | `-------------'
| | /|\
| | '----------------.
| | | .--------.
.------. .-----------. .------------. .---------. | HTML |
| | | | | Cocoon | | |-->`--------'
| DB |<--->| Hibernate |--->| Generator |--->| Forrest | .--------.
| | | | | | | |-->| PDF |
`------' `-----------' `------------' `---------' `--------'
| | .--------.
| `------->| XML |
\|/ `--------'
.------------.
| Cocoon |
| Client |
`------------'
It would be more robust, and most likely faster, to use Cocoon Forms to
create your client apps in the way the above diagram shows. However, I
understand your point about "time to learn Cocoon Forms", that
implementation decision is, of course, your own.
Ross
Re: OSCommerce input plugin
Posted by Ross Gardler <rg...@apache.org>.
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
clarity):
.--------.
.------. .-----------. .------------. .---------. | 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?
Ross
OSCommerce input plugin
Posted by Brian M Dube <br...@gmail.com>.
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
RE: Another Forrest reference site: G11NToolKit
Posted by bill/wilandra <bi...@wilandra.com>.
Thank you Ross. I will see what I can do to fix these points. It is good to
get someone's feedback who is using different equipment. Which browser are
you using? Bill
-----Original Message-----
From: Ross Gardler [mailto:rgardler@apache.org]
Sent: Monday, June 26, 2006 2:13 AM
To: user@forrest.apache.org
Subject: Re: Another Forrest reference site: G11NToolKit
bill/wilandra wrote:
> The home page for the G11NToolKit project on SourceForge is generated
> using Forrest.
> http://g11ntoolkit.sourceforge.net
>
> I am still learning how to use Forrest so any constructive critisism
> is welcome.
(forgive the cursive natuer of these points, I'm in a hurry, but I hope they
are constructive)
The title of your home page is being cut of when I view on my laptop with
1040 screen. I'd suggest making it shorter or putting a line break in.
The colours of your subtabs on all main tabs seems wrong.
Following the links of these subtabs takes you back to the home page.
There are too many subtabs under the user guides tab for my small laptop
screen, they wrap around and so look cluttered.
I'd suggest only usin sub tabs for whole portions of your site rather than
as an alternative navigation menu that duplicates the left nav.
Ross
Re: Another Forrest reference site: G11NToolKit
Posted by Ross Gardler <rg...@apache.org>.
bill/wilandra wrote:
> The home page for the G11NToolKit project on SourceForge is generated using
> Forrest.
> http://g11ntoolkit.sourceforge.net
>
> I am still learning how to use Forrest so any constructive critisism is
> welcome.
(forgive the cursive natuer of these points, I'm in a hurry, but I hope
they are constructive)
The title of your home page is being cut of when I view on my laptop
with 1040 screen. I'd suggest making it shorter or putting a line break in.
The colours of your subtabs on all main tabs seems wrong.
Following the links of these subtabs takes you back to the home page.
There are too many subtabs under the user guides tab for my small laptop
screen, they wrap around and so look cluttered.
I'd suggest only usin sub tabs for whole portions of your site rather
than as an alternative navigation menu that duplicates the left nav.
Ross
Another Forrest reference site: G11NToolKit
Posted by bill/wilandra <bi...@wilandra.com>.
The home page for the G11NToolKit project on SourceForge is generated using
Forrest.
http://g11ntoolkit.sourceforge.net
I am still learning how to use Forrest so any constructive critisism is
welcome.
Thanks. Bill
Bill Rich
Wilandra Consulting LLC
421 34th Avenue
Santa Cruz, CA 95062-5102
mobile: +1 408 410-9713
Santa Cruz: +1 831 464-9007
eFax: +1 413 669-9716
Skype: wfr0766
bill@wilandra.com
http://www.wilandra.com
Re: Catalogue application (Re: Dispatcher ClassCastException)
Posted by Ross Gardler <rg...@apache.org>.
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
Re: Catalogue application (Re: Dispatcher ClassCastException)
Posted by Brian M Dube <br...@gmail.com>.
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.
> 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.
Brian
Re: Catalogue application (Re: Dispatcher ClassCastException)
Posted by Ross Gardler <rg...@apache.org>.
Brian M Dube wrote:
> Brian M Dube wrote:
>
>> Ross Gardler wrote:
>>
>>> Brian M Dube wrote:
>>>
>>>> I'm building a site with 0.8-dev using dispatcher. I created a
>>>> free-form (well-formed, but no DTD) XML file that describes the
>>>> items for sale along with their options. I'm using the locationmap
>>>> and sitemap to provide virtual URLs to view the items in the master
>>>> file.
>>>
>>>
>>> I'm just about to start experimenting with such a system. I wonder if
>>> you would be able to open source your code, I'd be happy to turn it
>>> into a plugin and assist with its development/maintenance since I
>>> have a client with this need who is keen to open source the solution.
>>
>>
>> I can provide what I have done as open source. I need to finish the
>> project as soon as possible, but the process of turning it into a
>> plugin would provide early feedback about the design. How do you want
>> to proceed?
>
>
> 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?
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'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.
Ross
Re: Catalogue application (Re: Dispatcher ClassCastException)
Posted by Brian M Dube <br...@gmail.com>.
Brian M Dube wrote:
> Ross Gardler wrote:
>> Brian M Dube wrote:
>>> I'm building a site with 0.8-dev using dispatcher. I created a
>>> free-form (well-formed, but no DTD) XML file that describes the items
>>> for sale along with their options. I'm using the locationmap and
>>> sitemap to provide virtual URLs to view the items in the master file.
>>
>> I'm just about to start experimenting with such a system. I wonder if
>> you would be able to open source your code, I'd be happy to turn it
>> into a plugin and assist with its development/maintenance since I have
>> a client with this need who is keen to open source the solution.
>
> I can provide what I have done as open source. I need to finish the
> project as soon as possible, but the process of turning it into a plugin
> would provide early feedback about the design. How do you want to proceed?
I have seeded a plugin locally. I have some questions. Does this master
file need to validate? If so, does the plugin define the schema or does
the user? 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?
Brian
Re: Catalogue application (Re: Dispatcher ClassCastException)
Posted by Brian M Dube <br...@gmail.com>.
Ross Gardler wrote:
> Brian M Dube wrote:
>> I'm building a site with 0.8-dev using dispatcher. I created a
>> free-form (well-formed, but no DTD) XML file that describes the items
>> for sale along with their options. I'm using the locationmap and
>> sitemap to provide virtual URLs to view the items in the master file.
>
> I'm just about to start experimenting with such a system. I wonder if
> you would be able to open source your code, I'd be happy to turn it into
> a plugin and assist with its development/maintenance since I have a
> client with this need who is keen to open source the solution.
I can provide what I have done as open source. I need to finish the
project as soon as possible, but the process of turning it into a plugin
would provide early feedback about the design. How do you want to proceed?
Brian
Catalogue application (Re: Dispatcher ClassCastException)
Posted by Ross Gardler <rg...@apache.org>.
Brian M Dube wrote:
> I'm building a site with 0.8-dev using dispatcher. I created a free-form
> (well-formed, but no DTD) XML file that describes the items for sale
> along with their options. I'm using the locationmap and sitemap to
> provide virtual URLs to view the items in the master file.
I'm just about to start experimenting with such a system. I wonder if
you would be able to open source your code, I'd be happy to turn it into
a plugin and assist with its development/maintenance since I have a
client with this need who is keen to open source the solution.
Ross
Re: Dispatcher ClassCastException
Posted by Thorsten Scherler <th...@wyona.com>.
El mié, 21-06-2006 a las 23:00 -0500, Brian M Dube escribió:
> Brian M Dube wrote:
> > I'm building a site with 0.8-dev using dispatcher. I created a free-form
> > (well-formed, but no DTD) XML file that describes the items for sale
> > along with their options. I'm using the locationmap and sitemap to
> > provide virtual URLs to view the items in the master file. When I
> > request a resource that exists, such as
> > http://localhost:8888/index.html, everything works fine. When I request
> > one of the virtual URLs, such as
> > http://localhost:8888/products/categoryX/itemY.html, it works as
> > intended but this error is also produced on the console:
> > cocoon://resolve.contract.html.nav-section; Line #0; Column #0;
> > java.lang.ClassCastException. Static mode also builds successfully while
> > reporting the same exception.
> >
> > In either case the resource is rendered, but the nav-section contract
> > doesn't finish and the menu is compromised. I haven't been able to trace
> > the exception to its cause. Has anyone seen this? I have a custom theme
> > but I'm not implementing a custom nav-section contract.
>
> I didn't include the nav-section-toc property in my call to the
> contract. It seems to be working now.
Nice, thanks for reporting back.
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
Re: Dispatcher ClassCastException
Posted by Brian M Dube <br...@gmail.com>.
Brian M Dube wrote:
> I'm building a site with 0.8-dev using dispatcher. I created a free-form
> (well-formed, but no DTD) XML file that describes the items for sale
> along with their options. I'm using the locationmap and sitemap to
> provide virtual URLs to view the items in the master file. When I
> request a resource that exists, such as
> http://localhost:8888/index.html, everything works fine. When I request
> one of the virtual URLs, such as
> http://localhost:8888/products/categoryX/itemY.html, it works as
> intended but this error is also produced on the console:
> cocoon://resolve.contract.html.nav-section; Line #0; Column #0;
> java.lang.ClassCastException. Static mode also builds successfully while
> reporting the same exception.
>
> In either case the resource is rendered, but the nav-section contract
> doesn't finish and the menu is compromised. I haven't been able to trace
> the exception to its cause. Has anyone seen this? I have a custom theme
> but I'm not implementing a custom nav-section contract.
I didn't include the nav-section-toc property in my call to the
contract. It seems to be working now.
Brian