On 7/18/2012 12:42 PM, Jacques Le Roux wrote:
From: "Adrian Crum" <adrian.c...@sandglass-software.com>
On 7/18/2012 4:19 AM, Scott Gray wrote:
On 18/07/2012, at 8:09 AM, Adrian Crum wrote:
On 7/17/2012 2:47 PM, Jacopo Cappellato wrote:
On Jul 16, 2012, at 11:50 AM, Adrian Crum wrote:
The next steps for the future will be to move out of the
framework the folders in the "images" application that are
specific to applications (somewhere under runtime seems a good
approach).
Some of the application-specific content could be used by other
applications, so it should stay in the resources component.
Anything that is truly application-specific should be kept in the
application. The application-specific content can be added to the
application's URL path. If that causes problems with other
applications trying to access it (I'm thinking of the product
content), then we might need to re-engineer some things to
accommodate that. Putting content in the runtime folder sounds
odd to me.
The goal that I would like to achieve in the long term is the
following: the framework/applications folders, once deployed
should be read only and should not contain files that are
generated at runtime; at the moment the images folder is an
exception because, for example, when you upload an image the image
is stored under framework/images/webapp/images (by default); for
this I think that runtime would be a better fit. On the other hand
I agree that static resources could be hosted in the respective
component.
But I am not planning to work on this sometime soon... we have
time to think.
I know the purpose of the images web app was to provide the
capability to host static content separately, and there are things
like Freemarker transforms and such that point to that static
content. The problem is, static content might be hosted in more
than one place, or in more than one way (in a content repository).
I'm thinking along the same path as BJ - maybe static content
should be accessed through the Content component or a similar
mechanism. Then the static content could reside anywhere.
I agree that uploaded files need their own folder. Again, that
could be handled by the Content component or a similar mechanism.
Uploaded files going into the runtime folder makes sense.
-Adrian
For busy sites you really don't want to be serving static content
via OFBiz. Apache or Tomcat are much better at that than we will
ever be.
Regards
Scott
Agreed. But there are also things like product brochures or owners
manuals that are not simple gif files - they are documents under
version control and in some cases are kept in an existing content
repository outside of OFBiz.
Maybe we could have a protocol similar to our "component://" protocol
that makes it easy to reference content. Something like:
content://static/images/smiley.gif
content://repo/brochures/Widget.pdf
etc...
-Adrian
This sounds like a good idea to me, but then some another idea pop up
in my head: should we not try to couple that with the JackRabbit effort?
Jacques
You could integrate it with just about anything.
-Adrian
