You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Pierre Smits <pi...@gmail.com> on 2015/04/29 12:02:14 UTC

[DISCUSSION] Adding more flexibility to how widget elements - and others are referenced

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

Re: [DISCUSSION] Adding more flexibility to how widget elements - and others are referenced

Posted by Pierre Smits <pi...@gmail.com>.
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 <pi...@gmail.com>
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
>

Re: [DISCUSSION] Adding more flexibility to how widget elements - and others are referenced

Posted by Pierre Smits <pi...@gmail.com>.
What are the potential issues that this won't work?

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:34 PM, Pierre Smits <pi...@gmail.com>
wrote:

> 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.crum@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
>>>
>>>
>

Re: [DISCUSSION] Adding more flexibility to how widget elements - and others are referenced

Posted by Pierre Smits <pi...@gmail.com>.
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.crum@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
>>
>>

Re: [DISCUSSION] Adding more flexibility to how widget elements - and others are referenced

Posted by Adrian Crum <ad...@sandglass-software.com>.
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
>

Re: [DISCUSSION] Adding more flexibility to how widget elements - and others are referenced

Posted by Pierre Smits <pi...@gmail.com>.
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 <do...@brainfood.com> 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

Re: [DISCUSSION] Adding more flexibility to how widget elements - and others are referenced

Posted by Adam Heath <do...@brainfood.com>.
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
>