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