Skip to content
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

Kustomisiertes Suchfeld #31

Open
iTitus opened this issue Mar 17, 2020 · 6 comments
Open

Kustomisiertes Suchfeld #31

iTitus opened this issue Mar 17, 2020 · 6 comments

Comments

@iTitus
Copy link
Member

iTitus commented Mar 17, 2020

Festlegung einer eigenen Route (nicht auf #, sondern zB auf /search), ändern der Methode (GET, POST, etc.).

@n2o
Copy link
Contributor

n2o commented Mar 17, 2020

Klingt schon sinnvoll. POST sehe ich da nicht, GET reicht und genügt den Standards.

@Phlegethon90
Copy link
Collaborator

meine ersten gedanken dazu:

das problem an so einem vorhaben (kustomisierung von search in einzelnen subsystemen) ist, dass dann die konsistenz im gesamten system bspw. im hinblick auf die wichtigkeit der route leidet, was der ux schadet. ich habe also nichts gegen eine weiterleitung auf /search, sondern habe bedenken bei einer kustomisierung dieser sache pro subsystem (im hinblick auf die einfachheit und konsistenz für den nutzer in all seinen formen).

post wäre in diesem fall (= unsere suche) nur sinnvoll, wenn man die maximale url-länge überschreitet... dann sollte man aber eher seine suchanfrage (und vllt auch der entwickler seine pfadangabe) überdenken.

@n2o
Copy link
Contributor

n2o commented Mar 17, 2020

Das Problem ist aber nun, dass man in jedem Controller dann den Parameter checken muss. Und bei Unterseiten ist das doof.

Beispiel: https://keycloak-cs-demo.herokuapp.com/personal?searchFormIsVisible=true&search=foo

Eingeloggt, auf /personal gegangen, Suche ausgeführt. Nun müsste der personal View gucken, ob search gesetzt ist.

@Phlegethon90
Copy link
Collaborator

Phlegethon90 commented Mar 17, 2020

zum verständnis: die vorhandene suche ist genau dazu da, speziell die seite zu durchsuchen, auf der man gerade ist (ich nenne es mal "lokale suche"). falls man das nicht im jeden controller checken will, dann würde vererbung, aop, interceptor, controlleradvice, etc. weiterhelfen. aber wie gesagt: ich habe nichts gegen eine allgemeine(!) änderung auf /search. ich habe nur bedenken bei "mal so, mal so".

falls es nur darum geht eine "globale suche" bereitzustellen, kann man doch selbst /search bereitstellen, wo dann global gesucht werden kann.

@n2o
Copy link
Contributor

n2o commented Mar 17, 2020

Für eine lokale Suche eignet sich Ctrl + F doch am besten ;-)

Es ist kein mal so mal so. Es ist ein Denkanstoß. Und den können wir ja auch mal im Channel diskutieren.

Stellt man /search bei sich bereit, hat man oben in der Leiste aber immer noch die Suche aktiv. Und nutzt vielleicht das "falsche" Feld, was dann nicht zum gewünschten Ergebnis führt.

Ich weiß auch noch nicht was sinnvoll / gut ist 🤷‍♂ aber vielleicht erarbeiten wir ja zusammen eine Lösung

@Phlegethon90
Copy link
Collaborator

Phlegethon90 commented Mar 17, 2020

mit "lokaler suche" meine ich natürlich eine suche, die im tätigskeitsbereich der unterseite liegt. es ist nicht immer so, dass das, was man gerade auf der unterseite sieht, auch wirklich alles ist, was die unterseite bereitstellen kann (bspw. pagination bei foren). da nützt strg+f nichts.

du hast das "mal so, mal so" falsch verstanden. wie gesagt, bietet die möglichkeit einer kustomisierung ein "mal so, mal so".

wenn man /search bereitstellt, is es doch super, dass es dann schon ein suchfeld oben rechts gibt. dann muss man das auf der seite nicht mehr selbst einbauen, sondern kann dieses dann direkt für die globale suche verwenden und dann nur noch die suchergebnisse anzeigen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants