Re: Proposal: merging framework/images into framework/resources

[Deepak Dixit <de...@hotwaxmedia.com>]

Hi Folks,

Any update on this?

IMO moving static resources from images to resources is good. 
We can do logical grouping as well to make it easily readable ie. we can move all the js files and library under resources/js and same applies to css and images (related to js and css file) as well.


Thanks & Regards
—
Deepak Dixit


On Jul 18, 2012, at 5:23 PM, Jacques Le Roux <ja...@les7arts.com> wrote:

> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>> 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
> 
> +1, it has allways disturbed me (not too much though)
> 
>> ; 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.
> 
> Why not a JackRabbit content repo? I think, in the long term, it would give us more power on content. This could be a second phase though, since JackRabbit could relies on runtime folder/s.
> 
>> On the other hand I agree that static resources could be hosted in the respective component.
> 
> I agree too, easier to retrieve, but those have to be really static resources. In my opininon, any not static content resources should be handled by JackRabbit embedeed inside of OFBiz. I did not work on it yet, may be using it beside/outside could be done. But, since Sascha has already done a part of the work, I think this (JackRabbit embedded) should be really envisioned by the team and discussed before coding only our own (of course the idea is to delegate as much a possible).
> 
> Jacques
> 
>> 
>> But I am not planning to work on this sometime soon... we have time to think.
>> 
>> Jacopo

Re: Proposal: merging framework/images into framework/resources

[Deepak Dixit <de...@hotwaxmedia.com>]

Here is the task id for the same OFBIZ-5776

Thanks & Regards
—
Deepak Dixit

On Sep 18, 2014, at 5:23 PM, Deepak Dixit <de...@hotwaxmedia.com> wrote:

> Hi Folks,
> 
> Any update on this?
> 
> IMO moving static resources from images to resources is good. 
> We can do logical grouping as well to make it easily readable ie. we can move all the js files and library under resources/js and same applies to css and images (related to js and css file) as well.
> 
> 
> Thanks & Regards
> —
> Deepak Dixit
> 
> 
> On Jul 18, 2012, at 5:23 PM, Jacques Le Roux <ja...@les7arts.com> wrote:
> 
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>> 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
>> 
>> +1, it has allways disturbed me (not too much though)
>> 
>>> ; 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.
>> 
>> Why not a JackRabbit content repo? I think, in the long term, it would give us more power on content. This could be a second phase though, since JackRabbit could relies on runtime folder/s.
>> 
>>> On the other hand I agree that static resources could be hosted in the respective component.
>> 
>> I agree too, easier to retrieve, but those have to be really static resources. In my opininon, any not static content resources should be handled by JackRabbit embedeed inside of OFBiz. I did not work on it yet, may be using it beside/outside could be done. But, since Sascha has already done a part of the work, I think this (JackRabbit embedded) should be really envisioned by the team and discussed before coding only our own (of course the idea is to delegate as much a possible).
>> 
>> Jacques
>> 
>>> 
>>> But I am not planning to work on this sometime soon... we have time to think.
>>> 
>>> Jacopo
>