Wow! Much better then inlining comments. I like it! -Bruno
2009/12/1 Scott Gray <[email protected]>: > Sure thing, I'll share the code as soon as I have some written. > > Also I only just realized that I completely missed linking to my actual > implementation proposal: > http://cwiki.apache.org/confluence/display/OFBIZ/Saved+Searches > Sending that link out was the entire purpose of my original email :-/ and > this whole time I assumed you had read it and we were discussing it, wow. > > Regards > Scott > > On 1/12/2009, at 11:31 PM, Bruno Busco wrote: > >> 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 >>>>>>> >>>>> >>>>> >>> >>> > >
