Controller Entry related to include other application controller.

[Rishi Solanki]

Hi All,

I have a question related to including other application controller in to
new under development application.
For example : We have included five more controller in projectmgr
application as ; catalog, ordermgr, accounting, workeffort, and humanres.
Here I think that if we have to use 20 - 30 uri of other controller, and
suppose all controllers have 100 uri.
So, Here is my question that,
Should we include these five controllers in projectmgr or we may create new
uri's for the same in the projectmgr component. Because
as per my understanding, every time the uri when not found in the controller
of projectmgr it will search the same uri in other controller
as per sequence they included in the projectmgr controller.
Now which approach is better in such case if we consider the performance :
" Either we should include the controller in the new application controller
or we may write our own uri's in new application controller. "

My vote is we should go for Write our own uri in the new application
controller.

Suggestion's are most welcome.


Thanks and Regards :
 [Rishi Solanki]

[Vikas Mayur-2]

On Thu, Mar 20, 2008 at 2:25 PM, Rishi Solanki <[hidden email]>
wrote:

> Hi All,
>
> I have a question related to including other application controller in to
> new under development application.
> For example : We have included five more controller in projectmgr
> application as ; catalog, ordermgr, accounting, workeffort, and humanres.
> Here I think that if we have to use 20 - 30 uri of other controller, and
> suppose all controllers have 100 uri.
> So, Here is my question that,
> Should we include these five controllers in projectmgr or we may create
> new
> uri's for the same in the projectmgr component. Because
> as per my understanding, every time the uri when not found in the
> controller
> of projectmgr it will search the same uri in other controller
> as per sequence they included in the projectmgr controller.
> Now which approach is better in such case if we consider the performance :
> " Either we should include the controller in the new application
> controller
> or we may write our own uri's in new application controller. "
>
> My vote is we should go for Write our own uri in the new application
> controller.

This is not a best practice, this totally does not favour code re-usability
and maintenance.

Vikas



>
> Suggestion's are most welcome.
>
>
> Thanks and Regards :
>  [Rishi Solanki]
>

[Rishi Solanki]

Thanks for involvement in this discussion and reply.
But We are reusing the view,  Services and Screens as well.
only enter new uri for that. So the searching for the uri will be among
less number of uri's by the ControlServlet.
Please Correct me, I may be wrong.

Thanks and Regards :
 [Rishi Solanki]


On Thu, Mar 20, 2008 at 3:44 PM, Vikas Mayur <[hidden email]> wrote:

> On Thu, Mar 20, 2008 at 2:25 PM, Rishi Solanki <[hidden email]>
> wrote:
>
> > Hi All,
> >
> > I have a question related to including other application controller in
> to
> > new under development application.
> > For example : We have included five more controller in projectmgr
> > application as ; catalog, ordermgr, accounting, workeffort, and
> humanres.
> > Here I think that if we have to use 20 - 30 uri of other controller, and
> > suppose all controllers have 100 uri.
> > So, Here is my question that,
> > Should we include these five controllers in projectmgr or we may create
> > new
> > uri's for the same in the projectmgr component. Because
> > as per my understanding, every time the uri when not found in the
> > controller
> > of projectmgr it will search the same uri in other controller
> > as per sequence they included in the projectmgr controller.
> > Now which approach is better in such case if we consider the performance
> :
> > " Either we should include the controller in the new application
> > controller
> > or we may write our own uri's in new application controller. "
> >
> > My vote is we should go for Write our own uri in the new application
> > controller.
>
>
>
> This is not a best practice, this totally does not favour code
> re-usability
> and maintenance.
>
> Vikas
>
>
>
> >
> > Suggestion's are most welcome.
> >
> >
> > Thanks and Regards :
> >  [Rishi Solanki]
> >
>

[David E Jones]

This is something that could certainly swing both ways. In general  
though if you don't want all requests and views from another  
controller.xml file then including it is probably not the best idea.

Controller request and view entries are so small that some redundancy  
there is not a big deal, and is a cost that could be outweighed by the  
benefit of being able to look at the controller.xml file, in this case  
for the Project Manager app, and see all of the requests and views  
involved in the app. If request and view definitions from a bunch of  
other controller.xml files are simply included then it is a LOT of  
work to figure out which ones are used and which ones aren't, making  
maintenance and future development significantly more difficult.

In general Vikas is right that reusing as much as possible is the way  
to go and will result in less code and easier to maintain  
applications. However, if you are getting a lot more than your want in  
reusing something it may be worse (which isn't the case for most  
tools, but certainly applies here) then it may actually be a bad thing  
and not a good one.

If there was a way to specify requests and views to leave out when  
including another controller.xml file then including them from 5 other  
apps for just a few here and there would be acceptable (there wouldn't  
be a bunch of bogus and unused requests and views), but it wouldn't be  
very efficient because you would have so many exclusions just to  
include a few things here and there.

So yes, I'd say the approach Rishi is proposing is the better way:  
only include the controller.xml files if you want all of the requests  
and views, and don't worry about the minimal redundancy in redefining  
the requests and views for a derived application. In fact, this is  
usually a good thing as it allows for variations in screen flows and  
such.

-David


On Mar 20, 2008, at 5:58 AM, Rishi Solanki wrote:

> Thanks for involvement in this discussion and reply.
> But We are reusing the view,  Services and Screens as well.
> only enter new uri for that. So the searching for the uri will be  
> among
> less number of uri's by the ControlServlet.
> Please Correct me, I may be wrong.
>
> Thanks and Regards :
> [Rishi Solanki]
>
>
> On Thu, Mar 20, 2008 at 3:44 PM, Vikas Mayur <[hidden email]>  
> wrote:
>
>> On Thu, Mar 20, 2008 at 2:25 PM, Rishi Solanki <[hidden email]
>> >
>> wrote:
>>
>>> Hi All,
>>>
>>> I have a question related to including other application  
>>> controller in
>> to
>>> new under development application.
>>> For example : We have included five more controller in projectmgr
>>> application as ; catalog, ordermgr, accounting, workeffort, and
>> humanres.
>>> Here I think that if we have to use 20 - 30 uri of other  
>>> controller, and
>>> suppose all controllers have 100 uri.
>>> So, Here is my question that,
>>> Should we include these five controllers in projectmgr or we may  
>>> create
>>> new
>>> uri's for the same in the projectmgr component. Because
>>> as per my understanding, every time the uri when not found in the
>>> controller
>>> of projectmgr it will search the same uri in other controller
>>> as per sequence they included in the projectmgr controller.
>>> Now which approach is better in such case if we consider the  
>>> performance
>> :
>>> " Either we should include the controller in the new application
>>> controller
>>> or we may write our own uri's in new application controller. "
>>>
>>> My vote is we should go for Write our own uri in the new application
>>> controller.
>>
>>
>>
>> This is not a best practice, this totally does not favour code
>> re-usability
>> and maintenance.
>>
>> Vikas
>>
>>
>>
>>>
>>> Suggestion's are most welcome.
>>>
>>>
>>> Thanks and Regards :
>>> [Rishi Solanki]
>>>
>>

[Mridul Pathak-2]

That was a really awesome explaination from David.  I too agree with the
Rishi's point here.  I would like to add one more point in this discussion.
If we want to use a couple of request from other controller then instead of
including that controller we can make use of inter-application request call
functionality in OFBiz.  This exists in both, form-widgets and ftl's.  Like
for example, in ftl's I have seen and used call's to *
/content/control/ViewSimpleContent*, here we didn't included controller of *
Content* component and have reused the request from its controller as well.
I think this way we can call requests from other components as well.  This
can solve both the problems at times, i.e. you won't need to include another
controller, and also no need to define a duplicate request in your
controller.  And the concept of reusability is sustaines as well.


On Thu, Mar 20, 2008 at 9:09 PM, David E Jones <[hidden email]>
wrote:

>
> This is something that could certainly swing both ways. In general
> though if you don't want all requests and views from another
> controller.xml file then including it is probably not the best idea.
>
> Controller request and view entries are so small that some redundancy
> there is not a big deal, and is a cost that could be outweighed by the
> benefit of being able to look at the controller.xml file, in this case
> for the Project Manager app, and see all of the requests and views
> involved in the app. If request and view definitions from a bunch of
> other controller.xml files are simply included then it is a LOT of
> work to figure out which ones are used and which ones aren't, making
> maintenance and future development significantly more difficult.
>
> In general Vikas is right that reusing as much as possible is the way
> to go and will result in less code and easier to maintain
> applications. However, if you are getting a lot more than your want in
> reusing something it may be worse (which isn't the case for most
> tools, but certainly applies here) then it may actually be a bad thing
> and not a good one.
>
> If there was a way to specify requests and views to leave out when
> including another controller.xml file then including them from 5 other
> apps for just a few here and there would be acceptable (there wouldn't
> be a bunch of bogus and unused requests and views), but it wouldn't be
> very efficient because you would have so many exclusions just to
> include a few things here and there.
>
> So yes, I'd say the approach Rishi is proposing is the better way:
> only include the controller.xml files if you want all of the requests
> and views, and don't worry about the minimal redundancy in redefining
> the requests and views for a derived application. In fact, this is
> usually a good thing as it allows for variations in screen flows and
> such.
>
> -David
>
>
> On Mar 20, 2008, at 5:58 AM, Rishi Solanki wrote:
> > Thanks for involvement in this discussion and reply.
> > But We are reusing the view,  Services and Screens as well.
> > only enter new uri for that. So the searching for the uri will be
> > among
> > less number of uri's by the ControlServlet.
> > Please Correct me, I may be wrong.
> >
> > Thanks and Regards :
> > [Rishi Solanki]
> >
> >
> > On Thu, Mar 20, 2008 at 3:44 PM, Vikas Mayur <[hidden email]>
> > wrote:
> >
> >> On Thu, Mar 20, 2008 at 2:25 PM, Rishi Solanki <[hidden email]
> >> >
> >> wrote:
> >>
> >>> Hi All,
> >>>
> >>> I have a question related to including other application
> >>> controller in
> >> to
> >>> new under development application.
> >>> For example : We have included five more controller in projectmgr
> >>> application as ; catalog, ordermgr, accounting, workeffort, and
> >> humanres.
> >>> Here I think that if we have to use 20 - 30 uri of other
> >>> controller, and
> >>> suppose all controllers have 100 uri.
> >>> So, Here is my question that,
> >>> Should we include these five controllers in projectmgr or we may
> >>> create
> >>> new
> >>> uri's for the same in the projectmgr component. Because
> >>> as per my understanding, every time the uri when not found in the
> >>> controller
> >>> of projectmgr it will search the same uri in other controller
> >>> as per sequence they included in the projectmgr controller.
> >>> Now which approach is better in such case if we consider the
> >>> performance
> >> :
> >>> " Either we should include the controller in the new application
> >>> controller
> >>> or we may write our own uri's in new application controller. "
> >>>
> >>> My vote is we should go for Write our own uri in the new application
> >>> controller.
> >>
> >>
> >>
> >> This is not a best practice, this totally does not favour code
> >> re-usability
> >> and maintenance.
> >>
> >> Vikas
> >>
> >>
> >>
> >>>
> >>> Suggestion's are most welcome.
> >>>
> >>>
> >>> Thanks and Regards :
> >>> [Rishi Solanki]
> >>>
> >>
>
>

--
Thanks & Regards
Mridul Pathak
Hotwax Media
http://www.hotwaxmedia.com
[hidden email]
__________________________________
Office : 509.855.4113
Mobile : [phone]

[Sumit Pandit-3]

Hello all,
This is really a great explanation given by David.
Continuing to this I would like to ask similar question to the community,

Let the assume the situation where I am working in a component (say
order) and if I want UiLabel entry(one or more ?) from some different
component (say party). So which is batter option :-
1) include the UiLabel of party or
2) make a new entry in the OrderUiLabels.xml ?

Again I will go with second option.

Also I am highly recommended the following lines written by David :-
*However, if you are getting a lot more than your want in reusing
something it may be worse (which isn't the case for most tools, but
certainly applies here) then it may actually be a bad thing and not a
good one.   :    *Is it applies here ?

Thanks
Sumit


David E Jones wrote:

>
> This is something that could certainly swing both ways. In general
> though if you don't want all requests and views from another
> controller.xml file then including it is probably not the best idea.
>
> Controller request and view entries are so small that some redundancy
> there is not a big deal, and is a cost that could be outweighed by the
> benefit of being able to look at the controller.xml file, in this case
> for the Project Manager app, and see all of the requests and views
> involved in the app. If request and view definitions from a bunch of
> other controller.xml files are simply included then it is a LOT of
> work to figure out which ones are used and which ones aren't, making
> maintenance and future development significantly more difficult.
>
> In general Vikas is right that reusing as much as possible is the way
> to go and will result in less code and easier to maintain
> applications. However, if you are getting a lot more than your want in
> reusing something it may be worse (which isn't the case for most
> tools, but certainly applies here) then it may actually be a bad thing
> and not a good one.
>
> If there was a way to specify requests and views to leave out when
> including another controller.xml file then including them from 5 other
> apps for just a few here and there would be acceptable (there wouldn't
> be a bunch of bogus and unused requests and views), but it wouldn't be
> very efficient because you would have so many exclusions just to
> include a few things here and there.
>
> So yes, I'd say the approach Rishi is proposing is the better way:
> only include the controller.xml files if you want all of the requests
> and views, and don't worry about the minimal redundancy in redefining
> the requests and views for a derived application. In fact, this is
> usually a good thing as it allows for variations in screen flows and
> such.
>
> -David
>
>
> On Mar 20, 2008, at 5:58 AM, Rishi Solanki wrote:
>> Thanks for involvement in this discussion and reply.
>> But We are reusing the view,  Services and Screens as well.
>> only enter new uri for that. So the searching for the uri will be among
>> less number of uri's by the ControlServlet.
>> Please Correct me, I may be wrong.
>>
>> Thanks and Regards :
>> [Rishi Solanki]
>>
>>
>> On Thu, Mar 20, 2008 at 3:44 PM, Vikas Mayur <[hidden email]>
>> wrote:
>>
>>> On Thu, Mar 20, 2008 at 2:25 PM, Rishi Solanki
>>> <[hidden email]>
>>> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I have a question related to including other application controller in
>>> to
>>>> new under development application.
>>>> For example : We have included five more controller in projectmgr
>>>> application as ; catalog, ordermgr, accounting, workeffort, and
>>> humanres.
>>>> Here I think that if we have to use 20 - 30 uri of other
>>>> controller, and
>>>> suppose all controllers have 100 uri.
>>>> So, Here is my question that,
>>>> Should we include these five controllers in projectmgr or we may
>>>> create
>>>> new
>>>> uri's for the same in the projectmgr component. Because
>>>> as per my understanding, every time the uri when not found in the
>>>> controller
>>>> of projectmgr it will search the same uri in other controller
>>>> as per sequence they included in the projectmgr controller.
>>>> Now which approach is better in such case if we consider the
>>>> performance
>>> :
>>>> " Either we should include the controller in the new application
>>>> controller
>>>> or we may write our own uri's in new application controller. "
>>>>
>>>> My vote is we should go for Write our own uri in the new application
>>>> controller.
>>>
>>>
>>>
>>> This is not a best practice, this totally does not favour code
>>> re-usability
>>> and maintenance.
>>>
>>> Vikas
>>>
>>>
>>>
>>>>
>>>> Suggestion's are most welcome.
>>>>
>>>>
>>>> Thanks and Regards :
>>>> [Rishi Solanki]
>>>>
>>>
>

[David E Jones]

For the including controller.xml files I'd say that applies, it is  
worse than the minimal redundancy resulting from copying a few request  
and view defs.

For *UiLabel.* files I'd say it does not apply. Those are meant to be  
a big set of labels, and with those not including would result in  
massive redundancy (which is happening already, and is rough to  
maintain and generally bad).

-David


On Mar 24, 2008, at 5:31 PM, Sumit Pandit wrote:

> Hello all,
> This is really a great explanation given by David.
> Continuing to this I would like to ask similar question to the  
> community,
>
> Let the assume the situation where I am working in a component (say  
> order) and if I want UiLabel entry(one or more ?) from some  
> different component (say party). So which is batter option :-
> 1) include the UiLabel of party or
> 2) make a new entry in the OrderUiLabels.xml ?
>
> Again I will go with second option.
>
> Also I am highly recommended the following lines written by David :-
> *However, if you are getting a lot more than your want in reusing  
> something it may be worse (which isn't the case for most tools, but  
> certainly applies here) then it may actually be a bad thing and not  
> a good one.   :    *Is it applies here ?
>
> Thanks
> Sumit
>
>
> David E Jones wrote:
>>
>> This is something that could certainly swing both ways. In general  
>> though if you don't want all requests and views from another  
>> controller.xml file then including it is probably not the best idea.
>>
>> Controller request and view entries are so small that some  
>> redundancy there is not a big deal, and is a cost that could be  
>> outweighed by the benefit of being able to look at the  
>> controller.xml file, in this case for the Project Manager app, and  
>> see all of the requests and views involved in the app. If request  
>> and view definitions from a bunch of other controller.xml files are  
>> simply included then it is a LOT of work to figure out which ones  
>> are used and which ones aren't, making maintenance and future  
>> development significantly more difficult.
>>
>> In general Vikas is right that reusing as much as possible is the  
>> way to go and will result in less code and easier to maintain  
>> applications. However, if you are getting a lot more than your want  
>> in reusing something it may be worse (which isn't the case for most  
>> tools, but certainly applies here) then it may actually be a bad  
>> thing and not a good one.
>>
>> If there was a way to specify requests and views to leave out when  
>> including another controller.xml file then including them from 5  
>> other apps for just a few here and there would be acceptable (there  
>> wouldn't be a bunch of bogus and unused requests and views), but it  
>> wouldn't be very efficient because you would have so many  
>> exclusions just to include a few things here and there.
>>
>> So yes, I'd say the approach Rishi is proposing is the better way:  
>> only include the controller.xml files if you want all of the  
>> requests and views, and don't worry about the minimal redundancy in  
>> redefining the requests and views for a derived application. In  
>> fact, this is usually a good thing as it allows for variations in  
>> screen flows and such.
>>
>> -David
>>
>>
>> On Mar 20, 2008, at 5:58 AM, Rishi Solanki wrote:
>>> Thanks for involvement in this discussion and reply.
>>> But We are reusing the view,  Services and Screens as well.
>>> only enter new uri for that. So the searching for the uri will be  
>>> among
>>> less number of uri's by the ControlServlet.
>>> Please Correct me, I may be wrong.
>>>
>>> Thanks and Regards :
>>> [Rishi Solanki]
>>>
>>>
>>> On Thu, Mar 20, 2008 at 3:44 PM, Vikas Mayur  
>>> <[hidden email]> wrote:
>>>
>>>> On Thu, Mar 20, 2008 at 2:25 PM, Rishi Solanki <[hidden email]
>>>> >
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I have a question related to including other application  
>>>>> controller in
>>>> to
>>>>> new under development application.
>>>>> For example : We have included five more controller in projectmgr
>>>>> application as ; catalog, ordermgr, accounting, workeffort, and
>>>> humanres.
>>>>> Here I think that if we have to use 20 - 30 uri of other  
>>>>> controller, and
>>>>> suppose all controllers have 100 uri.
>>>>> So, Here is my question that,
>>>>> Should we include these five controllers in projectmgr or we may  
>>>>> create
>>>>> new
>>>>> uri's for the same in the projectmgr component. Because
>>>>> as per my understanding, every time the uri when not found in the
>>>>> controller
>>>>> of projectmgr it will search the same uri in other controller
>>>>> as per sequence they included in the projectmgr controller.
>>>>> Now which approach is better in such case if we consider the  
>>>>> performance
>>>> :
>>>>> " Either we should include the controller in the new application
>>>>> controller
>>>>> or we may write our own uri's in new application controller. "
>>>>>
>>>>> My vote is we should go for Write our own uri in the new  
>>>>> application
>>>>> controller.
>>>>
>>>>
>>>>
>>>> This is not a best practice, this totally does not favour code
>>>> re-usability
>>>> and maintenance.
>>>>
>>>> Vikas
>>>>
>>>>
>>>>
>>>>>
>>>>> Suggestion's are most welcome.
>>>>>
>>>>>
>>>>> Thanks and Regards :
>>>>> [Rishi Solanki]
>>>>>
>>>>
>>
>

[Rishi Solanki]

Hello All,

As per my understanding, I wish to add some reasonable points in this
discussion of uiLables.
Here when we start our application (after starting the server) then all the
uiLables are loaded once,
in turn, there will be no searching time increases when server search for
uiLables values
(means the time is negligible when we comparing it with cost on
maintainance).

Thanks and Regards :
 [Rishi Solanki]


On Tue, Mar 25, 2008 at 9:04 AM, David E Jones <[hidden email]>
wrote:

>
> For the including controller.xml files I'd say that applies, it is
> worse than the minimal redundancy resulting from copying a few request
> and view defs.
>
> For *UiLabel.* files I'd say it does not apply. Those are meant to be
> a big set of labels, and with those not including would result in
> massive redundancy (which is happening already, and is rough to
> maintain and generally bad).
>
> -David
>
>
> On Mar 24, 2008, at 5:31 PM, Sumit Pandit wrote:
> > Hello all,
> > This is really a great explanation given by David.
> > Continuing to this I would like to ask similar question to the
> > community,
> >
> > Let the assume the situation where I am working in a component (say
> > order) and if I want UiLabel entry(one or more ?) from some
> > different component (say party). So which is batter option :-
> > 1) include the UiLabel of party or
> > 2) make a new entry in the OrderUiLabels.xml ?
> >
> > Again I will go with second option.
> >
> > Also I am highly recommended the following lines written by David :-
> > *However, if you are getting a lot more than your want in reusing
> > something it may be worse (which isn't the case for most tools, but
> > certainly applies here) then it may actually be a bad thing and not
> > a good one.   :    *Is it applies here ?
> >
> > Thanks
> > Sumit
> >
> >
> > David E Jones wrote:
> >>
> >> This is something that could certainly swing both ways. In general
> >> though if you don't want all requests and views from another
> >> controller.xml file then including it is probably not the best idea.
> >>
> >> Controller request and view entries are so small that some
> >> redundancy there is not a big deal, and is a cost that could be
> >> outweighed by the benefit of being able to look at the
> >> controller.xml file, in this case for the Project Manager app, and
> >> see all of the requests and views involved in the app. If request
> >> and view definitions from a bunch of other controller.xml files are
> >> simply included then it is a LOT of work to figure out which ones
> >> are used and which ones aren't, making maintenance and future
> >> development significantly more difficult.
> >>
> >> In general Vikas is right that reusing as much as possible is the
> >> way to go and will result in less code and easier to maintain
> >> applications. However, if you are getting a lot more than your want
> >> in reusing something it may be worse (which isn't the case for most
> >> tools, but certainly applies here) then it may actually be a bad
> >> thing and not a good one.
> >>
> >> If there was a way to specify requests and views to leave out when
> >> including another controller.xml file then including them from 5
> >> other apps for just a few here and there would be acceptable (there
> >> wouldn't be a bunch of bogus and unused requests and views), but it
> >> wouldn't be very efficient because you would have so many
> >> exclusions just to include a few things here and there.
> >>
> >> So yes, I'd say the approach Rishi is proposing is the better way:
> >> only include the controller.xml files if you want all of the
> >> requests and views, and don't worry about the minimal redundancy in
> >> redefining the requests and views for a derived application. In
> >> fact, this is usually a good thing as it allows for variations in
> >> screen flows and such.
> >>
> >> -David
> >>
> >>
> >> On Mar 20, 2008, at 5:58 AM, Rishi Solanki wrote:
> >>> Thanks for involvement in this discussion and reply.
> >>> But We are reusing the view,  Services and Screens as well.
> >>> only enter new uri for that. So the searching for the uri will be
> >>> among
> >>> less number of uri's by the ControlServlet.
> >>> Please Correct me, I may be wrong.
> >>>
> >>> Thanks and Regards :
> >>> [Rishi Solanki]
> >>>
> >>>
> >>> On Thu, Mar 20, 2008 at 3:44 PM, Vikas Mayur
> >>> <[hidden email]> wrote:
> >>>
> >>>> On Thu, Mar 20, 2008 at 2:25 PM, Rishi Solanki <
> [hidden email]
> >>>> >
> >>>> wrote:
> >>>>
> >>>>> Hi All,
> >>>>>
> >>>>> I have a question related to including other application
> >>>>> controller in
> >>>> to
> >>>>> new under development application.
> >>>>> For example : We have included five more controller in projectmgr
> >>>>> application as ; catalog, ordermgr, accounting, workeffort, and
> >>>> humanres.
> >>>>> Here I think that if we have to use 20 - 30 uri of other
> >>>>> controller, and
> >>>>> suppose all controllers have 100 uri.
> >>>>> So, Here is my question that,
> >>>>> Should we include these five controllers in projectmgr or we may
> >>>>> create
> >>>>> new
> >>>>> uri's for the same in the projectmgr component. Because
> >>>>> as per my understanding, every time the uri when not found in the
> >>>>> controller
> >>>>> of projectmgr it will search the same uri in other controller
> >>>>> as per sequence they included in the projectmgr controller.
> >>>>> Now which approach is better in such case if we consider the
> >>>>> performance
> >>>> :
> >>>>> " Either we should include the controller in the new application
> >>>>> controller
> >>>>> or we may write our own uri's in new application controller. "
> >>>>>
> >>>>> My vote is we should go for Write our own uri in the new
> >>>>> application
> >>>>> controller.
> >>>>
> >>>>
> >>>>
> >>>> This is not a best practice, this totally does not favour code
> >>>> re-usability
> >>>> and maintenance.
> >>>>
> >>>> Vikas
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>> Suggestion's are most welcome.
> >>>>>
> >>>>>
> >>>>> Thanks and Regards :
> >>>>> [Rishi Solanki]
> >>>>>
> >>>>
> >>
> >
>
>

[Bruno Busco]

Hi,
about UiLabels redundancy please read this jira issue:
https://issues.apache.org/jira/browse/OFBIZ-1698

Here i have attached a python script that could completely remove UiLabels
redundancy. We are in the phase of having an agreement about the files
hierarchy order. This will affect where a redundant label will be left or
deleted.

- Bruno

2008/3/25, Rishi Solanki <[hidden email]>:

>
> Hello All,
>
> As per my understanding, I wish to add some reasonable points in this
> discussion of uiLables.
> Here when we start our application (after starting the server) then all
> the
> uiLables are loaded once,
> in turn, there will be no searching time increases when server search for
> uiLables values
> (means the time is negligible when we comparing it with cost on
> maintainance).
>
>
> Thanks and Regards :
>   [Rishi Solanki]
>
>
>
> On Tue, Mar 25, 2008 at 9:04 AM, David E Jones <[hidden email]>
> wrote:
>
> >
>
> > For the including controller.xml files I'd say that applies, it is
> > worse than the minimal redundancy resulting from copying a few request
> > and view defs.
> >
> > For *UiLabel.* files I'd say it does not apply. Those are meant to be
> > a big set of labels, and with those not including would result in
> > massive redundancy (which is happening already, and is rough to
> > maintain and generally bad).
> >
> > -David
> >
> >
> > On Mar 24, 2008, at 5:31 PM, Sumit Pandit wrote:
> > > Hello all,
> > > This is really a great explanation given by David.
> > > Continuing to this I would like to ask similar question to the
> > > community,
> > >
> > > Let the assume the situation where I am working in a component (say
> > > order) and if I want UiLabel entry(one or more ?) from some
> > > different component (say party). So which is batter option :-
> > > 1) include the UiLabel of party or
> > > 2) make a new entry in the OrderUiLabels.xml ?
> > >
> > > Again I will go with second option.
> > >
> > > Also I am highly recommended the following lines written by David :-
> > > *However, if you are getting a lot more than your want in reusing
> > > something it may be worse (which isn't the case for most tools, but
> > > certainly applies here) then it may actually be a bad thing and not
> > > a good one.   :    *Is it applies here ?
> > >
> > > Thanks
> > > Sumit
> > >
> > >
> > > David E Jones wrote:
> > >>
> > >> This is something that could certainly swing both ways. In general
> > >> though if you don't want all requests and views from another
> > >> controller.xml file then including it is probably not the best idea.
> > >>
> > >> Controller request and view entries are so small that some
> > >> redundancy there is not a big deal, and is a cost that could be
> > >> outweighed by the benefit of being able to look at the
> > >> controller.xml file, in this case for the Project Manager app, and
> > >> see all of the requests and views involved in the app. If request
> > >> and view definitions from a bunch of other controller.xml files are
> > >> simply included then it is a LOT of work to figure out which ones
> > >> are used and which ones aren't, making maintenance and future
> > >> development significantly more difficult.
> > >>
> > >> In general Vikas is right that reusing as much as possible is the
> > >> way to go and will result in less code and easier to maintain
> > >> applications. However, if you are getting a lot more than your want
> > >> in reusing something it may be worse (which isn't the case for most
> > >> tools, but certainly applies here) then it may actually be a bad
> > >> thing and not a good one.
> > >>
> > >> If there was a way to specify requests and views to leave out when
> > >> including another controller.xml file then including them from 5
> > >> other apps for just a few here and there would be acceptable (there
> > >> wouldn't be a bunch of bogus and unused requests and views), but it
> > >> wouldn't be very efficient because you would have so many
> > >> exclusions just to include a few things here and there.
> > >>
> > >> So yes, I'd say the approach Rishi is proposing is the better way:
> > >> only include the controller.xml files if you want all of the
> > >> requests and views, and don't worry about the minimal redundancy in
> > >> redefining the requests and views for a derived application. In
> > >> fact, this is usually a good thing as it allows for variations in
> > >> screen flows and such.
> > >>
> > >> -David
> > >>
> > >>
> > >> On Mar 20, 2008, at 5:58 AM, Rishi Solanki wrote:
> > >>> Thanks for involvement in this discussion and reply.
> > >>> But We are reusing the view,  Services and Screens as well.
> > >>> only enter new uri for that. So the searching for the uri will be
> > >>> among
> > >>> less number of uri's by the ControlServlet.
> > >>> Please Correct me, I may be wrong.
> > >>>
> > >>> Thanks and Regards :
> > >>> [Rishi Solanki]
> > >>>
> > >>>
> > >>> On Thu, Mar 20, 2008 at 3:44 PM, Vikas Mayur
> > >>> <[hidden email]> wrote:
> > >>>
> > >>>> On Thu, Mar 20, 2008 at 2:25 PM, Rishi Solanki <
> > [hidden email]
> > >>>> >
> > >>>> wrote:
> > >>>>
> > >>>>> Hi All,
> > >>>>>
> > >>>>> I have a question related to including other application
> > >>>>> controller in
> > >>>> to
> > >>>>> new under development application.
> > >>>>> For example : We have included five more controller in projectmgr
> > >>>>> application as ; catalog, ordermgr, accounting, workeffort, and
> > >>>> humanres.
> > >>>>> Here I think that if we have to use 20 - 30 uri of other
> > >>>>> controller, and
> > >>>>> suppose all controllers have 100 uri.
> > >>>>> So, Here is my question that,
> > >>>>> Should we include these five controllers in projectmgr or we may
> > >>>>> create
> > >>>>> new
> > >>>>> uri's for the same in the projectmgr component. Because
> > >>>>> as per my understanding, every time the uri when not found in the
> > >>>>> controller
> > >>>>> of projectmgr it will search the same uri in other controller
> > >>>>> as per sequence they included in the projectmgr controller.
> > >>>>> Now which approach is better in such case if we consider the
> > >>>>> performance
> > >>>> :
> > >>>>> " Either we should include the controller in the new application
> > >>>>> controller
> > >>>>> or we may write our own uri's in new application controller. "
> > >>>>>
> > >>>>> My vote is we should go for Write our own uri in the new
> > >>>>> application
> > >>>>> controller.
> > >>>>
> > >>>>
> > >>>>
> > >>>> This is not a best practice, this totally does not favour code
> > >>>> re-usability
> > >>>> and maintenance.
> > >>>>
> > >>>> Vikas
> > >>>>
> > >>>>
> > >>>>
> > >>>>>
> > >>>>> Suggestion's are most welcome.
> > >>>>>
> > >>>>>
> > >>>>> Thanks and Regards :
> > >>>>> [Rishi Solanki]
> > >>>>>
> > >>>>
> > >>
> > >
> >
> >
>

[Jacques Le Roux]

Hi All,

In this respect Bruno Busco has suggested an order for UiLabels.xml files in
https://issues.apache.org/jira/browse/OFBIZ-1698?focusedCommentId=12581154#action_12581154

What do you think ?

Jacques

PS : I have already posted this on dev ML but got no answers so far

From: "David E Jones" <[hidden email]>

>
> For the including controller.xml files I'd say that applies, it is  
> worse than the minimal redundancy resulting from copying a few request  
> and view defs.
>
> For *UiLabel.* files I'd say it does not apply. Those are meant to be  
> a big set of labels, and with those not including would result in  
> massive redundancy (which is happening already, and is rough to  
> maintain and generally bad).
>
> -David
>
>
> On Mar 24, 2008, at 5:31 PM, Sumit Pandit wrote:
>> Hello all,
>> This is really a great explanation given by David.
>> Continuing to this I would like to ask similar question to the  
>> community,
>>
>> Let the assume the situation where I am working in a component (say  
>> order) and if I want UiLabel entry(one or more ?) from some  
>> different component (say party). So which is batter option :-
>> 1) include the UiLabel of party or
>> 2) make a new entry in the OrderUiLabels.xml ?
>>
>> Again I will go with second option.
>>
>> Also I am highly recommended the following lines written by David :-
>> *However, if you are getting a lot more than your want in reusing  
>> something it may be worse (which isn't the case for most tools, but  
>> certainly applies here) then it may actually be a bad thing and not  
>> a good one.   :    *Is it applies here ?
>>
>> Thanks
>> Sumit
>>
>>
>> David E Jones wrote:
>>>
>>> This is something that could certainly swing both ways. In general  
>>> though if you don't want all requests and views from another  
>>> controller.xml file then including it is probably not the best idea.
>>>
>>> Controller request and view entries are so small that some  
>>> redundancy there is not a big deal, and is a cost that could be  
>>> outweighed by the benefit of being able to look at the  
>>> controller.xml file, in this case for the Project Manager app, and  
>>> see all of the requests and views involved in the app. If request  
>>> and view definitions from a bunch of other controller.xml files are  
>>> simply included then it is a LOT of work to figure out which ones  
>>> are used and which ones aren't, making maintenance and future  
>>> development significantly more difficult.
>>>
>>> In general Vikas is right that reusing as much as possible is the  
>>> way to go and will result in less code and easier to maintain  
>>> applications. However, if you are getting a lot more than your want  
>>> in reusing something it may be worse (which isn't the case for most  
>>> tools, but certainly applies here) then it may actually be a bad  
>>> thing and not a good one.
>>>
>>> If there was a way to specify requests and views to leave out when  
>>> including another controller.xml file then including them from 5  
>>> other apps for just a few here and there would be acceptable (there  
>>> wouldn't be a bunch of bogus and unused requests and views), but it  
>>> wouldn't be very efficient because you would have so many  
>>> exclusions just to include a few things here and there.
>>>
>>> So yes, I'd say the approach Rishi is proposing is the better way:  
>>> only include the controller.xml files if you want all of the  
>>> requests and views, and don't worry about the minimal redundancy in  
>>> redefining the requests and views for a derived application. In  
>>> fact, this is usually a good thing as it allows for variations in  
>>> screen flows and such.
>>>
>>> -David
>>>
>>>
>>> On Mar 20, 2008, at 5:58 AM, Rishi Solanki wrote:
>>>> Thanks for involvement in this discussion and reply.
>>>> But We are reusing the view,  Services and Screens as well.
>>>> only enter new uri for that. So the searching for the uri will be  
>>>> among
>>>> less number of uri's by the ControlServlet.
>>>> Please Correct me, I may be wrong.
>>>>
>>>> Thanks and Regards :
>>>> [Rishi Solanki]
>>>>
>>>>
>>>> On Thu, Mar 20, 2008 at 3:44 PM, Vikas Mayur  
>>>> <[hidden email]> wrote:
>>>>
>>>>> On Thu, Mar 20, 2008 at 2:25 PM, Rishi Solanki <[hidden email]
>>>>> >
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I have a question related to including other application  
>>>>>> controller in
>>>>> to
>>>>>> new under development application.
>>>>>> For example : We have included five more controller in projectmgr
>>>>>> application as ; catalog, ordermgr, accounting, workeffort, and
>>>>> humanres.
>>>>>> Here I think that if we have to use 20 - 30 uri of other  
>>>>>> controller, and
>>>>>> suppose all controllers have 100 uri.
>>>>>> So, Here is my question that,
>>>>>> Should we include these five controllers in projectmgr or we may  
>>>>>> create
>>>>>> new
>>>>>> uri's for the same in the projectmgr component. Because
>>>>>> as per my understanding, every time the uri when not found in the
>>>>>> controller
>>>>>> of projectmgr it will search the same uri in other controller
>>>>>> as per sequence they included in the projectmgr controller.
>>>>>> Now which approach is better in such case if we consider the  
>>>>>> performance
>>>>> :
>>>>>> " Either we should include the controller in the new application
>>>>>> controller
>>>>>> or we may write our own uri's in new application controller. "
>>>>>>
>>>>>> My vote is we should go for Write our own uri in the new  
>>>>>> application
>>>>>> controller.
>>>>>
>>>>>
>>>>>
>>>>> This is not a best practice, this totally does not favour code
>>>>> re-usability
>>>>> and maintenance.
>>>>>
>>>>> Vikas
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Suggestion's are most welcome.
>>>>>>
>>>>>>
>>>>>> Thanks and Regards :
>>>>>> [Rishi Solanki]
>>>>>>
>>>>>
>>>
>>
>

[Jacques Le Roux]

Hi Bruno,

Seems that we are on the same page today :D

Jacques

From: "Bruno Busco" <[hidden email]>

> Hi,
> about UiLabels redundancy please read this jira issue:
> https://issues.apache.org/jira/browse/OFBIZ-1698
>
> Here i have attached a python script that could completely remove UiLabels
> redundancy. We are in the phase of having an agreement about the files
> hierarchy order. This will affect where a redundant label will be left or
> deleted.
>
> - Bruno
>
> 2008/3/25, Rishi Solanki <[hidden email]>:
>>
>> Hello All,
>>
>> As per my understanding, I wish to add some reasonable points in this
>> discussion of uiLables.
>> Here when we start our application (after starting the server) then all
>> the
>> uiLables are loaded once,
>> in turn, there will be no searching time increases when server search for
>> uiLables values
>> (means the time is negligible when we comparing it with cost on
>> maintainance).
>>
>>
>> Thanks and Regards :
>>   [Rishi Solanki]
>>
>>
>>
>> On Tue, Mar 25, 2008 at 9:04 AM, David E Jones <[hidden email]>
>> wrote:
>>
>> >
>>
>> > For the including controller.xml files I'd say that applies, it is
>> > worse than the minimal redundancy resulting from copying a few request
>> > and view defs.
>> >
>> > For *UiLabel.* files I'd say it does not apply. Those are meant to be
>> > a big set of labels, and with those not including would result in
>> > massive redundancy (which is happening already, and is rough to
>> > maintain and generally bad).
>> >
>> > -David
>> >
>> >
>> > On Mar 24, 2008, at 5:31 PM, Sumit Pandit wrote:
>> > > Hello all,
>> > > This is really a great explanation given by David.
>> > > Continuing to this I would like to ask similar question to the
>> > > community,
>> > >
>> > > Let the assume the situation where I am working in a component (say
>> > > order) and if I want UiLabel entry(one or more ?) from some
>> > > different component (say party). So which is batter option :-
>> > > 1) include the UiLabel of party or
>> > > 2) make a new entry in the OrderUiLabels.xml ?
>> > >
>> > > Again I will go with second option.
>> > >
>> > > Also I am highly recommended the following lines written by David :-
>> > > *However, if you are getting a lot more than your want in reusing
>> > > something it may be worse (which isn't the case for most tools, but
>> > > certainly applies here) then it may actually be a bad thing and not
>> > > a good one.   :    *Is it applies here ?
>> > >
>> > > Thanks
>> > > Sumit
>> > >
>> > >
>> > > David E Jones wrote:
>> > >>
>> > >> This is something that could certainly swing both ways. In general
>> > >> though if you don't want all requests and views from another
>> > >> controller.xml file then including it is probably not the best idea.
>> > >>
>> > >> Controller request and view entries are so small that some
>> > >> redundancy there is not a big deal, and is a cost that could be
>> > >> outweighed by the benefit of being able to look at the
>> > >> controller.xml file, in this case for the Project Manager app, and
>> > >> see all of the requests and views involved in the app. If request
>> > >> and view definitions from a bunch of other controller.xml files are
>> > >> simply included then it is a LOT of work to figure out which ones
>> > >> are used and which ones aren't, making maintenance and future
>> > >> development significantly more difficult.
>> > >>
>> > >> In general Vikas is right that reusing as much as possible is the
>> > >> way to go and will result in less code and easier to maintain
>> > >> applications. However, if you are getting a lot more than your want
>> > >> in reusing something it may be worse (which isn't the case for most
>> > >> tools, but certainly applies here) then it may actually be a bad
>> > >> thing and not a good one.
>> > >>
>> > >> If there was a way to specify requests and views to leave out when
>> > >> including another controller.xml file then including them from 5
>> > >> other apps for just a few here and there would be acceptable (there
>> > >> wouldn't be a bunch of bogus and unused requests and views), but it
>> > >> wouldn't be very efficient because you would have so many
>> > >> exclusions just to include a few things here and there.
>> > >>
>> > >> So yes, I'd say the approach Rishi is proposing is the better way:
>> > >> only include the controller.xml files if you want all of the
>> > >> requests and views, and don't worry about the minimal redundancy in
>> > >> redefining the requests and views for a derived application. In
>> > >> fact, this is usually a good thing as it allows for variations in
>> > >> screen flows and such.
>> > >>
>> > >> -David
>> > >>
>> > >>
>> > >> On Mar 20, 2008, at 5:58 AM, Rishi Solanki wrote:
>> > >>> Thanks for involvement in this discussion and reply.
>> > >>> But We are reusing the view,  Services and Screens as well.
>> > >>> only enter new uri for that. So the searching for the uri will be
>> > >>> among
>> > >>> less number of uri's by the ControlServlet.
>> > >>> Please Correct me, I may be wrong.
>> > >>>
>> > >>> Thanks and Regards :
>> > >>> [Rishi Solanki]
>> > >>>
>> > >>>
>> > >>> On Thu, Mar 20, 2008 at 3:44 PM, Vikas Mayur
>> > >>> <[hidden email]> wrote:
>> > >>>
>> > >>>> On Thu, Mar 20, 2008 at 2:25 PM, Rishi Solanki <
>> > [hidden email]
>> > >>>> >
>> > >>>> wrote:
>> > >>>>
>> > >>>>> Hi All,
>> > >>>>>
>> > >>>>> I have a question related to including other application
>> > >>>>> controller in
>> > >>>> to
>> > >>>>> new under development application.
>> > >>>>> For example : We have included five more controller in projectmgr
>> > >>>>> application as ; catalog, ordermgr, accounting, workeffort, and
>> > >>>> humanres.
>> > >>>>> Here I think that if we have to use 20 - 30 uri of other
>> > >>>>> controller, and
>> > >>>>> suppose all controllers have 100 uri.
>> > >>>>> So, Here is my question that,
>> > >>>>> Should we include these five controllers in projectmgr or we may
>> > >>>>> create
>> > >>>>> new
>> > >>>>> uri's for the same in the projectmgr component. Because
>> > >>>>> as per my understanding, every time the uri when not found in the
>> > >>>>> controller
>> > >>>>> of projectmgr it will search the same uri in other controller
>> > >>>>> as per sequence they included in the projectmgr controller.
>> > >>>>> Now which approach is better in such case if we consider the
>> > >>>>> performance
>> > >>>> :
>> > >>>>> " Either we should include the controller in the new application
>> > >>>>> controller
>> > >>>>> or we may write our own uri's in new application controller. "
>> > >>>>>
>> > >>>>> My vote is we should go for Write our own uri in the new
>> > >>>>> application
>> > >>>>> controller.
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> This is not a best practice, this totally does not favour code
>> > >>>> re-usability
>> > >>>> and maintenance.
>> > >>>>
>> > >>>> Vikas
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>>>
>> > >>>>> Suggestion's are most welcome.
>> > >>>>>
>> > >>>>>
>> > >>>>> Thanks and Regards :
>> > >>>>> [Rishi Solanki]
>> > >>>>>
>> > >>>>
>> > >>
>> > >
>> >
>> >
>>
>