When talking about the 'same component' I meant everything in the same folder structure, as in:
component |-> /widget |->/ widget/forms |-> /scripts |-> etc Anything outside that structure is - with current definitions - outside the component. Think of a screen of component A referencing a script in another component B. For such the 'full' location should/must be referenced, as it is now. If a screen AScreenName - existing in AScreens.xml in component A - needs to be referenced in another screens.xml file in the component A (say in BScreens.xml), it should suffice to have an 'short' location reference. As in <screen name="AScreenName" location="AScreens.xml" /> Best regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Wed, Apr 29, 2015 at 1:12 PM, Adrian Crum < adrian.c...@sandglass-software.com> wrote: > I don't think this will work - for a number of reasons. > > Using the screen widgets as an example, what does "widgets in the same > component" mean? Widgets are reused everywhere. If a component reuses a > widget in another component, what is "the same component?" The component > referencing the reused widget, or the component that contains the reused > widget? > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 4/29/2015 11:02 AM, Pierre Smits wrote: > >> Currently many widgets are referenced in other widgets (e.g. forms, etc) >> by >> incorporating the location to the widget. >> >> e.g. In a screen file following the following can occur: >> >> - <include-form name="form1" >> location="component://componentName/widget/forms/Forms.xml"/> >> - <include-screen name="Screen1" >> location="component://componentName/widget/AnotherScreens.xml"/> >> - <include-menu name="Menu1" >> location="component://componentName/widget/Menus.xml'/> >> - <script >> location="component://componentName/scripts/script.groovy"/> >> >> And in controller.xml: >> >> - <view-map name="optionsetting" type="screen" page= >> "component://order/widget/OrderEntryOrderScreens.xml#OptionSettings"/> >> - <event type="simple" path= >> "component://commonext/script/org/ofbiz/setup/SetupEvents.xml" invoke= >> "createProductStoreWithDefaultSetting"/> >> >> And in the ofbiz-component.xml file of the component: >> >> >> - <entity-resource type="model" reader-name="main" loader="main" >> location >> ="entitydef/entitymodel.xml"/> >> - <entity-resource type="eca" reader-name="main" loader="main" >> location= >> "entitydef/eecas.xml"/> >> - <entity-resource type="data" reader-name="seed" loader="main" >> location= >> "data/WorkEffortTypeData.xml"/> >> >> >> >> However, having to type the location path everywhere is quite tedious and >> error prone. >> >> Couldn't it be possible to add a layer of flexibility, so that widgets in >> the same component can be referenced in an easier way? Like for screens: >> >> - <include-form name="form1" location="Forms.xml"/> >> - <include-screen name="Screen1" location="AnotherScreens.xml"/> >> - <include-menu name="Menu1" location="Menus.xml'/> >> - <script location="script.groovy"/> >> >> And for controller.xml: >> >> - <event type="simple" path="SetupEvents.xml" invoke= >> "createProductStoreWithDefaultSetting"/> >> - <view-map name="optionsetting" type="screen" page= >> "OrderEntryOrderScreens.xml#OptionSettings"/> >> >> And for ofbiz-component.xml: >> >> >> - <entity-resource type="model" reader-name="main" loader="main" >> location >> =entitymodel.xml"/> >> - <entity-resource type="eca" reader-name="main" loader="main" >> location= >> "eecas.xml"/> >> - <entity-resource type="data" reader-name="seed" loader="main" >> location= >> "WorkEffortTypeData.xml"/> >> >> >> Of course, such would require that the default paths to the various widget >> locations must be known on the moment of loading the component (especially >> the entitymodel and ecas/secas - I migt be forgetting some). >> This could be done by references in a record in the SystemProperty entity, >> and as a fallback the system.properties file in the component. >> >> Such an improvement would, I believe, make both development of new >> applications and migration regarding future framework changes easier. >> >> What do you think? >> >> Best regards, >> >> >> Pierre Smits >> >> *ORRTIZ.COM <http://www.orrtiz.com>* >> Services & Solutions for Cloud- >> Based Manufacturing, Professional >> Services and Retail & Trade >> http://www.orrtiz.com >> >>
