You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Scott Gray <sc...@hotwaxmedia.com> on 2009/12/01 04:08:00 UTC
Implementing Saved Searches
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
Re: Implementing Saved Searches
Posted by Jacques Le Roux <ja...@les7arts.com>.
From: "Bruno Busco" <br...@gmail.com>
> Wow!
> Much better then inlining comments.
> I like it!
Interesting remark... At some point, well written requirements, specifications help a lot...
Jacques
> -Bruno
>
> 2009/12/1 Scott Gray <sc...@hotwaxmedia.com>:
>> 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 <sc...@hotwaxmedia.com>:
>>>>
>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>
>>>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
Confluences watches WAS: Implementing Saved Searches
Posted by Scott Gray <sc...@hotwaxmedia.com>.
Hi Jacques
Please feel free to change the subject line when you go off topic, I'd
rather not dilute this thread with discussions about confluence.
Thanks
Scott
On 2/12/2009, at 10:49 AM, Jacques Le Roux wrote:
> Note: when you watch OFBiz spaces, ie
>
> OFBiz (Open For Business) Project Open Wiki
> http://cwiki.apache.org/confluence/spaces/browsespace.action?key=OFBIZ
>
> OFBiz End-User Documentation
> http://cwiki.apache.org/confluence/spaces/browsespace.action?key=OFBENDUSER
>
> OFBiz Project Administration Workspace
> http://cwiki.apache.org/confluence/spaces/browsespace.action?key=OFBADMIN
>
> OFBiz Requirements and Designs
> http://cwiki.apache.org/confluence/spaces/browsespace.action?key=OFBREQDES
>
> OFBiz Technical Documentation
> http://cwiki.apache.org/confluence/spaces/browsespace.action?key=OFBTECH
>
> You are alerted about any changes just after they have been done
> (with links)
>
> Jacques
>
> From: "Jacques Le Roux" <ja...@les7arts.com>
>> I did not thought about it because I have subscribed to change in
>> cwiki and I saw Scott's proposition.
>> Actually for now I have both subscribed to email (every changes in
>> each all spaces everyday) and OFBiz spaces changes.
>> Maybe we could require that all commiters subscribe to OFBiz spaces
>> changes in order to be able to follow what is happenning there.
>> If nobody see a problem with that I will add it to http://cwiki.apache.org/confluence/x/IoB2
>>
>> Thanks for sharing opininons
>>
>> Jacques
>>
>> From: "Bruno Busco" <br...@gmail.com>
>>> Wow!
>>> Much better then inlining comments.
>>> I like it!
>>>
>>> -Bruno
>>>
>>> 2009/12/1 Scott Gray <sc...@hotwaxmedia.com>:
>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>
>>>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>>>
>>>>>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>
>
Re: Implementing Saved Searches
Posted by Jacques Le Roux <ja...@les7arts.com>.
Note: when you watch OFBiz spaces, ie
OFBiz (Open For Business) Project Open Wiki
http://cwiki.apache.org/confluence/spaces/browsespace.action?key=OFBIZ
OFBiz End-User Documentation
http://cwiki.apache.org/confluence/spaces/browsespace.action?key=OFBENDUSER
OFBiz Project Administration Workspace
http://cwiki.apache.org/confluence/spaces/browsespace.action?key=OFBADMIN
OFBiz Requirements and Designs
http://cwiki.apache.org/confluence/spaces/browsespace.action?key=OFBREQDES
OFBiz Technical Documentation
http://cwiki.apache.org/confluence/spaces/browsespace.action?key=OFBTECH
You are alerted about any changes just after they have been done (with links)
Jacques
From: "Jacques Le Roux" <ja...@les7arts.com>
>I did not thought about it because I have subscribed to change in cwiki and I saw Scott's proposition.
> Actually for now I have both subscribed to email (every changes in each all spaces everyday) and OFBiz spaces changes.
> Maybe we could require that all commiters subscribe to OFBiz spaces changes in order to be able to follow what is happenning
> there.
> If nobody see a problem with that I will add it to http://cwiki.apache.org/confluence/x/IoB2
>
> Thanks for sharing opininons
>
> Jacques
>
> From: "Bruno Busco" <br...@gmail.com>
>> Wow!
>> Much better then inlining comments.
>> I like it!
>>
>> -Bruno
>>
>> 2009/12/1 Scott Gray <sc...@hotwaxmedia.com>:
>>> 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 <sc...@hotwaxmedia.com>:
>>>>>
>>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>>
>>>>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>
Re: Implementing Saved Searches
Posted by Jacques Le Roux <ja...@les7arts.com>.
I did not thought about it because I have subscribed to change in cwiki and I saw Scott's proposition.
Actually for now I have both subscribed to email (every changes in each all spaces everyday) and OFBiz spaces changes.
Maybe we could require that all commiters subscribe to OFBiz spaces changes in order to be able to follow what is happenning there.
If nobody see a problem with that I will add it to http://cwiki.apache.org/confluence/x/IoB2
Thanks for sharing opininons
Jacques
From: "Bruno Busco" <br...@gmail.com>
> Wow!
> Much better then inlining comments.
> I like it!
>
> -Bruno
>
> 2009/12/1 Scott Gray <sc...@hotwaxmedia.com>:
>> 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 <sc...@hotwaxmedia.com>:
>>>>
>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>
>>>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
Re: Implementing Saved Searches
Posted by Bruno Busco <br...@gmail.com>.
Wow!
Much better then inlining comments.
I like it!
-Bruno
2009/12/1 Scott Gray <sc...@hotwaxmedia.com>:
> 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 <sc...@hotwaxmedia.com>:
>>>
>>> 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 <sc...@hotwaxmedia.com>:
>>>>>
>>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
>
Re: Implementing Saved Searches
Posted by Scott Gray <sc...@hotwaxmedia.com>.
Thanks Adrian, I'll update the document accordingly and then wait
another day for any additional feedback.
After that I'll start the implementation with 3 jira issues:
* entities
* form widget
* actual implementation
Which should help facilitate any further discussion particularly
around the entities and form widget.
Regards
Scott
On 2/12/2009, at 9:45 AM, Adrian Crum wrote:
> Sounds great!
>
> -Adrian
>
> Scott Gray wrote:
>> Hi Adrian,
>> Thanks for taking a look.
>> You make a good point, it would be possible in the current proposal
>> to modify the search and save it as a new one but not to update the
>> existing one:
>> 1. Select a saved search from the drop-down
>> 2. Modify the search parameters and submit
>> 3. The save text-box and submit will be present
>> We could have the find form keep the persistedFormId in a hidden
>> input and present both the drop down and the text input, something
>> like this:
>> Save as new search: <text-input> <save-link>
>> Update existing search: <drop-down> <update-link>
>> We'll also need to add something so that the form widget can tell
>> the difference between a saved search being loaded and a saved
>> search being modified so that the "Save as new search" doesn't show
>> up unnecessarily.
>> So the flow would be:
>> 1. Select a saved search from the drop-down (only the drop-down is
>> presented)
>> 2. Modify the parameters and submit the find form to the regular
>> find target (persistedFormId is also submitted)
>> 3. The two fields described above are presented
>> WDYT?
>> Thanks
>> Scott
>> On 2/12/2009, at 5:11 AM, Adrian Crum wrote:
>>> From the User Interaction section:
>>>
>>> "The save search option should only be presented when the user has
>>> submitted the form as normal and will not be present when the user
>>> has chosen a previous search from the drop-down."
>>>
>>> What about when the user chose a previous search and wants to
>>> update and save some of the parameters?
>>>
>>> -Adrian
>>>
>>>
>>> Scott Gray wrote:
>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>>>
>>>>>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
Re: Implementing Saved Searches
Posted by Adrian Crum <ad...@hlmksw.com>.
Sounds great!
-Adrian
Scott Gray wrote:
> Hi Adrian,
>
> Thanks for taking a look.
> You make a good point, it would be possible in the current proposal to
> modify the search and save it as a new one but not to update the
> existing one:
> 1. Select a saved search from the drop-down
> 2. Modify the search parameters and submit
> 3. The save text-box and submit will be present
>
> We could have the find form keep the persistedFormId in a hidden input
> and present both the drop down and the text input, something like this:
> Save as new search: <text-input> <save-link>
> Update existing search: <drop-down> <update-link>
> We'll also need to add something so that the form widget can tell the
> difference between a saved search being loaded and a saved search being
> modified so that the "Save as new search" doesn't show up unnecessarily.
>
> So the flow would be:
> 1. Select a saved search from the drop-down (only the drop-down is
> presented)
> 2. Modify the parameters and submit the find form to the regular find
> target (persistedFormId is also submitted)
> 3. The two fields described above are presented
>
> WDYT?
>
> Thanks
> Scott
>
> On 2/12/2009, at 5:11 AM, Adrian Crum wrote:
>
>> From the User Interaction section:
>>
>> "The save search option should only be presented when the user has
>> submitted the form as normal and will not be present when the user has
>> chosen a previous search from the drop-down."
>>
>> What about when the user chose a previous search and wants to update
>> and save some of the parameters?
>>
>> -Adrian
>>
>>
>> Scott Gray wrote:
>>> 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 <sc...@hotwaxmedia.com>:
>>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>>
>>>>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>
Re: Implementing Saved Searches
Posted by Scott Gray <sc...@hotwaxmedia.com>.
Hi Adrian,
Thanks for taking a look.
You make a good point, it would be possible in the current proposal to
modify the search and save it as a new one but not to update the
existing one:
1. Select a saved search from the drop-down
2. Modify the search parameters and submit
3. The save text-box and submit will be present
We could have the find form keep the persistedFormId in a hidden input
and present both the drop down and the text input, something like this:
Save as new search: <text-input> <save-link>
Update existing search: <drop-down> <update-link>
We'll also need to add something so that the form widget can tell the
difference between a saved search being loaded and a saved search
being modified so that the "Save as new search" doesn't show up
unnecessarily.
So the flow would be:
1. Select a saved search from the drop-down (only the drop-down is
presented)
2. Modify the parameters and submit the find form to the regular find
target (persistedFormId is also submitted)
3. The two fields described above are presented
WDYT?
Thanks
Scott
On 2/12/2009, at 5:11 AM, Adrian Crum wrote:
> From the User Interaction section:
>
> "The save search option should only be presented when the user has
> submitted the form as normal and will not be present when the user
> has chosen a previous search from the drop-down."
>
> What about when the user chose a previous search and wants to update
> and save some of the parameters?
>
> -Adrian
>
>
> Scott Gray wrote:
>> 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 <sc...@hotwaxmedia.com>:
>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>
>>>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
Re: Implementing Saved Searches
Posted by Adrian Crum <ad...@hlmksw.com>.
From the User Interaction section:
"The save search option should only be presented when the user has
submitted the form as normal and will not be present when the user has
chosen a previous search from the drop-down."
What about when the user chose a previous search and wants to update and
save some of the parameters?
-Adrian
Scott Gray wrote:
> 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 <sc...@hotwaxmedia.com>:
>>> 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 <sc...@hotwaxmedia.com>:
>>>>>
>>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
Re: Implementing Saved Searches
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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 <sc...@hotwaxmedia.com>:
>> 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 <sc...@hotwaxmedia.com>:
>>>>
>>>> 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 <sc...@hotwaxmedia.com>:
>>>>>>
>>>>>> 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
>>>>>>
>>>>
>>>>
>>
>>
Re: Implementing Saved Searches
Posted by Bruno Busco <br...@gmail.com>.
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 <sc...@hotwaxmedia.com>:
> 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 <sc...@hotwaxmedia.com>:
>>>
>>> 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 <sc...@hotwaxmedia.com>:
>>>>>
>>>>> 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
>>>>>
>>>
>>>
>
>
Re: Implementing Saved Searches
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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 <sc...@hotwaxmedia.com>:
>> 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 <sc...@hotwaxmedia.com>:
>>>>
>>>> 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
>>>>
>>
>>
Re: Implementing Saved Searches
Posted by Bruno Busco <br...@gmail.com>.
Hi Scott,
inline
2009/12/1 Scott Gray <sc...@hotwaxmedia.com>:
> 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".
>
>> 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).
>
>> - "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...
>
>> 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 <sc...@hotwaxmedia.com>:
>>>
>>> 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
>>>
>
>
Re: Implementing Saved Searches
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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
> - 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?
> 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.
> - "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.
> - 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.
> - 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?
> 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 <sc...@hotwaxmedia.com>:
>> 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
>>
Re: Implementing Saved Searches
Posted by Bruno Busco <br...@gmail.com>.
Hi Scott,
this is on my list also.
This is how I did imagine it:
**UI:
In the search options screenlet of the FindScreenDecorator:
- 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.
Not yet defined how to let the user delete a saved search.
- "Save this search" button is shown to let the user save the actual
content of the search fileds.
- 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.
- There should be the possibility to share saved search in same way
letting them being visible by all users.
- All this is only available if the user is logged in. No search save
is possible for not logger users.
**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 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.
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.
Thank you very much for sharing all this!
-Bruno
2009/12/1 Scott Gray <sc...@hotwaxmedia.com>:
> 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
>