Sure, I will follow and review this the best I can. Just send the pointer to patches or wherever I can see the code.
-Bruno 2009/12/1 Scott Gray <[email protected]>: > Inline, thanks again for your comments Bruno. > > On 1/12/2009, at 10:21 PM, Bruno Busco wrote: > >> Hi Scott, >> inline >> >> 2009/12/1 Scott Gray <[email protected]>: >>> >>> Hi Bruno, >>> >>> Thanks for sharing your thoughts, comments inline. >>> >>> On 1/12/2009, at 7:30 PM, Bruno Busco wrote: >>> >>>> Hi Scott, >>>> this is on my list also. >>>> >>>> This is how I did imagine it: >>>> >>>> **UI: >>>> In the search options screenlet of the FindScreenDecorator: >>> >>> This is interesting, how do you plan on presenting the drop-down to the >>> user? I placed it in the form widget itself for a couple of reasons: >>> * So that it can be positioned within the form according to the >>> developers >>> preference and styled on a per form basis >>> * Because of the dual behavior I had envisaged for the form, i.e. it is a >>> drop down initially but if a new search is performed then it switches to >>> a >>> text box to allow a name to be entered and saved. >>> * The list of saved searches to populate the drop-down list is dependent >>> on >>> the form target >>> * The new form element could also be used in the future to save a draft >>> of a >>> partially completed form >> >> Agreed. Having it in the form widget sounds good to me. >> >>> >>>> - a drop-down apperars if one or more saved search are available for >>>> that search. If the user selects one of the options all the search >>>> fields get populated automatically. >>> >>> And the search results are presented at the same time right? >> >> Shouldn't the user be able to change some of the values in the fields >> before running the search? >> In this case it would be better to only fill the fields and then press >> "search". > > I guess that could be possible but it would be more difficult to implement > we'd either need to send all of the parameters out for each saved search > when we render the form or do an ajax call to get the parameters plus we'd > need javascript to populate the form fields. I had planned on just > triggering a submit when the selection in the drop-down changes (this is > what SugarCRM do, not that I consider that a justification). I had been > considering that in the majority of cases the saved search will meet the > users needs without modification. Either way this will be possible > regardless of the implementation but if I am doing the implementation I > would prefer to leave it out and then we can add it later and perhaps even > make it configurable in the form widget xsd. > >>>> Not yet defined how to let the user delete a saved search. >>> >>> Yeah I haven't done that either, I was thinking perhaps a delete link >>> could >>> be presented once the user performs the search to be deleted. So the >>> user >>> would select a search from the drop-down, the search is performed, a >>> delete >>> link is now present next to the drop down. >> >> May be we could think to a "My saved searches" screen where the user >> sees all his saved searches and can edit their names, delete (or even >> share them at a later stage). > > That sounds like a good idea to me. > >>>> - "Save this search" button is shown to let the user save the actual >>>> content of the search fileds. >>> >>> Agreed >>> >>>> - A name field allows to set a name for the search the user is going >>>> to save. This is what will be displayed on the drop-down to select the >>>> search. >>> >>> Agreed, the plan for me was to switch the drop-down out for a text box if >>> a >>> new search is performed. >> >> Agreed. This is great! >> >>> >>>> - There should be the possibility to share saved search in same way >>>> letting them being visible by all users. >>> >>> I think this is nice to have but a little complicated because who are we >>> sharing it with? I doubt we'd want to share them organization wide >>> because >>> the list would quickly become too long for a drop-down to be useful. >>> Because of the complications I had planned on leaving this until someone >>> actually needed the functionality or someone else felt like working on >>> it. >> >> Agreed. Lets start simple for now. >> >>> >>>> - All this is only available if the user is logged in. No search save >>>> is possible for not logger users. >>> >>> Agreed >>> >>>> **Code: >>>> Adrian suggested to use userPreferences for this and I think it is a >>>> good >>>> idea. >>>> Every search screen should have a unique key that will be used to >>>> store a preference. >>> >>> I did read this suggestion but I didn't feel that a single key-value pair >>> was a good fit for the amount of information that needs to be stored. >>> What >>> would the name and value consist of? >> >> Agreed. This seems to complex to fit in there... > > Great, if you have time please do review the entities, I'd like to get as > many eyes on them as possible since they tend to be difficult to re-factor > down the road. > >>>> I am using the userPreferences to store the screenlet collapsed status >>>> also, I did not commit yet but I will do soon. In this case the >>>> screenlet-id is used as key. >>> >>> This makes sense for a UserPreference record because it is naturally a >>> unique key and a single value. >>> >>>> Additionally, I would like to use a saved search to automatically run >>>> a report periodically. To do this I need to pass the saved search as a >>>> parameter to a service. >>> >>> +1 I see a few potential uses for persisted forms/requests, saving >>> drafts, >>> creating reports, possibly even the most recently viewed items feature >>> that >>> we've talked about before. I tried to create the data model with these >>> things in mind. >>> >>>> Thank you very much for sharing all this! >>>> -Bruno >>>> >>>> 2009/12/1 Scott Gray <[email protected]>: >>>>> >>>>> We've discussed in passing a couple of times now the possibility of >>>>> allowing >>>>> users to save their searches/finds in order to allow them to quickly >>>>> perform >>>>> the search again in the future. I'd like to get this implemented in >>>>> the >>>>> very near future and since there have been a few different ideas thrown >>>>> around about how that might be achieved, I've gone ahead and put >>>>> together >>>>> some implementation notes for feedback from the community. >>>>> >>>>> No code has been written and opinions of any nature would be greatly >>>>> appreciated, since it's not a major feature I'd rather only wait a day >>>>> or >>>>> two before getting stuck in (unless of any conversations take longer >>>>> than >>>>> that). >>>>> >>>>> Thanks >>>>> Scott >>>>> >>>>> HotWax Media >>>>> http://www.hotwaxmedia.com >>>>> >>> >>> > >
