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 |
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 <[hidden email]> 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 > |
In reply to this post by Pierre Smits
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 > |
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 < [hidden email]> 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 >> >> |
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 <[hidden email]> 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 < > [hidden email]> 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 >>> >>> > |
In reply to this post by Pierre Smits
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 > |
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 <[hidden email]> 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 |
Free forum by Nabble | Edit this page |