Discussion summaries
Locked
 
|
Dear All,
In the last days we have had some interesting duscussions about several subjects. Don't you think we need to summarize them up and write something on the stone? For example, about the Find screens what is the final one? Many thanks, -Bruno |
Administrator
|
Yes this would be smart :o)
Jacques From: "Bruno Busco" <[hidden email]> > Dear All, > In the last days we have had some interesting duscussions about several > subjects. > Don't you think we need to summarize them up and write something on the > stone? > For example, about the Find screens what is the final one? > > Many thanks, > -Bruno > |
|
|
I have all of the emails on the Find Screen discussion, so I will add it to the best practices section of the wiki. I plan to do some work on the wiki this afternoon.
By the way, it was agreed that the find screens would display a complete list at first, then the list is narrowed down by the user. The lookup screens are different - they don't display a list until the user enters search options. -Adrian --- On Sun, 6/22/08, Jacques Le Roux <[hidden email]> wrote: > From: Jacques Le Roux <[hidden email]> > Subject: Re: Discussion summaries > To: [hidden email] > Date: Sunday, June 22, 2008, 5:18 AM > Yes this would be smart :o) > > Jacques > > From: "Bruno Busco" <[hidden email]> > > Dear All, > > In the last days we have had some interesting > duscussions about several > > subjects. > > Don't you think we need to summarize them up and > write something on the > > stone? > > For example, about the Find screens what is the final > one? > > > > Many thanks, > > -Bruno > > |
|
|
Adrian,
many thanks for the update. So last commits on Lookups and Example FindScreens follows the guidelines, good! -Bruno 2008/6/22 Adrian Crum <[hidden email]>: > I have all of the emails on the Find Screen discussion, so I will add it to > the best practices section of the wiki. I plan to do some work on the wiki > this afternoon. > > By the way, it was agreed that the find screens would display a complete > list at first, then the list is narrowed down by the user. > > The lookup screens are different - they don't display a list until the user > enters search options. > > -Adrian > > > --- On Sun, 6/22/08, Jacques Le Roux <[hidden email]> wrote: > > > From: Jacques Le Roux <[hidden email]> > > Subject: Re: Discussion summaries > > To: [hidden email] > > Date: Sunday, June 22, 2008, 5:18 AM > > Yes this would be smart :o) > > > > Jacques > > > > From: "Bruno Busco" <[hidden email]> > > > Dear All, > > > In the last days we have had some interesting > > duscussions about several > > > subjects. > > > Don't you think we need to summarize them up and > > write something on the > > > stone? > > > For example, about the Find screens what is the final > > one? > > > > > > Many thanks, > > > -Bruno > > > > > > > |
|
Administrator
|
OK, but what about my argument on stress on DB ? This can be hard sometimes...
And BTW this not how it works in most of the screen for now Jacques From: "Bruno Busco" <[hidden email]> > Adrian, > many thanks for the update. > So last commits on Lookups and Example FindScreens follows the guidelines, > good! > > -Bruno > > 2008/6/22 Adrian Crum <[hidden email]>: > >> I have all of the emails on the Find Screen discussion, so I will add it to >> the best practices section of the wiki. I plan to do some work on the wiki >> this afternoon. >> >> By the way, it was agreed that the find screens would display a complete >> list at first, then the list is narrowed down by the user. >> >> The lookup screens are different - they don't display a list until the user >> enters search options. >> >> -Adrian >> >> >> --- On Sun, 6/22/08, Jacques Le Roux <[hidden email]> wrote: >> >> > From: Jacques Le Roux <[hidden email]> >> > Subject: Re: Discussion summaries >> > To: [hidden email] >> > Date: Sunday, June 22, 2008, 5:18 AM >> > Yes this would be smart :o) >> > >> > Jacques >> > >> > From: "Bruno Busco" <[hidden email]> >> > > Dear All, >> > > In the last days we have had some interesting >> > duscussions about several >> > > subjects. >> > > Don't you think we need to summarize them up and >> > write something on the >> > > stone? >> > > For example, about the Find screens what is the final >> > one? >> > > >> > > Many thanks, >> > > -Bruno >> > > >> >> >> >> > |
|
|
I agree with Jacques... it's a bad idea. I'm referring to this statement from Adrian's email: "By the way, it was agreed that the find screens would display a complete list at first, then the list is narrowed down by the user." When was that agreed to? For my part it's a big -1, and in fact I was just about to go remove that from Bruno's patch of the example component, and possibly other things too.... Really, it seems odd (no offense to you personally Bruno) that a patch from a newer contributor like Bruno should be accepted under ANY terms in the way it was in SVN rev 670340. The example component is supposed to be the example of best practices and things changing in this seems odd. -David On Jun 22, 2008, at 8:24 AM, Jacques Le Roux wrote: > OK, but what about my argument on stress on DB ? This can be hard > sometimes... > And BTW this not how it works in most of the screen for now > > Jacques > > From: "Bruno Busco" <[hidden email]> >> Adrian, >> many thanks for the update. >> So last commits on Lookups and Example FindScreens follows the >> guidelines, >> good! >> -Bruno >> 2008/6/22 Adrian Crum <[hidden email]>: >>> I have all of the emails on the Find Screen discussion, so I will >>> add it to >>> the best practices section of the wiki. I plan to do some work on >>> the wiki >>> this afternoon. >>> >>> By the way, it was agreed that the find screens would display a >>> complete >>> list at first, then the list is narrowed down by the user. >>> >>> The lookup screens are different - they don't display a list until >>> the user >>> enters search options. >>> >>> -Adrian >>> >>> >>> --- On Sun, 6/22/08, Jacques Le Roux >>> <[hidden email]> wrote: >>> >>> > From: Jacques Le Roux <[hidden email]> >>> > Subject: Re: Discussion summaries >>> > To: [hidden email] >>> > Date: Sunday, June 22, 2008, 5:18 AM >>> > Yes this would be smart :o) >>> > >>> > Jacques >>> > >>> > From: "Bruno Busco" <[hidden email]> >>> > > Dear All, >>> > > In the last days we have had some interesting >>> > duscussions about several >>> > > subjects. >>> > > Don't you think we need to summarize them up and >>> > write something on the >>> > > stone? >>> > > For example, about the Find screens what is the final >>> > one? >>> > > >>> > > Many thanks, >>> > > -Bruno >>> > > >>> >>> >>> >>> >> |
|
|
Well, someone had suggested it during the best practices discussion and no one objected to it.
-Adrian --- On Sun, 6/22/08, David E Jones <[hidden email]> wrote: > From: David E Jones <[hidden email]> > Subject: Re: Discussion summaries > To: [hidden email] > Date: Sunday, June 22, 2008, 4:04 PM > I agree with Jacques... it's a bad idea. I'm > referring to this > statement from Adrian's email: "By the way, it was > agreed that the > find screens would display a complete list at first, then > the list is > narrowed down by the user." > > When was that agreed to? > > For my part it's a big -1, and in fact I was just about > to go remove > that from Bruno's patch of the example component, and > possibly other > things too.... > > Really, it seems odd (no offense to you personally Bruno) > that a patch > from a newer contributor like Bruno should be accepted > under ANY terms > in the way it was in SVN rev 670340. The example component > is supposed > to be the example of best practices and things changing in > this seems > odd. > > -David > > > On Jun 22, 2008, at 8:24 AM, Jacques Le Roux wrote: > > > OK, but what about my argument on stress on DB ? This > can be hard > > sometimes... > > And BTW this not how it works in most of the screen > for now > > > > Jacques > > > > From: "Bruno Busco" > <[hidden email]> > >> Adrian, > >> many thanks for the update. > >> So last commits on Lookups and Example FindScreens > follows the > >> guidelines, > >> good! > >> -Bruno > >> 2008/6/22 Adrian Crum > <[hidden email]>: > >>> I have all of the emails on the Find Screen > discussion, so I will > >>> add it to > >>> the best practices section of the wiki. I plan > to do some work on > >>> the wiki > >>> this afternoon. > >>> > >>> By the way, it was agreed that the find > screens would display a > >>> complete > >>> list at first, then the list is narrowed down > by the user. > >>> > >>> The lookup screens are different - they > don't display a list until > >>> the user > >>> enters search options. > >>> > >>> -Adrian > >>> > >>> > >>> --- On Sun, 6/22/08, Jacques Le Roux > >>> <[hidden email]> wrote: > >>> > >>> > From: Jacques Le Roux > <[hidden email]> > >>> > Subject: Re: Discussion summaries > >>> > To: [hidden email] > >>> > Date: Sunday, June 22, 2008, 5:18 AM > >>> > Yes this would be smart :o) > >>> > > >>> > Jacques > >>> > > >>> > From: "Bruno Busco" > <[hidden email]> > >>> > > Dear All, > >>> > > In the last days we have had some > interesting > >>> > duscussions about several > >>> > > subjects. > >>> > > Don't you think we need to > summarize them up and > >>> > write something on the > >>> > > stone? > >>> > > For example, about the Find screens > what is the final > >>> > one? > >>> > > > >>> > > Many thanks, > >>> > > -Bruno > >>> > > > >>> > >>> > >>> > >>> > >> |
|
|
David,
no problem at all with a deeper review of my patches, it is understandable. BTW the matter was discussed here http://markmail.org/message/cs3lvoc3puzofbhu#query:ofbiz%20Here%20are%20the%20layout%20best%20practices%20discussed%20so%20far%3A+page:1+mid:zhtzes3f4tiqlai2+state:results and it did seem to me that the majority of us agreed on that. Since we had the FindDecoratorScreen that was written just in order to have all the find screens look similar, I thought that the best contribution was to have the template find screens (the one in the example application) changed first and that gradually all the others. If you guys think that having initially the list empty is better we could make it configurable like proposed by Adrian. But I suggest to have a GLOBAL property to control this so that we have all the UI on an installation consistent. Now I have seen that Adrian has started writing a new confluence page that will summarize all the agreed Layout guidelines in order to have them simply accessible, thank you Adrian. I think we really need this. While browsing the thread about the Layout best practices I came across some other points that were discussed. I would like to remind them to all so the final decision could be taken and added in the Layout guidelines Confluence page. They were: 1) - A Skip menu to access several part of the screen directly 2) - An help button/icon link. Should we have it always located the same place? Many thanks, -Bruno 2008/6/23 Adrian Crum <[hidden email]>: > Well, someone had suggested it during the best practices discussion and no > one objected to it. > > -Adrian > > > --- On Sun, 6/22/08, David E Jones <[hidden email]> wrote: > > > From: David E Jones <[hidden email]> > > Subject: Re: Discussion summaries > > To: [hidden email] > > Date: Sunday, June 22, 2008, 4:04 PM > > I agree with Jacques... it's a bad idea. I'm > > referring to this > > statement from Adrian's email: "By the way, it was > > agreed that the > > find screens would display a complete list at first, then > > the list is > > narrowed down by the user." > > > > When was that agreed to? > > > > For my part it's a big -1, and in fact I was just about > > to go remove > > that from Bruno's patch of the example component, and > > possibly other > > things too.... > > > > Really, it seems odd (no offense to you personally Bruno) > > that a patch > > from a newer contributor like Bruno should be accepted > > under ANY terms > > in the way it was in SVN rev 670340. The example component > > is supposed > > to be the example of best practices and things changing in > > this seems > > odd. > > > > -David > > > > > > On Jun 22, 2008, at 8:24 AM, Jacques Le Roux wrote: > > > > > OK, but what about my argument on stress on DB ? This > > can be hard > > > sometimes... > > > And BTW this not how it works in most of the screen > > for now > > > > > > Jacques > > > > > > From: "Bruno Busco" > > <[hidden email]> > > >> Adrian, > > >> many thanks for the update. > > >> So last commits on Lookups and Example FindScreens > > follows the > > >> guidelines, > > >> good! > > >> -Bruno > > >> 2008/6/22 Adrian Crum > > <[hidden email]>: > > >>> I have all of the emails on the Find Screen > > discussion, so I will > > >>> add it to > > >>> the best practices section of the wiki. I plan > > to do some work on > > >>> the wiki > > >>> this afternoon. > > >>> > > >>> By the way, it was agreed that the find > > screens would display a > > >>> complete > > >>> list at first, then the list is narrowed down > > by the user. > > >>> > > >>> The lookup screens are different - they > > don't display a list until > > >>> the user > > >>> enters search options. > > >>> > > >>> -Adrian > > >>> > > >>> > > >>> --- On Sun, 6/22/08, Jacques Le Roux > > >>> <[hidden email]> wrote: > > >>> > > >>> > From: Jacques Le Roux > > <[hidden email]> > > >>> > Subject: Re: Discussion summaries > > >>> > To: [hidden email] > > >>> > Date: Sunday, June 22, 2008, 5:18 AM > > >>> > Yes this would be smart :o) > > >>> > > > >>> > Jacques > > >>> > > > >>> > From: "Bruno Busco" > > <[hidden email]> > > >>> > > Dear All, > > >>> > > In the last days we have had some > > interesting > > >>> > duscussions about several > > >>> > > subjects. > > >>> > > Don't you think we need to > > summarize them up and > > >>> > write something on the > > >>> > > stone? > > >>> > > For example, about the Find screens > > what is the final > > >>> > one? > > >>> > > > > >>> > > Many thanks, > > >>> > > -Bruno > > >>> > > > > >>> > > >>> > > >>> > > >>> > > >> > > > > |
|
Administrator
|
From: "Bruno Busco" <[hidden email]>
[...snip...] > If you guys think that having initially the list empty is better we could > make it configurable like proposed by Adrian. But I suggest to have a GLOBAL > property to control this so that we have all the UI on an installation > consistent. +1 > Now I have seen that Adrian has started writing a new confluence page that > will summarize all the agreed Layout guidelines in order to have them simply > accessible, thank you Adrian. I think we really need this. Yes, really helpful, to be completed... > While browsing the thread about the Layout best practices I came across some > other points that were discussed. I would like to remind them to all so the > final decision could be taken and added in the Layout guidelines Confluence > page. > > They were: > 1) - A Skip menu to access several part of the screen directly I did it. Could be enhanced : it only skips to main area for now. In my mind it was an option for sight disabled people so it's invisible for "normal" people. > 2) - An help button/icon link. Should we have it always located the same > place? Yes, I can't see any argument to have it in different places regarding the screen. UI consistency is a must-have, I know you are concerned Bruno and it's great there are still much work in OFBiz about that point... Thanks Jacques > Many thanks, > -Bruno > > 2008/6/23 Adrian Crum <[hidden email]>: > >> Well, someone had suggested it during the best practices discussion and no >> one objected to it. >> >> -Adrian >> >> >> --- On Sun, 6/22/08, David E Jones <[hidden email]> wrote: >> >> > From: David E Jones <[hidden email]> >> > Subject: Re: Discussion summaries >> > To: [hidden email] >> > Date: Sunday, June 22, 2008, 4:04 PM >> > I agree with Jacques... it's a bad idea. I'm >> > referring to this >> > statement from Adrian's email: "By the way, it was >> > agreed that the >> > find screens would display a complete list at first, then >> > the list is >> > narrowed down by the user." >> > >> > When was that agreed to? >> > >> > For my part it's a big -1, and in fact I was just about >> > to go remove >> > that from Bruno's patch of the example component, and >> > possibly other >> > things too.... >> > >> > Really, it seems odd (no offense to you personally Bruno) >> > that a patch >> > from a newer contributor like Bruno should be accepted >> > under ANY terms >> > in the way it was in SVN rev 670340. The example component >> > is supposed >> > to be the example of best practices and things changing in >> > this seems >> > odd. >> > >> > -David >> > >> > >> > On Jun 22, 2008, at 8:24 AM, Jacques Le Roux wrote: >> > >> > > OK, but what about my argument on stress on DB ? This >> > can be hard >> > > sometimes... >> > > And BTW this not how it works in most of the screen >> > for now >> > > >> > > Jacques >> > > >> > > From: "Bruno Busco" >> > <[hidden email]> >> > >> Adrian, >> > >> many thanks for the update. >> > >> So last commits on Lookups and Example FindScreens >> > follows the >> > >> guidelines, >> > >> good! >> > >> -Bruno >> > >> 2008/6/22 Adrian Crum >> > <[hidden email]>: >> > >>> I have all of the emails on the Find Screen >> > discussion, so I will >> > >>> add it to >> > >>> the best practices section of the wiki. I plan >> > to do some work on >> > >>> the wiki >> > >>> this afternoon. >> > >>> >> > >>> By the way, it was agreed that the find >> > screens would display a >> > >>> complete >> > >>> list at first, then the list is narrowed down >> > by the user. >> > >>> >> > >>> The lookup screens are different - they >> > don't display a list until >> > >>> the user >> > >>> enters search options. >> > >>> >> > >>> -Adrian >> > >>> >> > >>> >> > >>> --- On Sun, 6/22/08, Jacques Le Roux >> > >>> <[hidden email]> wrote: >> > >>> >> > >>> > From: Jacques Le Roux >> > <[hidden email]> >> > >>> > Subject: Re: Discussion summaries >> > >>> > To: [hidden email] >> > >>> > Date: Sunday, June 22, 2008, 5:18 AM >> > >>> > Yes this would be smart :o) >> > >>> > >> > >>> > Jacques >> > >>> > >> > >>> > From: "Bruno Busco" >> > <[hidden email]> >> > >>> > > Dear All, >> > >>> > > In the last days we have had some >> > interesting >> > >>> > duscussions about several >> > >>> > > subjects. >> > >>> > > Don't you think we need to >> > summarize them up and >> > >>> > write something on the >> > >>> > > stone? >> > >>> > > For example, about the Find screens >> > what is the final >> > >>> > one? >> > >>> > > >> > >>> > > Many thanks, >> > >>> > > -Bruno >> > >>> > > >> > >>> >> > >>> >> > >>> >> > >>> >> > >> >> >> >> >> > |
|
|
In reply to this post by Bruno Busco
Just curious on what you're discussing about. Do you mean something like
this? http://www.dbsight.com/search.do?indexName=freedb&q=mobile If so, by Lucene would be a nice implement. Shi Yusen/Beijing Langhua Ltd. 在 2008-06-23一的 08:28 +0200，Bruno Busco写道： > David, > no problem at all with a deeper review of my patches, it is understandable. > > BTW the matter was discussed here > http://markmail.org/message/cs3lvoc3puzofbhu#query:ofbiz%20Here%20are%20the%20layout%20best%20practices%20discussed%20so%20far%3A+page:1+mid:zhtzes3f4tiqlai2+state:results > and it did seem to me that the majority of us agreed on that. > > Since we had the FindDecoratorScreen that was written just in order to have > all the find screens look similar, I thought that the best contribution was > to have the template find screens (the one in the example application) > changed first and that gradually all the others. > If you guys think that having initially the list empty is better we could > make it configurable like proposed by Adrian. But I suggest to have a GLOBAL > property to control this so that we have all the UI on an installation > consistent. > > Now I have seen that Adrian has started writing a new confluence page that > will summarize all the agreed Layout guidelines in order to have them simply > accessible, thank you Adrian. I think we really need this. > > While browsing the thread about the Layout best practices I came across some > other points that were discussed. I would like to remind them to all so the > final decision could be taken and added in the Layout guidelines Confluence > page. > > They were: > 1) - A Skip menu to access several part of the screen directly > 2) - An help button/icon link. Should we have it always located the same > place? > > Many thanks, > -Bruno > > 2008/6/23 Adrian Crum <[hidden email]>: > > > Well, someone had suggested it during the best practices discussion and no > > one objected to it. > > > > -Adrian > > > > > > --- On Sun, 6/22/08, David E Jones <[hidden email]> wrote: > > > > > From: David E Jones <[hidden email]> > > > Subject: Re: Discussion summaries > > > To: [hidden email] > > > Date: Sunday, June 22, 2008, 4:04 PM > > > I agree with Jacques... it's a bad idea. I'm > > > referring to this > > > statement from Adrian's email: "By the way, it was > > > agreed that the > > > find screens would display a complete list at first, then > > > the list is > > > narrowed down by the user." > > > > > > When was that agreed to? > > > > > > For my part it's a big -1, and in fact I was just about > > > to go remove > > > that from Bruno's patch of the example component, and > > > possibly other > > > things too.... > > > > > > Really, it seems odd (no offense to you personally Bruno) > > > that a patch > > > from a newer contributor like Bruno should be accepted > > > under ANY terms > > > in the way it was in SVN rev 670340. The example component > > > is supposed > > > to be the example of best practices and things changing in > > > this seems > > > odd. > > > > > > -David > > > > > > > > > On Jun 22, 2008, at 8:24 AM, Jacques Le Roux wrote: > > > > > > > OK, but what about my argument on stress on DB ? This > > > can be hard > > > > sometimes... > > > > And BTW this not how it works in most of the screen > > > for now > > > > > > > > Jacques > > > > > > > > From: "Bruno Busco" > > > <[hidden email]> > > > >> Adrian, > > > >> many thanks for the update. > > > >> So last commits on Lookups and Example FindScreens > > > follows the > > > >> guidelines, > > > >> good! > > > >> -Bruno > > > >> 2008/6/22 Adrian Crum > > > <[hidden email]>: > > > >>> I have all of the emails on the Find Screen > > > discussion, so I will > > > >>> add it to > > > >>> the best practices section of the wiki. I plan > > > to do some work on > > > >>> the wiki > > > >>> this afternoon. > > > >>> > > > >>> By the way, it was agreed that the find > > > screens would display a > > > >>> complete > > > >>> list at first, then the list is narrowed down > > > by the user. > > > >>> > > > >>> The lookup screens are different - they > > > don't display a list until > > > >>> the user > > > >>> enters search options. > > > >>> > > > >>> -Adrian > > > >>> > > > >>> > > > >>> --- On Sun, 6/22/08, Jacques Le Roux > > > >>> <[hidden email]> wrote: > > > >>> > > > >>> > From: Jacques Le Roux > > > <[hidden email]> > > > >>> > Subject: Re: Discussion summaries > > > >>> > To: [hidden email] > > > >>> > Date: Sunday, June 22, 2008, 5:18 AM > > > >>> > Yes this would be smart :o) > > > >>> > > > > >>> > Jacques > > > >>> > > > > >>> > From: "Bruno Busco" > > > <[hidden email]> > > > >>> > > Dear All, > > > >>> > > In the last days we have had some > > > interesting > > > >>> > duscussions about several > > > >>> > > subjects. > > > >>> > > Don't you think we need to > > > summarize them up and > > > >>> > write something on the > > > >>> > > stone? > > > >>> > > For example, about the Find screens > > > what is the final > > > >>> > one? > > > >>> > > > > > >>> > > Many thanks, > > > >>> > > -Bruno > > > >>> > > > > > >>> > > > >>> > > > >>> > > > >>> > > > >> > > > > > > > > |
|
Administrator
|
Shi,
It's about the find screens which are often the main pages of applications. They mostly use the findPerfomr service. They are domains specific and use entities, no need to use Lucene Jacques From: "Shi Yusen" <[hidden email]> > Just curious on what you're discussing about. Do you mean something like > this? > http://www.dbsight.com/search.do?indexName=freedb&q=mobile > > If so, by Lucene would be a nice implement. > > Shi Yusen/Beijing Langhua Ltd. > > > 在 2008-06-23一的 08:28 +0200，Bruno Busco写道： >> David, >> no problem at all with a deeper review of my patches, it is understandable. >> >> BTW the matter was discussed here >> http://markmail.org/message/cs3lvoc3puzofbhu#query:ofbiz%20Here%20are%20the%20layout%20best%20practices%20discussed%20so%20far%3A+page:1+mid:zhtzes3f4tiqlai2+state:results >> and it did seem to me that the majority of us agreed on that. >> >> Since we had the FindDecoratorScreen that was written just in order to have >> all the find screens look similar, I thought that the best contribution was >> to have the template find screens (the one in the example application) >> changed first and that gradually all the others. >> If you guys think that having initially the list empty is better we could >> make it configurable like proposed by Adrian. But I suggest to have a GLOBAL >> property to control this so that we have all the UI on an installation >> consistent. >> >> Now I have seen that Adrian has started writing a new confluence page that >> will summarize all the agreed Layout guidelines in order to have them simply >> accessible, thank you Adrian. I think we really need this. >> >> While browsing the thread about the Layout best practices I came across some >> other points that were discussed. I would like to remind them to all so the >> final decision could be taken and added in the Layout guidelines Confluence >> page. >> >> They were: >> 1) - A Skip menu to access several part of the screen directly >> 2) - An help button/icon link. Should we have it always located the same >> place? >> >> Many thanks, >> -Bruno >> >> 2008/6/23 Adrian Crum <[hidden email]>: >> >> > Well, someone had suggested it during the best practices discussion and no >> > one objected to it. >> > >> > -Adrian >> > >> > >> > --- On Sun, 6/22/08, David E Jones <[hidden email]> wrote: >> > >> > > From: David E Jones <[hidden email]> >> > > Subject: Re: Discussion summaries >> > > To: [hidden email] >> > > Date: Sunday, June 22, 2008, 4:04 PM >> > > I agree with Jacques... it's a bad idea. I'm >> > > referring to this >> > > statement from Adrian's email: "By the way, it was >> > > agreed that the >> > > find screens would display a complete list at first, then >> > > the list is >> > > narrowed down by the user." >> > > >> > > When was that agreed to? >> > > >> > > For my part it's a big -1, and in fact I was just about >> > > to go remove >> > > that from Bruno's patch of the example component, and >> > > possibly other >> > > things too.... >> > > >> > > Really, it seems odd (no offense to you personally Bruno) >> > > that a patch >> > > from a newer contributor like Bruno should be accepted >> > > under ANY terms >> > > in the way it was in SVN rev 670340. The example component >> > > is supposed >> > > to be the example of best practices and things changing in >> > > this seems >> > > odd. >> > > >> > > -David >> > > >> > > >> > > On Jun 22, 2008, at 8:24 AM, Jacques Le Roux wrote: >> > > >> > > > OK, but what about my argument on stress on DB ? This >> > > can be hard >> > > > sometimes... >> > > > And BTW this not how it works in most of the screen >> > > for now >> > > > >> > > > Jacques >> > > > >> > > > From: "Bruno Busco" >> > > <[hidden email]> >> > > >> Adrian, >> > > >> many thanks for the update. >> > > >> So last commits on Lookups and Example FindScreens >> > > follows the >> > > >> guidelines, >> > > >> good! >> > > >> -Bruno >> > > >> 2008/6/22 Adrian Crum >> > > <[hidden email]>: >> > > >>> I have all of the emails on the Find Screen >> > > discussion, so I will >> > > >>> add it to >> > > >>> the best practices section of the wiki. I plan >> > > to do some work on >> > > >>> the wiki >> > > >>> this afternoon. >> > > >>> >> > > >>> By the way, it was agreed that the find >> > > screens would display a >> > > >>> complete >> > > >>> list at first, then the list is narrowed down >> > > by the user. >> > > >>> >> > > >>> The lookup screens are different - they >> > > don't display a list until >> > > >>> the user >> > > >>> enters search options. >> > > >>> >> > > >>> -Adrian >> > > >>> >> > > >>> >> > > >>> --- On Sun, 6/22/08, Jacques Le Roux >> > > >>> <[hidden email]> wrote: >> > > >>> >> > > >>> > From: Jacques Le Roux >> > > <[hidden email]> >> > > >>> > Subject: Re: Discussion summaries >> > > >>> > To: [hidden email] >> > > >>> > Date: Sunday, June 22, 2008, 5:18 AM >> > > >>> > Yes this would be smart :o) >> > > >>> > >> > > >>> > Jacques >> > > >>> > >> > > >>> > From: "Bruno Busco" >> > > <[hidden email]> >> > > >>> > > Dear All, >> > > >>> > > In the last days we have had some >> > > interesting >> > > >>> > duscussions about several >> > > >>> > > subjects. >> > > >>> > > Don't you think we need to >> > > summarize them up and >> > > >>> > write something on the >> > > >>> > > stone? >> > > >>> > > For example, about the Find screens >> > > what is the final >> > > >>> > one? >> > > >>> > > >> > > >>> > > Many thanks, >> > > >>> > > -Bruno >> > > >>> > > >> > > >>> >> > > >>> >> > > >>> >> > > >>> >> > > >> >> > >> > >> > >> > > |
|
|
In reply to this post by Bruno Busco
Bruno Busco wrote:
> Now I have seen that Adrian has started writing a new confluence page that > will summarize all the agreed Layout guidelines in order to have them simply > accessible, thank you Adrian. I think we really need this. I had some emergencies come up at home that pulled me away from the wiki work. I'll finish it soon. -Adrian |
|
|
In reply to this post by Bruno Busco
This has been implemented in rev 670676.
Basically, all Find screens need to have this line: <set field="noConditionFind" value="Y"/> replaced with these lines: <property-to-field field="initialResultsProp" resource="widget" property="widget.findscreen.initial.results"/> <set field="noConditionFind" from-field="parameters.noConditionFind" default-value="${initialResultsProp}"></set> -Adrian Bruno Busco wrote: > If you guys think that having initially the list empty is better we could > make it configurable like proposed by Adrian. But I suggest to have a GLOBAL > property to control this so that we have all the UI on an installation > consistent. |
|
|
Is there anywhere in a decorator or something where we could put this? Perhaps even right into the ScreenRenderer class where it prepares the context. Especially if it is coming from a properties file in the widget component we might as well make it official/automatic/etc. -David On Jun 23, 2008, at 11:22 AM, Adrian Crum wrote: > This has been implemented in rev 670676. > > Basically, all Find screens need to have this line: > > <set field="noConditionFind" value="Y"/> > > replaced with these lines: > > <property-to-field field="initialResultsProp" resource="widget" > property="widget.findscreen.initial.results"/> > <set field="noConditionFind" from-field="parameters.noConditionFind" > default-value="${initialResultsProp}"></set> > > -Adrian > > Bruno Busco wrote: >> If you guys think that having initially the list empty is better we >> could >> make it configurable like proposed by Adrian. But I suggest to have >> a GLOBAL >> property to control this so that we have all the UI on an >> installation >> consistent. |
|
|
I thought of that too. Problem is, the decorator is called after the
field value is needed. I'll keep scratching my head... -Adrian David E Jones wrote: > > Is there anywhere in a decorator or something where we could put this? > Perhaps even right into the ScreenRenderer class where it prepares the > context. Especially if it is coming from a properties file in the widget > component we might as well make it official/automatic/etc. > > -David > > > On Jun 23, 2008, at 11:22 AM, Adrian Crum wrote: > >> This has been implemented in rev 670676. >> >> Basically, all Find screens need to have this line: >> >> <set field="noConditionFind" value="Y"/> >> >> replaced with these lines: >> >> <property-to-field field="initialResultsProp" resource="widget" >> property="widget.findscreen.initial.results"/> >> <set field="noConditionFind" from-field="parameters.noConditionFind" >> default-value="${initialResultsProp}"></set> >> >> -Adrian >> >> Bruno Busco wrote: >>> If you guys think that having initially the list empty is better we >>> could >>> make it configurable like proposed by Adrian. But I suggest to have a >>> GLOBAL >>> property to control this so that we have all the UI on an installation >>> consistent. > > |
|
|
Yeah, good point. I guess in that case the ScreenRenderer class is probably the best place to put it. This would be the default value for "noConditionFind", and of course if anything specifies it manually then it will override the setting initially in the context. -David On Jun 23, 2008, at 12:10 PM, Adrian Crum wrote: > I thought of that too. Problem is, the decorator is called after the > field value is needed. > > I'll keep scratching my head... > > -Adrian > > David E Jones wrote: >> Is there anywhere in a decorator or something where we could put >> this? Perhaps even right into the ScreenRenderer class where it >> prepares the context. Especially if it is coming from a properties >> file in the widget component we might as well make it official/ >> automatic/etc. >> -David >> On Jun 23, 2008, at 11:22 AM, Adrian Crum wrote: >>> This has been implemented in rev 670676. >>> >>> Basically, all Find screens need to have this line: >>> >>> <set field="noConditionFind" value="Y"/> >>> >>> replaced with these lines: >>> >>> <property-to-field field="initialResultsProp" resource="widget" >>> property="widget.findscreen.initial.results"/> >>> <set field="noConditionFind" from- >>> field="parameters.noConditionFind" default-value="$ >>> {initialResultsProp}"></set> >>> >>> -Adrian >>> >>> Bruno Busco wrote: >>>> If you guys think that having initially the list empty is better >>>> we could >>>> make it configurable like proposed by Adrian. But I suggest to >>>> have a GLOBAL >>>> property to control this so that we have all the UI on an >>>> installation >>>> consistent. |
|
|
Will do!
David E Jones wrote: > > Yeah, good point. I guess in that case the ScreenRenderer class is > probably the best place to put it. > > This would be the default value for "noConditionFind", and of course if > anything specifies it manually then it will override the setting > initially in the context. > > -David > > > On Jun 23, 2008, at 12:10 PM, Adrian Crum wrote: > >> I thought of that too. Problem is, the decorator is called after the >> field value is needed. >> >> I'll keep scratching my head... >> >> -Adrian >> >> David E Jones wrote: >>> Is there anywhere in a decorator or something where we could put >>> this? Perhaps even right into the ScreenRenderer class where it >>> prepares the context. Especially if it is coming from a properties >>> file in the widget component we might as well make it >>> official/automatic/etc. >>> -David >>> On Jun 23, 2008, at 11:22 AM, Adrian Crum wrote: >>>> This has been implemented in rev 670676. >>>> >>>> Basically, all Find screens need to have this line: >>>> >>>> <set field="noConditionFind" value="Y"/> >>>> >>>> replaced with these lines: >>>> >>>> <property-to-field field="initialResultsProp" resource="widget" >>>> property="widget.findscreen.initial.results"/> >>>> <set field="noConditionFind" from-field="parameters.noConditionFind" >>>> default-value="${initialResultsProp}"></set> >>>> >>>> -Adrian >>>> >>>> Bruno Busco wrote: >>>>> If you guys think that having initially the list empty is better we >>>>> could >>>>> make it configurable like proposed by Adrian. But I suggest to have >>>>> a GLOBAL >>>>> property to control this so that we have all the UI on an installation >>>>> consistent. > > |
|
|
On second thought, it would be better to put it in the FindServices.java
file. -Adrian Adrian Crum wrote: > Will do! > > David E Jones wrote: >> >> Yeah, good point. I guess in that case the ScreenRenderer class is >> probably the best place to put it. >> >> This would be the default value for "noConditionFind", and of course >> if anything specifies it manually then it will override the setting >> initially in the context. >> >> -David >> >> >> On Jun 23, 2008, at 12:10 PM, Adrian Crum wrote: >> >>> I thought of that too. Problem is, the decorator is called after the >>> field value is needed. >>> >>> I'll keep scratching my head... >>> >>> -Adrian >>> >>> David E Jones wrote: >>>> Is there anywhere in a decorator or something where we could put >>>> this? Perhaps even right into the ScreenRenderer class where it >>>> prepares the context. Especially if it is coming from a properties >>>> file in the widget component we might as well make it >>>> official/automatic/etc. >>>> -David >>>> On Jun 23, 2008, at 11:22 AM, Adrian Crum wrote: >>>>> This has been implemented in rev 670676. >>>>> >>>>> Basically, all Find screens need to have this line: >>>>> >>>>> <set field="noConditionFind" value="Y"/> >>>>> >>>>> replaced with these lines: >>>>> >>>>> <property-to-field field="initialResultsProp" resource="widget" >>>>> property="widget.findscreen.initial.results"/> >>>>> <set field="noConditionFind" >>>>> from-field="parameters.noConditionFind" >>>>> default-value="${initialResultsProp}"></set> >>>>> >>>>> -Adrian >>>>> >>>>> Bruno Busco wrote: >>>>>> If you guys think that having initially the list empty is better >>>>>> we could >>>>>> make it configurable like proposed by Adrian. But I suggest to >>>>>> have a GLOBAL >>>>>> property to control this so that we have all the UI on an >>>>>> installation >>>>>> consistent. >> >> > |
|
|
Done. Rev 670705.
No additional screen widget code is needed to implement the Find screen search results default behavior. -Adrian Adrian Crum wrote: > On second thought, it would be better to put it in the FindServices.java > file. > > -Adrian > > Adrian Crum wrote: >> Will do! >> >> David E Jones wrote: >>> >>> Yeah, good point. I guess in that case the ScreenRenderer class is >>> probably the best place to put it. >>> >>> This would be the default value for "noConditionFind", and of course >>> if anything specifies it manually then it will override the setting >>> initially in the context. >>> >>> -David >>> >>> >>> On Jun 23, 2008, at 12:10 PM, Adrian Crum wrote: >>> >>>> I thought of that too. Problem is, the decorator is called after the >>>> field value is needed. >>>> >>>> I'll keep scratching my head... >>>> >>>> -Adrian >>>> >>>> David E Jones wrote: >>>>> Is there anywhere in a decorator or something where we could put >>>>> this? Perhaps even right into the ScreenRenderer class where it >>>>> prepares the context. Especially if it is coming from a properties >>>>> file in the widget component we might as well make it >>>>> official/automatic/etc. >>>>> -David >>>>> On Jun 23, 2008, at 11:22 AM, Adrian Crum wrote: >>>>>> This has been implemented in rev 670676. >>>>>> >>>>>> Basically, all Find screens need to have this line: >>>>>> >>>>>> <set field="noConditionFind" value="Y"/> >>>>>> >>>>>> replaced with these lines: >>>>>> >>>>>> <property-to-field field="initialResultsProp" resource="widget" >>>>>> property="widget.findscreen.initial.results"/> >>>>>> <set field="noConditionFind" >>>>>> from-field="parameters.noConditionFind" >>>>>> default-value="${initialResultsProp}"></set> >>>>>> >>>>>> -Adrian >>>>>> >>>>>> Bruno Busco wrote: >>>>>>> If you guys think that having initially the list empty is better >>>>>>> we could >>>>>>> make it configurable like proposed by Adrian. But I suggest to >>>>>>> have a GLOBAL >>>>>>> property to control this so that we have all the UI on an >>>>>>> installation >>>>>>> consistent. >>> >>> >> > |
|
|
Great! Thanks! ;-)
2008/6/23 Adrian Crum <[hidden email]>: > Done. Rev 670705. > > No additional screen widget code is needed to implement the Find screen > search results default behavior. > > -Adrian > > > Adrian Crum wrote: > >> On second thought, it would be better to put it in the FindServices.java >> file. >> >> -Adrian >> >> Adrian Crum wrote: >> >>> Will do! >>> >>> David E Jones wrote: >>> >>>> >>>> Yeah, good point. I guess in that case the ScreenRenderer class is >>>> probably the best place to put it. >>>> >>>> This would be the default value for "noConditionFind", and of course if >>>> anything specifies it manually then it will override the setting initially >>>> in the context. >>>> >>>> -David >>>> >>>> >>>> On Jun 23, 2008, at 12:10 PM, Adrian Crum wrote: >>>> >>>> I thought of that too. Problem is, the decorator is called after the >>>>> field value is needed. >>>>> >>>>> I'll keep scratching my head... >>>>> >>>>> -Adrian >>>>> >>>>> David E Jones wrote: >>>>> >>>>>> Is there anywhere in a decorator or something where we could put this? >>>>>> Perhaps even right into the ScreenRenderer class where it prepares the >>>>>> context. Especially if it is coming from a properties file in the widget >>>>>> component we might as well make it official/automatic/etc. >>>>>> -David >>>>>> On Jun 23, 2008, at 11:22 AM, Adrian Crum wrote: >>>>>> >>>>>>> This has been implemented in rev 670676. >>>>>>> >>>>>>> Basically, all Find screens need to have this line: >>>>>>> >>>>>>> <set field="noConditionFind" value="Y"/> >>>>>>> >>>>>>> replaced with these lines: >>>>>>> >>>>>>> <property-to-field field="initialResultsProp" resource="widget" >>>>>>> property="widget.findscreen.initial.results"/> >>>>>>> <set field="noConditionFind" from-field="parameters.noConditionFind" >>>>>>> default-value="${initialResultsProp}"></set> >>>>>>> >>>>>>> -Adrian >>>>>>> >>>>>>> Bruno Busco wrote: >>>>>>> >>>>>>>> If you guys think that having initially the list empty is better we >>>>>>>> could >>>>>>>> make it configurable like proposed by Adrian. But I suggest to have >>>>>>>> a GLOBAL >>>>>>>> property to control this so that we have all the UI on an >>>>>>>> installation >>>>>>>> consistent. >>>>>>>> >>>>>>> >>>> >>>> >>> >> |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |