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


Reply via email to