You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Jacopo Cappellato <ja...@hotwaxmedia.com> on 2012/07/16 11:40:03 UTC
Proposal: merging framework/images into framework/resources
As a first step in the review/cleanup of the "images" component I am proposing to move its content, i.e. the "images" webapp, to the framework/resources, transforming it into a component that will mount the "images" application.
This is a trivial change but in my opinion "resources" is a more appropriate component name than "images".
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).
What do you think?
Jacopo
Re: Proposal: merging framework/images into framework/resources
Posted by BJ Freeman <bj...@free-man.net>.
what is the goal?
How will mounting Resources independent effect the operation of Ofbiz?
why not stick with Content with a Resources Webapp?
<DataResourceType dataResourceTypeId="IMAGE_OBJECT" description="Image"
hasTable="Y" parentTypeId=""/>
on the second part as long as the reference to resources in done by
content method, instead of absolute location, then where it is located
is a matter of changing the Content record.
Jacopo Cappellato sent the following on 7/16/2012 2:40 AM:
> As a first step in the review/cleanup of the "images" component I am proposing to move its content, i.e. the "images" webapp, to the framework/resources, transforming it into a component that will mount the "images" application.
> This is a trivial change but in my opinion "resources" is a more appropriate component name than "images".
> 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).
>
> What do you think?
>
> Jacopo
>
>
Re: Proposal: merging framework/images into framework/resources
Posted by BJ Freeman <bj...@free-man.net>.
I vaguely remember the discussion on Jackrabbit.
and I do have the jackrabbit branch in my personal SVN.
we (my team) has been going through the content component.
we are far from finished with the evaluation, since it is just one we
are doing a design review on. The Goal is to have it meet all our needs
for the different vertical markets we are targeting.
if an appropriate place is given, would be glad to post when we have the
review finished.
I will have one of the team review Jackrabbit from the Ofbiz ML and the
repository, and give a report, which i will glad to share.
I think the scope of this thread is too limited and should be broaden to
all content handling.
Jacques Le Roux sent the following on 7/17/2012 3:42 PM:
> Jackrabbit implements Java Specification Request 170
> http://jackrabbit.apache.org/frequently-asked-questions.html
>
> What is a content repository?
> A content repository is an information management system that provides
> various services for storing, accessing, and managing
> content. In addition to a hierarchically structured storage, common
> services of a content repository are versioning, access control,
> full text searching, and event monitoring. A content repository is not a
> content management system (CMS), although most existing
> CMSs contain a custom content repository implementation, often based on
> the file system or a relational database.
>
> Hence come with versionning embedded.
>
> Note this section:
> What is a Jackrabbit file system?
> A Jackrabbbit file system (FS) is an internal component that implements
> standard file system operations on top of some underlying
> storage mechanism (a normal file system, a database, a webdav server, or
> a custom file format). A file system component is any Java
> class that implements the FileSystem interface and the associated
> behavioral contracts. File systems are used in Jackrabbit both as
> subcomponents of the persistence managers and for general storage needs
> (for example to store the full text indexes).
>
> But of course yes, you can also use SVN on a file system. Jackrabbit
> just offers more choices and has already a lot of knowledge
> embedded.
>
> Note that there is already a Jackrabbit effort going on in the
> jackrabbit20120501 branch
> https://svn.apache.org/repos/asf/ofbiz/branches/jackrabbit20120501
> Mostly sustained by Sascha so far...
>
> Jacques
>
> From: "BJ Freeman" <bj...@free-man.net>> to add another layer to this,
> how about using SVN for versioning, as
>> well as storage.
>> The would be managed through the content component.
>> I am not totally familiar with Jackrabbit.
>> But maybe the SVN solution would also take care of Jackrabbit
>> requirements.
>>
>> Jacques Le Roux sent the following on 7/17/2012 1:53 PM:
>>>
>>>>> 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-
>
Re: Proposal: merging framework/images into framework/resources
Posted by Jacques Le Roux <ja...@les7arts.com>.
Jackrabbit implements Java Specification Request 170 http://jackrabbit.apache.org/frequently-asked-questions.html
What is a content repository?
A content repository is an information management system that provides various services for storing, accessing, and managing
content. In addition to a hierarchically structured storage, common services of a content repository are versioning, access control,
full text searching, and event monitoring. A content repository is not a content management system (CMS), although most existing
CMSs contain a custom content repository implementation, often based on the file system or a relational database.
Hence come with versionning embedded.
Note this section:
What is a Jackrabbit file system?
A Jackrabbbit file system (FS) is an internal component that implements standard file system operations on top of some underlying
storage mechanism (a normal file system, a database, a webdav server, or a custom file format). A file system component is any Java
class that implements the FileSystem interface and the associated behavioral contracts. File systems are used in Jackrabbit both as
subcomponents of the persistence managers and for general storage needs (for example to store the full text indexes).
But of course yes, you can also use SVN on a file system. Jackrabbit just offers more choices and has already a lot of knowledge
embedded.
Note that there is already a Jackrabbit effort going on in the jackrabbit20120501 branch
https://svn.apache.org/repos/asf/ofbiz/branches/jackrabbit20120501
Mostly sustained by Sascha so far...
Jacques
From: "BJ Freeman" <bj...@free-man.net>> to add another layer to this, how about using SVN for versioning, as
> well as storage.
> The would be managed through the content component.
> I am not totally familiar with Jackrabbit.
> But maybe the SVN solution would also take care of Jackrabbit requirements.
>
> Jacques Le Roux sent the following on 7/17/2012 1:53 PM:
>>
>>>> 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-
Re: Proposal: merging framework/images into framework/resources
Posted by BJ Freeman <bj...@free-man.net>.
to add another layer to this, how about using SVN for versioning, as
well as storage.
The would be managed through the content component.
I am not totally familiar with Jackrabbit.
But maybe the SVN solution would also take care of Jackrabbit requirements.
Jacques Le Roux sent the following on 7/17/2012 1:53 PM:
>
>>> 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-
Re: Proposal: merging framework/images into framework/resources
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Adrian Crum" <ad...@sandglass-software.com>
> 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
This makes sense to me. But then should we not put the Jackrabbit effort in the scope? Having a way to use a versionning system on
contents is obviously a must have. Notably when it comes to move contents from staging/qa to production. This is uneasy with
contents in DB.
Jacques
Re: Proposal: merging framework/images into framework/resources
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 7/18/2012 12:42 PM, Jacques Le Roux wrote:
> From: "Adrian Crum" <ad...@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
Re: Proposal: merging framework/images into framework/resources
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Adrian Crum" <ad...@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
Re: Proposal: merging framework/images into framework/resources
Posted by BJ Freeman <bj...@free-man.net>.
I understand, it was more address scotts comment about speed, and your
suggestion about using the componet:// as a model.
As I stated I think that a thread should start with Content as the scope
with the resources being part of that.
Adrian Crum sent the following on 7/18/2012 3:35 AM:
> I don't think speed enhancement is a goal here. Jacopo is trying to find
> a better way to organize static content and uploaded files.
>
> -Adrian
>
> On 7/18/2012 11:28 AM, BJ Freeman wrote:
>> though the content:// makes it easier from a programming point of
>> view, if you take the underlying code it takes to generate the output,
>> I don't think you will find much speed enhancement.
>> Maybe a seperate thread on top down Content management would be in
>> order, and this topic would be covered under that.
>> I propose a design review of the Content Component.
>>
>>
>> Adrian Crum sent the following on 7/17/2012 9:47 PM:
>>> 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
>>>
>>>
>>>
>
>
>
Re: Proposal: merging framework/images into framework/resources
Posted by Adrian Crum <ad...@sandglass-software.com>.
I don't think speed enhancement is a goal here. Jacopo is trying to find
a better way to organize static content and uploaded files.
-Adrian
On 7/18/2012 11:28 AM, BJ Freeman wrote:
> though the content:// makes it easier from a programming point of
> view, if you take the underlying code it takes to generate the output,
> I don't think you will find much speed enhancement.
> Maybe a seperate thread on top down Content management would be in
> order, and this topic would be covered under that.
> I propose a design review of the Content Component.
>
>
> Adrian Crum sent the following on 7/17/2012 9:47 PM:
>> 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
>>
>>
>>
Re: Proposal: merging framework/images into framework/resources
Posted by BJ Freeman <bj...@free-man.net>.
though the content:// makes it easier from a programming point of view,
if you take the underlying code it takes to generate the output, I don't
think you will find much speed enhancement.
Maybe a seperate thread on top down Content management would be in
order, and this topic would be covered under that.
I propose a design review of the Content Component.
Adrian Crum sent the following on 7/17/2012 9:47 PM:
> 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
>
>
>
Re: Proposal: merging framework/images into framework/resources
Posted by Adrian Crum <ad...@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
Re: Proposal: merging framework/images into framework/resources
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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
Re: Proposal: merging framework/images into framework/resources
Posted by Adrian Crum <ad...@sandglass-software.com>.
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
Re: Proposal: merging framework/images into framework/resources
Posted by 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
>
Re: Proposal: merging framework/images into framework/resources
Posted by 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
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
Posted by 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; 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.
Jacopo
Re: Proposal: merging framework/images into framework/resources
Posted by Adrian Crum <ad...@sandglass-software.com>.
On 7/16/2012 10:40 AM, Jacopo Cappellato wrote:
> As a first step in the review/cleanup of the "images" component I am proposing to move its content, i.e. the "images" webapp, to the framework/resources, transforming it into a component that will mount the "images" application.
> This is a trivial change but in my opinion "resources" is a more appropriate component name than "images".
I agree.
> 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.
-Adrian