Indeed. One workaround we have applied is the use of ${activeApp} for
various references. But that can't be applied everywhere.Best eregards, Pierre On Wednesday, April 29, 2015, Adam Heath <[email protected]> wrote: > What you are looking to define here is relativeness. If a non-absolute > path is found in a file, then resolve the full path against the absolute > path of the file it was found in. > > I'm for this, btw. > > On 04/29/2015 05: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 >> >> > -- Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com
