Uploaded image for project: 'OFBiz'
  1. OFBiz
  2. OFBIZ-5776

Move static resources from framework/images to framework/resources webapp

    Details

    • Type: Improvement
    • Status: In Progress
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: Trunk
    • Fix Version/s: None
    • Component/s: framework
    • Labels:
      None
    • Sprint:
      Bug Crush Event - 21/2/2015

      Description

      Move all the static resources form images webapp to resources webapp, as they all are more related to resources rather then images.

      Also we need to rearrange these resources based on their purpose, like

      • Move all js related files and plugins under resources/js
      • Move all the css related files and plugins under resources/css
      • Move all the images related to js and css under resources/images or resources/img
      1. OFBIZ-5776.patch
        369 kB
        Deepak Dixit

        Issue Links

        There are no Sub-Tasks for this issue.

          Activity

          Hide
          deepak.dixit Deepak Dixit added a comment - - edited

          Thanks Nicolas,

          I think I wrote too short

          Proposal is to move js/css/images from common-theme/webapp/images to common-theme/webapp/common and then will remove the
          common-theme/webapp/images.
          So new structure will be as follow

          common-theme/webapp/common/js
          common-theme/webapp/common/css
          common-theme/webapp/common/images

          So no need to create new webapp in themes/common/ofbiz-component.xml.

          Show
          deepak.dixit Deepak Dixit added a comment - - edited Thanks Nicolas, I think I wrote too short Proposal is to move js/css/images from common-theme/webapp/images to common-theme/webapp/common and then will remove the common-theme/webapp/images. So new structure will be as follow common-theme/webapp/common/js common-theme/webapp/common/css common-theme/webapp/common/images So no need to create new webapp in themes/common/ofbiz-component.xml.
          Hide
          soledad Nicolas Malin added a comment - - edited

          +1 for me also

          Normally you just change on the themes/common/widget/Theme.xml like

          -        <property name="VT_HDR_JAVASCRIPT['add']" value="/images/jquery/plugins/asmselect/jquery.asmselect-1.0.4a-beta.js"/>
          +        <property name="VT_HDR_JAVASCRIPT['add']" value="/js/jquery/plugins/asmselect/jquery.asmselect-1.0.4a-beta.js"/>
          

          after don't forget to open the related webapp on themes/common/ofbiz-component.xml, but this you know well

          Show
          soledad Nicolas Malin added a comment - - edited +1 for me also Normally you just change on the themes/common/widget/Theme.xml like - <property name= "VT_HDR_JAVASCRIPT['add']" value= "/images/jquery/plugins/asmselect/jquery.asmselect-1.0.4a-beta.js" /> + <property name= "VT_HDR_JAVASCRIPT['add']" value= "/js/jquery/plugins/asmselect/jquery.asmselect-1.0.4a-beta.js" /> after don't forget to open the related webapp on themes/common/ofbiz-component.xml, but this you know well
          Hide
          taher Taher Alkhateeb added a comment -

          +1 Deepak. Makes sense, and I'm getting excited this is finally moving in the right direction

          Show
          taher Taher Alkhateeb added a comment - +1 Deepak. Makes sense, and I'm getting excited this is finally moving in the right direction
          Hide
          deepak.dixit Deepak Dixit added a comment -

          Thanks Jacques,

          yes its a typo,
          >>>
          We can move them from images webapp to common-theme as following
          common-theme/js
          common-theme/css
          common-theme/img or common-theme/images

          Show
          deepak.dixit Deepak Dixit added a comment - Thanks Jacques, yes its a typo, >>> We can move them from images webapp to common-theme as following common-theme/js common-theme/css common-theme/img or common-theme/images
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          +1 for the idea Deepak, but I guess a typo for the duplicated line
          common-theme/js

          Show
          jacques.le.roux Jacques Le Roux added a comment - +1 for the idea Deepak, but I guess a typo for the duplicated line common-theme/js
          Hide
          deepak.dixit Deepak Dixit added a comment -

          As now we have common-theme component, so now we don;t need images webapp for js/css and related images.

          We can move them from images webapp to common-theme as following
          common-theme/js
          common-theme/js
          common-theme/img or common-theme/images

          Show
          deepak.dixit Deepak Dixit added a comment - As now we have common-theme component, so now we don;t need images webapp for js/css and related images. We can move them from images webapp to common-theme as following common-theme/js common-theme/js common-theme/img or common-theme/images
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Hi Do Nhu Vy,

          What is exactly an unreasonable point? BTW the javascript.css file is only present in 2 themes: Flat Grey and RainbowStone. So it's theme specific

          Show
          jacques.le.roux Jacques Le Roux added a comment - Hi Do Nhu Vy, What is exactly an unreasonable point? BTW the javascript.css file is only present in 2 themes: Flat Grey and RainbowStone. So it's theme specific
          Show
          donhuvy Do Nhu Vy added a comment - It is a unreasonable point: https://user-images.githubusercontent.com/1328316/27322823-a937c66e-55c9-11e7-94d9-dc4adfd50631.jpg
          Hide
          soledad Nicolas Malin added a comment - - edited

          I create a first POC on my github https://github.com/nmalin/ApacheOFBiz/tree/common-theme with :

          • creation of a common-theme component (that can rename it's a poc)
          • redirect all framework/common/widget/CommonScreens.xml to theme/common-theme/widget/CommonScreens.xml
          • move all framework/common/webapp/template to theme/common-theme/webapp/template
          • move the images components to common-theme as embed webapp

          It's a first step, but the test is concluding.

          I can't create a patch because à move too many file but you can play with the branch

          Show
          soledad Nicolas Malin added a comment - - edited I create a first POC on my github https://github.com/nmalin/ApacheOFBiz/tree/common-theme with : creation of a common-theme component (that can rename it's a poc) redirect all framework/common/widget/CommonScreens.xml to theme/common-theme/widget/CommonScreens.xml move all framework/common/webapp/template to theme/common-theme/webapp/template move the images components to common-theme as embed webapp It's a first step, but the test is concluding. I can't create a patch because à move too many file but you can play with the branch
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I see, thanks

          Show
          jacques.le.roux Jacques Le Roux added a comment - I see, thanks
          Hide
          taher Taher Alkhateeb added a comment -

          I do not have a firm opinion, and I am just brainstorming so feel free to correct me on anything:

          My vision for the common theme is that of something that is completely compatible with the widget DSL but nothing more. To say it in another way it is the minimum that is needed for the widget DSL to work correctly. This would include the JavaScript libraries that we agree on as being essential and the CSS Frameworks that we consider essential as well and any other web artifacts. This would also include the essential data in the database for the themes to operate correctly.

          Now imagine that you have a bug in your user interface and you suspect that this bug has nothing to do with the back end but it's strictly a web thing. So you go to Firebug or whatever your tool is and you start investigating what is going on. The problem with the themes is that they are too fat as they contain much more than what is needed. So what is the solution in this case? You simply switch to the common theme and start investigating.

          Also how do you know that your common theme is able to do everything that the widget DSL asks of it? Well the best way to know is to watch it so you turn on the common theme and start exploring the screens to make sure that everything works as intended

          So these are some reasons why I would like it to be a theme and not just a folder. Again this is nothing more than ideas cooking in my head right now.

          Show
          taher Taher Alkhateeb added a comment - I do not have a firm opinion, and I am just brainstorming so feel free to correct me on anything: My vision for the common theme is that of something that is completely compatible with the widget DSL but nothing more. To say it in another way it is the minimum that is needed for the widget DSL to work correctly. This would include the JavaScript libraries that we agree on as being essential and the CSS Frameworks that we consider essential as well and any other web artifacts. This would also include the essential data in the database for the themes to operate correctly. Now imagine that you have a bug in your user interface and you suspect that this bug has nothing to do with the back end but it's strictly a web thing. So you go to Firebug or whatever your tool is and you start investigating what is going on. The problem with the themes is that they are too fat as they contain much more than what is needed. So what is the solution in this case? You simply switch to the common theme and start investigating. Also how do you know that your common theme is able to do everything that the widget DSL asks of it? Well the best way to know is to watch it so you turn on the common theme and start exploring the screens to make sure that everything works as intended So these are some reasons why I would like it to be a theme and not just a folder. Again this is nothing more than ideas cooking in my head right now.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Taher you said

          Now that I think about it one of the nice things about this common theme is that you will be able to select it as a theme from the list of themes in the user interface. This would be very nice and convenient for testing to make sure the things go in the right place and for debugging web-based bugs.

          I was thinking this commontheme would not be a theme in itself but a place where themes common things would stay. You envision to have a new theme there or pick one of the existing ones?

          Show
          jacques.le.roux Jacques Le Roux added a comment - Taher you said Now that I think about it one of the nice things about this common theme is that you will be able to select it as a theme from the list of themes in the user interface. This would be very nice and convenient for testing to make sure the things go in the right place and for debugging web-based bugs. I was thinking this commontheme would not be a theme in itself but a place where themes common things would stay. You envision to have a new theme there or pick one of the existing ones?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I'm not sure it's valid or not, but I'd say to stay in the way it was done so far (specialpurpose) better to use commontheme (not even "camelised")

          Show
          jacques.le.roux Jacques Le Roux added a comment - I'm not sure it's valid or not, but I'd say to stay in the way it was done so far (specialpurpose) better to use commontheme (not even "camelised")
          Hide
          taher Taher Alkhateeb added a comment -

          Now that I think about it one of the nice things about this common theme is that you will be able to select it as a theme from the list of themes in the user interface. This would be very nice and convenient for testing to make sure the things go in the right place and for debugging web-based bugs.

          Is the dash and acceptable character in component names? If not then we might need to call it commontheme. Not a big deal but important to point out

          Show
          taher Taher Alkhateeb added a comment - Now that I think about it one of the nice things about this common theme is that you will be able to select it as a theme from the list of themes in the user interface. This would be very nice and convenient for testing to make sure the things go in the right place and for debugging web-based bugs. Is the dash and acceptable character in component names? If not then we might need to call it commontheme. Not a big deal but important to point out
          Hide
          deepak.dixit Deepak Dixit added a comment -

          I also like common-theme

          Show
          deepak.dixit Deepak Dixit added a comment - I also like common-theme
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I like common-theme better

          Show
          jacques.le.roux Jacques Le Roux added a comment - I like common-theme better
          Hide
          taher Taher Alkhateeb added a comment -

          Hmm, not a strong opinion, but I would not label it on what it contains but rather its purpose. Based on our historical naming conventions maybe we can call it "common" or "common-theme". The reason I suggest that is because this is not just going to be a folder with static resources. It is going to be a full ofbiz component with ofbiz-component.xml definitions and whatnot.

          Remember, if we really want to extract the "web" away from the framework, then we need more power in the themes, not just static resources but also business logic when / where needed.

          Show
          taher Taher Alkhateeb added a comment - Hmm, not a strong opinion, but I would not label it on what it contains but rather its purpose. Based on our historical naming conventions maybe we can call it "common" or "common-theme". The reason I suggest that is because this is not just going to be a folder with static resources. It is going to be a full ofbiz component with ofbiz-component.xml definitions and whatnot. Remember, if we really want to extract the "web" away from the framework, then we need more power in the themes, not just static resources but also business logic when / where needed.
          Hide
          deepak.dixit Deepak Dixit added a comment -

          Yes Jacques OFBIZ-1319 is only about js, you can ignore this comment it

          Show
          deepak.dixit Deepak Dixit added a comment - Yes Jacques OFBIZ-1319 is only about js, you can ignore this comment it
          Hide
          deepak.dixit Deepak Dixit added a comment -

          I think we can use static or static-resource or assets or any better relevant name?

          Show
          deepak.dixit Deepak Dixit added a comment - I think we can use static or static-resource or assets or any better relevant name?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Are you sure? OFBIZ-1319 is only about js

          Show
          jacques.le.roux Jacques Le Roux added a comment - Are you sure? OFBIZ-1319 is only about js
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          What would you suggest?

          Show
          jacques.le.roux Jacques Le Roux added a comment - What would you suggest?
          Hide
          deepak.dixit Deepak Dixit added a comment -

          I like the idea, but instead of calling it basetheme we need to re-think the name. As we are going to move base utility js code so we have to name it more generic rather then base theme.

          Show
          deepak.dixit Deepak Dixit added a comment - I like the idea, but instead of calling it basetheme we need to re-think the name. As we are going to move base utility js code so we have to name it more generic rather then base theme.
          Hide
          deepak.dixit Deepak Dixit added a comment -

          I think one effort is already going under OFBIZ-1319

          Show
          deepak.dixit Deepak Dixit added a comment - I think one effort is already going under OFBIZ-1319
          Hide
          deepak.dixit Deepak Dixit added a comment -

          Yes Jacques you are right.

          Show
          deepak.dixit Deepak Dixit added a comment - Yes Jacques you are right.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I agree about an umbrella task, this one and OFBIZ-7907 would be subtask of it primarily

          Show
          jacques.le.roux Jacques Le Roux added a comment - I agree about an umbrella task, this one and OFBIZ-7907 would be subtask of it primarily
          Hide
          taher Taher Alkhateeb added a comment -

          Agreed, I am not sure how much work is involved in doing that, but this is a very critical area for the success of OFBiz (i.e. cleaning the UI mess). So I think we should not work too much on this JIRA and instead create an umbrella JIRA with perhaps the title "Move all UI web assets from the framework to a common shared theme" and branch out tasks such as "Refactor the themes to share a common base" and "Refactor the widgets in components to be independent of the theme designs" and similar tasks.

          So, it's big work, but necessary. UI is unfortunately one of the biggest areas of Chaos and we need to tackle it, and the very first step in my opinion is to keep the "mess" in one pile (/themes) and take it from there.

          Show
          taher Taher Alkhateeb added a comment - Agreed, I am not sure how much work is involved in doing that, but this is a very critical area for the success of OFBiz (i.e. cleaning the UI mess). So I think we should not work too much on this JIRA and instead create an umbrella JIRA with perhaps the title "Move all UI web assets from the framework to a common shared theme" and branch out tasks such as "Refactor the themes to share a common base" and "Refactor the widgets in components to be independent of the theme designs" and similar tasks. So, it's big work, but necessary. UI is unfortunately one of the biggest areas of Chaos and we need to tackle it, and the very first step in my opinion is to keep the "mess" in one pile (/themes) and take it from there.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          W/o thinking more (must go) I like much the idea of a base theme. There are already a lot of useless redundancy in themes (eg ref to css and js files)

          Show
          jacques.le.roux Jacques Le Roux added a comment - W/o thinking more (must go) I like much the idea of a base theme. There are already a lot of useless redundancy in themes (eg ref to css and js files)
          Hide
          taher Taher Alkhateeb added a comment -

          This is an area too big for me to tackle at the moment, but in my opinion web resources should be in fact completely outside of the framework. Perhaps a better place is the themes directory. Here are a few thoughts on why this should be the case:

          • The widget system is designed to be technology independent (is not specific to html). So the skinning, UI behavior and layout, should as much as possible be a deferred decision (right before painting). For example If I want a button to glow upon hovering, I should add that to the widget DSL and translate it at the very last second.
          • Even if we introduce a non-pure widget (<platform-specific><html>...) then the translation of that UI is also a last minute decision happening in the templates / rendering engine.

          So in summary, nothing "Web-specific UI" should reside in the framework. The framework is the infrastructure tools and low level components (servlets, entity engine, service engine, scripting, DSLs, widget engine, routing, etc ...) and never things like UI.

          If we are going to go through the pain of renaming, refactoring, and fixing all the links, we might as well do this properly by keeping the framework lean, and anything that gets painted should go IMO to /themes somewhere. Perhaps we can have a base theme that holds all the things that other themes extend from.

          Show
          taher Taher Alkhateeb added a comment - This is an area too big for me to tackle at the moment, but in my opinion web resources should be in fact completely outside of the framework. Perhaps a better place is the themes directory. Here are a few thoughts on why this should be the case: The widget system is designed to be technology independent (is not specific to html). So the skinning, UI behavior and layout, should as much as possible be a deferred decision (right before painting). For example If I want a button to glow upon hovering, I should add that to the widget DSL and translate it at the very last second. Even if we introduce a non-pure widget (<platform-specific><html>...) then the translation of that UI is also a last minute decision happening in the templates / rendering engine. So in summary, nothing "Web-specific UI" should reside in the framework. The framework is the infrastructure tools and low level components (servlets, entity engine, service engine, scripting, DSLs, widget engine, routing, etc ...) and never things like UI. If we are going to go through the pain of renaming, refactoring, and fixing all the links, we might as well do this properly by keeping the framework lean, and anything that gets painted should go IMO to /themes somewhere. Perhaps we can have a base theme that holds all the things that other themes extend from.
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          I agree about runtime Pierre, I can think of a better place! Maybe a sub folder of runtime/output ?

          Show
          jacques.le.roux Jacques Le Roux added a comment - I agree about runtime Pierre, I can think of a better place! Maybe a sub folder of runtime/output ?
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          Hi Deepak,

          W/o surprises I'm more for the option 2. But you say

          Rename images to static web-app and organize js/css/images in logical grouping.

          I guess you mean both component and webApp right?

          Show
          jacques.le.roux Jacques Le Roux added a comment - Hi Deepak, W/o surprises I'm more for the option 2. But you say Rename images to static web-app and organize js/css/images in logical grouping. I guess you mean both component and webApp right?
          Hide
          pfm.smits Pierre Smits added a comment -

          I agree. Dynamically generated content should not reside in the framework. Seems to me that the best place for that is the runtime folder.

          As long as the community hasn't taken a decision on where the resource templates should reside, we can't move them.

          Show
          pfm.smits Pierre Smits added a comment - I agree. Dynamically generated content should not reside in the framework. Seems to me that the best place for that is the runtime folder. As long as the community hasn't taken a decision on where the resource templates should reside, we can't move them.
          Hide
          deepak.dixit Deepak Dixit added a comment -

          Thanks Jacques,

          I think we can conclude this now and As Pierre mentioned about template, yes they are not in right place,we can move them to another location (when we finalize) after this move.

          At some other place you mentioned to use "static" web-app name that make sense as well.
          So here is the final proposal:

          Option one:
          Move all the js/css/images to resources web-app and delete the images web-app.

          Option two:
          Rename images to static web-app and organize js/css/images in logical grouping.

          Show
          deepak.dixit Deepak Dixit added a comment - Thanks Jacques, I think we can conclude this now and As Pierre mentioned about template, yes they are not in right place,we can move them to another location (when we finalize) after this move. At some other place you mentioned to use "static" web-app name that make sense as well. So here is the final proposal: Option one: Move all the js/css/images to resources web-app and delete the images web-app. Option two: Rename images to static web-app and organize js/css/images in logical grouping.
          Hide
          deepak.dixit Deepak Dixit added a comment -

          I think we have configuration option for this, like for product image we can change the image.server.path in catalog.properties. We can check all the dynamic content creation and can change their location from framework/images to framework/resources

          Show
          deepak.dixit Deepak Dixit added a comment - I think we have configuration option for this, like for product image we can change the image.server.path in catalog.properties. We can check all the dynamic content creation and can change their location from framework/images to framework/resources
          Hide
          jacques.le.roux Jacques Le Roux added a comment -

          The most interesting point to me is to move dynamically created content from framework/images. The rest is a moot point to me (though of course ressources name makes more sens for js and css to me than images). As mentionned Pierrre the templates are not at their right place either. There are maybe other kinds of stuff in images (Adrian spoke about "application-specific content"), I did not check, but it will be certainly easier to check and decide to their place after this move...

          Show
          jacques.le.roux Jacques Le Roux added a comment - The most interesting point to me is to move dynamically created content from framework/images. The rest is a moot point to me (though of course ressources name makes more sens for js and css to me than images). As mentionned Pierrre the templates are not at their right place either. There are maybe other kinds of stuff in images (Adrian spoke about "application-specific content"), I did not check, but it will be certainly easier to check and decide to their place after this move...
          Hide
          pfm.smits Pierre Smits added a comment -

          The framework / resources folder contains the templates for creating new applications, to jump start junior developers but also to get some consistency between components (following naming conventions for generic data, screen and form widget, services, etc files).

          These templates shouldn't be in the framework stack. But should probably live in the special purposes stack.

          Show
          pfm.smits Pierre Smits added a comment - The framework / resources folder contains the templates for creating new applications, to jump start junior developers but also to get some consistency between components (following naming conventions for generic data, screen and form widget, services, etc files). These templates shouldn't be in the framework stack. But should probably live in the special purposes stack.
          Hide
          deepak.dixit Deepak Dixit added a comment - - edited

          Can we conclude this ticket?

          Either we are fine to move static content from images (as image webapp name is miss leading) to resources (appropriate place for js/css) or we can discard this ticket as well

          Show
          deepak.dixit Deepak Dixit added a comment - - edited Can we conclude this ticket? Either we are fine to move static content from images (as image webapp name is miss leading) to resources (appropriate place for js/css) or we can discard this ticket as well
          Hide
          adrianc@hlmksw.com Adrian Crum added a comment -

          We seem to be going in circles. You keep saying we should move static content to a different folder, and I keep saying I don't see a reason to move it, and you keep saying we should move static content to a different folder, and I keep saying I don't see a reason to move it...

          Your approach is not "better" - it is merely different.

          Show
          adrianc@hlmksw.com Adrian Crum added a comment - We seem to be going in circles. You keep saying we should move static content to a different folder, and I keep saying I don't see a reason to move it, and you keep saying we should move static content to a different folder, and I keep saying I don't see a reason to move it... Your approach is not "better" - it is merely different.
          Hide
          deepak.dixit Deepak Dixit added a comment -

          Main goal is to organize static content in a better way.

          http://markmail.org/message/56skgbpwz4t6rvj2

          Show
          deepak.dixit Deepak Dixit added a comment - Main goal is to organize static content in a better way. http://markmail.org/message/56skgbpwz4t6rvj2
          Hide
          adrianc@hlmksw.com Adrian Crum added a comment -

          The current framework/resources folder contains templates used for ant targets. I still don't see how that folder is more "appropriate" for storing static content than the one we currently have (framework/images).

          Show
          adrianc@hlmksw.com Adrian Crum added a comment - The current framework/resources folder contains templates used for ant targets. I still don't see how that folder is more "appropriate" for storing static content than the one we currently have (framework/images).
          Hide
          deepak.dixit Deepak Dixit added a comment -

          Hi,

          Can we move static resource to appropriate place (resources) instead images webapp?

          Show
          deepak.dixit Deepak Dixit added a comment - Hi, Can we move static resource to appropriate place (resources) instead images webapp?
          Hide
          deepak.dixit Deepak Dixit added a comment -

          Thanks Pieere, Yes we can configure the image location, and I am not saying that user should have to use only framework/images location for image management.

          I am saying that we need to move static resources to much logical place, currently these are located at images webapp and that does not make sense, we have resources component already and we can move static resources to this component.
          I tried to explain with one situation

          Show
          deepak.dixit Deepak Dixit added a comment - Thanks Pieere, Yes we can configure the image location, and I am not saying that user should have to use only framework/images location for image management. I am saying that we need to move static resources to much logical place, currently these are located at images webapp and that does not make sense, we have resources component already and we can move static resources to this component. I tried to explain with one situation
          Hide
          pfm.smits Pierre Smits added a comment - - edited

          Deepak,

          Your last posting showed something that made me wonder about this a bit. Basically you're saying that you must remove the static stuff out from where it is, because the same place gets filled with product images when used in a production setup.

          That seems to me the wrong way around, as you would - in a sense - end up storing production data (images in this case) in a code location (the component in the framework stack). Better is it to separate (production) data locations from code locations.

          There are means available to define where images are (or can be) stored.

          Regards,

          Pierre

          Show
          pfm.smits Pierre Smits added a comment - - edited Deepak, Your last posting showed something that made me wonder about this a bit. Basically you're saying that you must remove the static stuff out from where it is, because the same place gets filled with product images when used in a production setup. That seems to me the wrong way around, as you would - in a sense - end up storing production data (images in this case) in a code location (the component in the framework stack). Better is it to separate (production) data locations from code locations. There are means available to define where images are (or can be) stored. Regards, Pierre
          Hide
          deepak.dixit Deepak Dixit added a comment -

          Thanks Adrian for the comment.

          Let me try to explain:
          Image webapp also used for product images as well. If we want to mount images webapp separately then we need to also override the static resources and product images as well. Ideally as name suggest images webapp should only responsible for images (for product and category, etc) as framework code used the images webapp for the same.

          As we have resources webapp as well and static resources like js, css, and css related images should be part of this webapp. If move static resources to resources webapp then we are free to independently mount images and resources webapp. This is also discussed under "http://ofbiz.markmail.org/thread/5i63sed4anc672x6"

          Show
          deepak.dixit Deepak Dixit added a comment - Thanks Adrian for the comment. Let me try to explain: Image webapp also used for product images as well. If we want to mount images webapp separately then we need to also override the static resources and product images as well. Ideally as name suggest images webapp should only responsible for images (for product and category, etc) as framework code used the images webapp for the same. As we have resources webapp as well and static resources like js, css, and css related images should be part of this webapp. If move static resources to resources webapp then we are free to independently mount images and resources webapp. This is also discussed under "http://ofbiz.markmail.org/thread/5i63sed4anc672x6"
          Hide
          adrianc@hlmksw.com Adrian Crum added a comment -

          I do not understand the need for this change. Is it merely the folder name that is the issue?

          Historically, static content is kept in the images component - so it can be hosted separately from the rest of the applications.

          Show
          adrianc@hlmksw.com Adrian Crum added a comment - I do not understand the need for this change. Is it merely the folder name that is the issue? Historically, static content is kept in the images component - so it can be hosted separately from the rest of the applications.
          Hide
          deepak.dixit Deepak Dixit added a comment -

          Here is the patch for reference after moving static resources to resources webapp.

          Show
          deepak.dixit Deepak Dixit added a comment - Here is the patch for reference after moving static resources to resources webapp.
          Hide
          deepak.dixit Deepak Dixit added a comment -

          Here are some references for files and folder that we need to move from images webapp to resources webapp.

          framework/images/webapp/images/catalog >> framework/resources/webapp/resources/css/catalog
          framework/images/webapp/images/date >> framework/resources/webapp/resources/js/date
          framework/images/webapp/images/humanres >> framework/resources/webapp/resources/css/humanres
          framework/images/webapp/images/icons >> framework/resources/webapp/resources/icons
          framework/images/webapp/images/imagemanagement >> framework/resources/webapp/resources/js/imagemanagement
          framework/images/webapp/images/img/* >> framework/resources/webapp/resources/images/
          framework/images/webapp/images/jquery >> framework/resources/webapp/resources/js/jquery
          framework/images/webapp/images/portlets >> framework/resources/webapp/resources/images/portlets
          framework/images/webapp/images/rate >> framework/resources/webapp/resources/images/rate
          framework/images/webapp/images/rtl >> framework/resources/webapp/resources/images/rtl
          framework/images/webapp/images/tabs >> framework/resources/webapp/resources/images/tabs
          
          
          move all the images located at framework/images/webapp/images/ to framework/resources/webapp/resources/images
          
          
          framework/images/webapp/images/combobox.js >> framework/resources/webapp/resources/js/combobox.js
          framework/images/webapp/images/ecommain.css >> framework/resources/webapp/resources/css/ecommain.css
          framework/images/webapp/images/forms.css  >> framework/resources/webapp/resources/css/forms.css
          
          framework/images/webapp/images/myportal.js >> framework/resources/webapp/resources/js/myportal.js
          framework/images/webapp/images/myportal.css >> framework/resources/webapp/resources/css/myportal.css
          framework/images/webapp/images/fieldlookup.js >> framework/resources/webapp/resources/js/fieldlookup.js
          framework/images/webapp/images/jsgantt.css  >> framework/resources/webapp/resources/js/plugins/jsgantt/jsgantt.css
          framework/images/webapp/images/jsgantt.js >> framework/resources/webapp/resources/js/plugins/jsgantt/jsgantt.js
          framework/images/webapp/images/reset.css  >> framework/resources/webapp/resources/css/reset.css
          framework/images/webapp/images/selectMultipleRelatedValues.js  >>  framework/resources/webapp/resources/js/selectMultipleRelatedValues.js
          framework/images/webapp/images/util.js >> framework/resources/webapp/resources/js/util.js
          framework/images/webapp/images/tabstyles.css >> framework/resources/webapp/resources/css/tabstyles.css
          framework/images/webapp/images/wiki-content.css >> framework/resources/webapp/resources/css/wiki-content.css
          
          Show
          deepak.dixit Deepak Dixit added a comment - Here are some references for files and folder that we need to move from images webapp to resources webapp. framework/images/webapp/images/catalog >> framework/resources/webapp/resources/css/catalog framework/images/webapp/images/date >> framework/resources/webapp/resources/js/date framework/images/webapp/images/humanres >> framework/resources/webapp/resources/css/humanres framework/images/webapp/images/icons >> framework/resources/webapp/resources/icons framework/images/webapp/images/imagemanagement >> framework/resources/webapp/resources/js/imagemanagement framework/images/webapp/images/img/* >> framework/resources/webapp/resources/images/ framework/images/webapp/images/jquery >> framework/resources/webapp/resources/js/jquery framework/images/webapp/images/portlets >> framework/resources/webapp/resources/images/portlets framework/images/webapp/images/rate >> framework/resources/webapp/resources/images/rate framework/images/webapp/images/rtl >> framework/resources/webapp/resources/images/rtl framework/images/webapp/images/tabs >> framework/resources/webapp/resources/images/tabs move all the images located at framework/images/webapp/images/ to framework/resources/webapp/resources/images framework/images/webapp/images/combobox.js >> framework/resources/webapp/resources/js/combobox.js framework/images/webapp/images/ecommain.css >> framework/resources/webapp/resources/css/ecommain.css framework/images/webapp/images/forms.css >> framework/resources/webapp/resources/css/forms.css framework/images/webapp/images/myportal.js >> framework/resources/webapp/resources/js/myportal.js framework/images/webapp/images/myportal.css >> framework/resources/webapp/resources/css/myportal.css framework/images/webapp/images/fieldlookup.js >> framework/resources/webapp/resources/js/fieldlookup.js framework/images/webapp/images/jsgantt.css >> framework/resources/webapp/resources/js/plugins/jsgantt/jsgantt.css framework/images/webapp/images/jsgantt.js >> framework/resources/webapp/resources/js/plugins/jsgantt/jsgantt.js framework/images/webapp/images/reset.css >> framework/resources/webapp/resources/css/reset.css framework/images/webapp/images/selectMultipleRelatedValues.js >> framework/resources/webapp/resources/js/selectMultipleRelatedValues.js framework/images/webapp/images/util.js >> framework/resources/webapp/resources/js/util.js framework/images/webapp/images/tabstyles.css >> framework/resources/webapp/resources/css/tabstyles.css framework/images/webapp/images/wiki-content.css >> framework/resources/webapp/resources/css/wiki-content.css
          Hide
          deepak.dixit Deepak Dixit added a comment - - edited

          Here is the proposed structure for resources webapp:
          /resources/js: Move all the js file like (fieldlookup.js, selectall.sj)

          • date
          • imagemanagement
          • jquery
          • plugins

          /resources/css : Move all css file related to ofbiz

          • catalog
          • humanres

          /resources/images: Move all the images (except products images) related to framework

          • portlets
          • rate
          • rtl
          • tabs

          /resources/icon : Move icons folder to resources/icons

          Show
          deepak.dixit Deepak Dixit added a comment - - edited Here is the proposed structure for resources webapp: /resources/js: Move all the js file like (fieldlookup.js, selectall.sj) date imagemanagement jquery plugins /resources/css : Move all css file related to ofbiz catalog humanres /resources/images: Move all the images (except products images) related to framework portlets rate rtl tabs /resources/icon : Move icons folder to resources/icons

            People

            • Assignee:
              deepak.dixit Deepak Dixit
              Reporter:
              deepak.dixit Deepak Dixit
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:

                Development

                  Agile