-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NEW: Allow search field customisation #9341
NEW: Allow search field customisation #9341
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to make it easier and clearer for developers to know how to use and customise the new search interface. This is a good step in that direction.
I'm thinking we should provide a way for them to do it directly on their DataObjects, but this PR is a good intermediary step.
I'm not totally sold on adding it to the |
That's probably a wider discussion for an RFC. This PR by itself doesn't preclude our duplicate these efforts. I'm fine with merging this PR once unit tests have been added and maybe some doc. |
b4cdd16
to
d6fde8f
Compare
Good feedback, @maxime-rainville .. have added the |
Likely doesn't impact this PR going through as-is, but #9356 talks about setting multiple fields to be searchable in the main field. Thinking we could change these new APIs in the future to optionally accept an array to achieve that issue's goals? |
@Cheddam thanks for tracking this. Multiple field is indeed necessary in my opinion, as it is very unconvenient for the user to go through the dropdown in order to search on other fields. I think the common expectation of all my customers is that "typing something in the search bar matches on all relevant fields", not only on a single field. |
@lekoala I appreciate that this feature would be really useful to users, but it'll need to be tackled in a separate PR - I just wanted to make @unclecheese aware of it, and check that this API is going to suit expansion to support it in the future. |
a1eaed5
to
8f0ec8c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy with the PR and I've re-tested that it works. I'm thinking some of the doc could use simpler language, but otherwise I'm happy.
@unclecheese when you get a chance would you be able to implement Maxime's recommended docs changes? We should be able to get this merged once those are in |
For reference |
8f0ec8c
to
18cf766
Compare
I have rebased this on |
The approval came before #10382 was created and may not apply with it as context
Note: The documentation portion should not be merged here. I have started the process of migrating docs to a new repository so the docs will need to be removed from this PR and a new PR raised in the new repo instead. |
18cf766
to
c884549
Compare
Docs changes have been moved to silverstripe/developer-docs#6 |
* The name of the default search field | ||
* @var string|null | ||
*/ | ||
protected $searchField = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
protected $searchField = null; | |
protected ?string $searchField = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
/** | ||
* @return string|null | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/** | |
* @return string|null | |
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
/** | ||
* @param string $field | ||
* @return $this | ||
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/** | |
* @param string $field | |
* @return $this | |
*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done
public function setSearchField(string $field): self | ||
{ | ||
$this->searchField = $field; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Subjective but okay. Done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you move the contents of this PR into #10382 and close this one, that way there's only a single framework PR which makes testing a lot easier < keep them separate
If you agree the changes in this PR are worthwhile keeping then yes, I'll merge the two PRs. Though the combined PR should not be squashed in that case. These are two related but separate changes. |
d2dbe74
to
24ea191
Compare
Oh right, sorry got confused with all the PRs. Hold off for now, see how the other PR looks on it's own and then in a better position to judge if this is worthwhile. Doesn't seem like we should combine the two in either case |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking close this one and add an allowlist style config into #10382 would be better
24ea191
to
07a6c11
Compare
We came to the decision not to use an allow-list configuration in the end: #10382 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested locally, works good
By default,
GridFieldFilterHeader
chooses the first field in the searchable fields array for the search bar. This allows you to customise what that field is.Notes
SearchContext
andGridField
s further and separately.Parent issue