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 Ross Gardler
-
