A way to have it in a SystemProperty entity record could be:

   -

   <SystemProperty systemResourceId="componentname" systemPropertyId=
   "location.forms" systemPropertyValue="component://widget/forms"
   description="default location of forms within the component"/>
   -

   <SystemProperty systemResourceId="componentname" systemPropertyId=
   "location.screens" systemPropertyValue="component://widget"
description="default
   location of screens within the component"/
   -

   <SystemProperty systemResourceId="componentname" systemPropertyId=
   "location.menus" systemPropertyValue=component://widget"
description="default
   location of forms within the component"/>
   -
   - <SystemProperty systemResourceId="componentname" systemPropertyId=
   "location.scripts" systemPropertyValue=component://scripts"
description="default
   location of forms within the component"/>

And in the 'componentname.properties file:

   -
   - location.screens=component://widget
   - location.forms=component://widget/forms
   - location.menus=component://widget
   - location.scripts=component://scripts

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 12:02 PM, Pierre Smits <[email protected]>
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
>

Reply via email to