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 <[EMAIL PROTECTED]> 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 > >>> <[EMAIL PROTECTED]> wrote: > >>> > >>>> On Thu, Mar 20, 2008 at 2:25 PM, Rishi Solanki < > [EMAIL PROTECTED] > >>>> > > >>>> 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] > >>>>> > >>>> > >> > > > >
