Inputfeld auslesen und belegen

[Jörg]

Hallo,

ich nutze ein Jquery Plugin, um schnell Tabelleneinträge ausfindig zu machen.

In jedem meiner Tabelleneinträge ist ein Link zu einem Formular XY.

Meine Frage ist, ob ich den "Suchbegriff" auslesen und im Querystring weiter geben kann. Meine Anschlussfrage ist, ob ich aus dem Formular XY diesen Suchbegriff dann beim Absenden des Formulars mitsenden kann (na ok, das ist eigentlich nicht die Frage... das geht schon) und ob ich auf der Antwortseite, die wiederum die Tabelle mit den Einträgen anzeigt, diesen Suchbegriff im Such-Input-Field vorbelegen kann, sodass der User exakt die Schnellsuchen-Vorauswahl wieder hat, die er zuvor auch manuell hergestellt hatte.

Ich hoffe, ich habe das verständlich ausgedrückt, daher nochmal die Reihenfolge:

1. Tabelle wird an gezeigt, User wählt Suchbegriff und 90% der Einträge gehen auf "hidden".
2. Innerhalb des Eintrages klickt der User auf "Formular zu diesem Eintrag" und der Suchbegriff wird mitgesendet.
3. User füllt Formular aus und schickt ab (Suchbegriff wird per "post" mitgesendet.
4. User ist weider auf der Tabelle (aus Punkt1) und der Suchbegriff wird automatisch ins Suchfeld eingetragen und die Tabelle wieder selektiert, d.h. die 90% gehen wieder auf "hidden"

So, wie ich das sehe, hat das Plugin keine eigenee Funktionen für mein Anliegen.

Das id-Feld des Plugins wird anscheinend zufällig generiert, die Klasse ist aber identisch und ich nutze nur 1 Suchfeld je Webseite, damit ließe sich also ggf. arbeiten.

Aber ab hier weiß ich nicht weiter. Hat jemand Tipps?

Jörg

[Rolf B]

Hallo Jörg,

Meine Frage ist, ob ich den "Suchbegriff" auslesen und im Querystring weiter geben kann.

Ich würde sagen: Ja.

Das id-Feld des Plugins wird anscheinend zufällig generiert,

Ich würde sagen: Nein. Die von Dir verlinkte Demoseite zeigt das Gegenteil. Wenn ich den Text auf der Github-Seite richtig deute, war das mal anders und es wurde geändert. Auf der Demoseite wird der quicksearcher wie folgt registriert:

$('input#id_search').quicksearch('table#table_example tbody tr');

Der Selektor ist unnötig spezifisch, #id_search oder #table_example tbody tr würden auch reichen, denn eine ID kann ja nur einmal verwendet werden.

Wie auch immer, da ist ein input-Element mit id="id_search", und diese ID ist nicht zufällig vergeben, sondern kommt von Dir und ist damit wohlbekannt. Über diese ID kommst Du an das Suchfeld heran, kannst den Wert mit $("#id_search").val() auslesen und ihn beispielsweise in ein hidden input eintragen.

Was man probieren müsste, ist eine Vergrößerung des Forms in dem das Suchfeld steht. Die Beispiele verwenden diese Struktur:

<form action="#">
   <input id="suchfeld">   <!-- hier fehlt übrigens ein Label! -->
</form>
<table id="tabelle">
<tr>...</tr>
<tr>...</tr>
<tr>...</tr>
</table>

Das Form wird nicht submitted, es scheint aus Sicht von Quicksearch ein Dummy zu sein. D.h. man könnte es auch so gestalten:

<form action="#">
  <label>Suchbegriff: <input name="suchfeld"></label>
  <table id="tabelle">
    <tr><td><button name="formular" value="1">Formular</button></td></tr>
    <tr><td><button name="formular" value="2">Formular</button></td></tr>
    <tr><td><button name="formular" value="3">Formular</button></td></tr>
  </table>
</form>

Wenn das funktioniert, klickt der Anwender auf einen der Formular-Buttons und du bekommst am Server den Suchbegriff automatisch mitgeliefert.

Wenn die Seite wieder aufgerufen wird, kannst Du das input-Feld serverseitig vorbelegen. Wenn das Plugin das ignoriert, musst Du ein input-Event darauf triggern:

$('#id_search').trigger('input');

Dadurch läuft in quicksearch die Suche an.

Rolf

[Jörg]

Hallo Rolf,

erstmal vielen lieben Dank für Deine Ausführungen. 👍😀

Ich würde sagen: Nein. Die von Dir verlinkte Demoseite zeigt das Gegenteil. Wenn ich den Text auf der Github-Seite richtig deute, war das mal anders und es wurde geändert. Auf der Demoseite wird der quicksearcher wie folgt registriert:

Oh, ich merke gerade, dass ich eine Demoseite gewählt habe, die nicht ganz passt, denn ich habe nicht diesen Fork eingebaut, sondern noch das Original davon.

Und da ist es noch so, dass die ID zufällig generiert wird.

Ich würde ungerne auf den Fork wechseln, aber es sollte doch auch möglich sein, den Suchbegriff anhand der Klasse auszulesen bzw. einzusetzen, oder? Zumindest, wenn die Klasse nur 1 x auf der Seite genutzt wird.

Jörg

[Rolf B]

Hallo Jörg,

auf der von Dir verlinkten Github Seite ist ebenfalls eine eigene ID vergeben worden.

Und da steht auch was von einem API, um programmgesteuert zu suchen (was für eine Reinitialisierung mit bekanntem Suchbegriff relevant sein könnte) - allerdings steht da nicht wie man es nutzt. Ich müsste mir dieses Plugin erstmal genauer anschauen.

Aber - es sollte alles gehen, was Du willst.

Rolf

[Jörg]

Hallo Rolf, hallo Gunnar, hallo @all

Wenn die Seite wieder aufgerufen wird, kannst Du das input-Feld serverseitig vorbelegen. Wenn das Plugin das ignoriert, musst Du ein input-Event darauf triggern:

$('#id_search').trigger('input');

Dadurch läuft in quicksearch die Suche an.

Genau an dieser Stelle steh ich grad. Den Suchbegriff auslesen, an den Link anhängen und per Formular wieder zurückliefern funktioniert.

Aber dort angekommen, hat weder

    if (isset($_REQUEST['mySearch'])) {
     echo("
	 	<script type=\"text/javascript\">
		$(document).ready(function () {
        $('.qs_input').val(".$_REQUEST['mySearch'].");
			});
	</script>
");
    }

noch

    if (isset($_REQUEST['mySearch'])) {
     echo("
	 	<script type=\"text/javascript\">
		$(document).ready(function () {
        $('.qs_input').trigger('input');
			});
	</script>
");
    }

auf das Suchfeld einen Effekt. $_REQUEST['mySearch'] ist jedoch mit dem Suchbegriff belegt.

Mein Vermutung ist, dass das Suchfeld noch nnicht existent ist, wenn ichs belegen will?

Jörg

[Rolf B]

Hallo Jörg,

eins von beiden reicht auch nicht. Du musst den Wert setzen und dann das Input-Event triggern (weil das programmatische Setzen des Wertes kein Event auslöst).

Mein Vermutung ist, dass das Suchfeld noch nicht existent ist, wenn ichs belegen will?

Diese Vermutung kannst nur Du selbst überprüfen. Aber eigentlich kann es nicht sein. Du verwendest einen Ready-Handler, d.h. das DOM ist fertig wenn die Funktion läuft.

Wie wird das Suchfeld bei Dir erzeugt und mit quicksearch verbunden?

Rolf

[Jörg]

Hallo Rolf,

eins von beiden reicht auch nicht. Du musst den Wert setzen und dann das Input-Event triggern (weil das programmatische Setzen des Wertes kein Event auslöst).

Ok, hier komme ich an meine Grenzen, was JS/Jquery angeht.

Wenn ich den Wert so setze:

$('.qs_input').val(".$_REQUEST['mySearch'].");

Wobei, besser so:

$('.qs_input').val('".$_REQUEST['mySearch']."');

wie muss ich dann anschließend den trigger ansetzen?

Wie wird das Suchfeld bei Dir erzeugt und mit quicksearch verbunden?

		$(document).ready(function () {
			$('table#table_example tbody tr').quicksearch({
				position: 'before',
				attached: '#table_example',
				labelText: 'Aktuelle Seite durchsuchen:',
				loaderText: 'Suche...'
			});
		});

Jörg

[Rolf B]

Hallo Jörg,

wie muss ich dann anschließend den trigger ansetzen?

Das stellen wir jetzt mal zurück.

$('table#table_example tbody tr').quicksearch({ ... });

Willst Du mich eigentlich veralbern? Das entspricht nicht der Anleitung und wenn ich mir den Sourcecode anschaue, ist diese Syntax auch nicht als Fallback für irgendeine Alt-Version vorgesehen.

Zumindest nicht in der sichtbaren Riklomas-Version, und die Forks von DeuxHuitHuit können das auch nicht. Ich habe mir die Versionen von Riklomas und DeuxHuitHuit heruntergeladen und deine Schreibweise einfach mal probiert. Klappt natürlich nicht. D.h. der Code, den Du gepostet hast, ist grundsätzlich falsch und funktioniert nicht.

Mach es wie in der Anleitung beschrieben und Du hast ein input-Feld, das in deinem HTML steht und das Du auch direkt aus PHP mit einem Wert versorgen kannst (value Attribut vorbelegen), ohne JavaScript generieren zu müssen oder ein Event triggern zu müssen.

Und dann mach das, was ich früher schon schrieb: Bring Suchfeld und Tabelle in ein gemeinsames Form mit method="GET". Gib dem Suchfeld ein name Attribut. Benutze Submit-Buttons, keine Links, um auf die Formularseiten zu kommen. Und alles geht automatisch. Kein Rumfummeln mit generierten Querystrings. Keine Click-Handler. Kein von PHP erzeugtes JavaScript. Kein JavaScript außer der Registrierung von quickcsearch auf dem Suchfeld. Du musst nur im PHP den Wert des Suchfeldes entgegennehmen und nachher, wenn Du auf die Seite zurückkehrst, wieder im Suchfeld hinterlegen.

Rolf

[Jörg]

Hallo Rolf,

Zumindest nicht in der sichtbaren Riklomas-Version, und die Forks von DeuxHuitHuit können das auch nicht. Ich habe mir die Versionen von Riklomas und DeuxHuitHuit heruntergeladen und deine Schreibweise einfach mal probiert. Klappt natürlich nicht. D.h. der Code, den Du gepostet hast, ist grundsätzlich falsch und funktioniert nicht.

Der Code funktioniert natürlich wohl, ich nutze den ja schon seit langer Zeit. Vielleicht nutze ich einen Fork, dessen Quelle ich nicht mehr finde, keine Ahnung. Ich denke, es ist der von Riklomas.🙄

Mach es wie in der Anleitung beschrieben und Du hast ein input-Feld, das in deinem HTML steht und das Du auch direkt aus PHP mit einem Wert versorgen kannst (value Attribut vorbelegen), ohne JavaScript generieren zu müssen oder ein Event triggern zu müssen.

Was nützt mir die Anleitung, wenn sie (anscheinend) nicht zu meinem Plugin gehört?

Und dann mach das, was ich früher schon schrieb: Bring Suchfeld und Tabelle in ein gemeinsames Form mit method="GET".

Ja, bin ich soweit bei Dir. Würde aber bedeuten, dass ich ein komplett anderes Plugin und das über meine Gesamtanwendung einbauen müsste.

Und das ist eigentlich nicht das, was ich will. Zumal ich ja schon soweit bin, dass mir nur noch das Einsetzen ins (js-generierte) Suchfeld fehlt.

Da scheint Dein Vorschlag des Triggers zielführender. Weiß aber nicht, wie der umgesetzt wird.

Jörg

[Rolf B]

Hallo Jörg,

Was nützt mir die Anleitung, wenn sie (anscheinend) nicht zu meinem Plugin gehört?

Was nützt Dir ein Plugin, dessen Herkunft Dir nicht mehr bekannt ist und für das Du keine Anleitung mehr hast??? Ich habe - durch Suchen nach "jquery quicksearch attached position" - einen Stackoverflow-Eintrag gefunden, der ein Quicksearch verwendet, das wie deins aussieht. Dort wird als Homepage dieser Version http://rikrikrik.com/jquery/quicksearch genannt, aber die Seite gibt's nicht mehr. Ein anderer Treffer deutet darauf hin, dass das die alte Homepage von Rik Lomas war. Github verlinkt www.lomalogue.com - aber diese Domain wurde von einem Müllverteiler übernommen und verrät mir nun, wie mich die Satellite-Lena zum Millionär machen will. Finger weg...

Also - du verwendest eine herrenlose Lib, die Du bei einem Computercrash auch nicht wiederbeschaffen kannst. Dieses Vorgehen ist gefährlich - falls Du ein professionelles Produkt baust, darfst Du das nicht tun.

Ich empfehle Dir dringend den Umstieg auf eine aktuelle Version. Einzige Voraussetzung: jQuery 1.8 oder höher.

Mit PHP generierter JS-Code ist zerbrechlich. Deine JS Kenntnisse sind ohnehin gering, wenn ich das richtig verstehe, und wenn Du dann noch PHP als Generator vorschaltest, wird es so richtig mühsam. Bei der Vorgehensweise, die ich Dir empfehle, entfällt viel vom JS.

Beim Umstieg musst Du natürlich ein bisschen nachdenken. Die bisherigen Optionen brauchst Du nicht mehr, weil Du das input-Feld und das Label dafür selbst ins HTML schreibst und nicht mehr von quicksearch generieren lässt. Welche Optionen für Dich sinnvoll sind, müsstest Du schon aus der Doku herauslesen.

Aber wenn nicht...

Wie Du den Trigger machen musst habe ich geschrieben. Einfach beides hintereinander.

$('.qs_input').val('".$_REQUEST['mySearch']."');
$('.qs_input').trigger('input');

Du musst nur darauf achten, dass Du diese beiden Befehle erst ausführst, nachdem quicksearch für das Eingabefeld registriert wurde. Das geht am leichtesten, wenn Du Registrierung und Wertzuweisung in der gleichen JavaScript-Funktion durchführst.

Rolf

[Jörg]

Hi Rolf,

Ich habe - durch Suchen nach "jquery quicksearch attached position" - einen Stackoverflow-Eintrag gefunden

Witzig, genau danach hatte ich auch gegoogelt, aber den Eintrag wohl übersehen.

Also - du verwendest eine herrenlose Lib, die Du bei einem Computercrash auch nicht wiederbeschaffen kannst. Dieses Vorgehen ist gefährlich - falls Du ein professionelles Produkt baust, darfst Du das nicht tun.

Zum einen habe ich gefühlte 1000 Sicherungen, zum anderen ist mir deises Quicksearch gar nihct sooo wichtig, abver Du weißt, wie das ist, wenn man mit dem Kopf durch die Wand will 😉

Aber wenn nicht...

Wie gesagt, so wichtig ist die QS ist, als dass ich da umsteigen mag.

Wie Du den Trigger machen musst habe ich geschrieben. Einfach beides hintereinander.

$('.qs_input').val('".$_REQUEST['mySearch']."');
$('.qs_input').trigger('input');

Habe ich shcon versucht, hat nichtr funktioniert. Es wird nichts in das Suchfeld eingesetzt. 😟

Du musst nur darauf achten, dass Du diese beiden Befehle erst ausführst, nachdem quicksearch für das Eingabefeld registriert wurde. Das geht am leichtesten, wenn Du Registrierung und Wertzuweisung in der gleichen JavaScript-Funktion durchführst.

Da werde ich wohl nochmal nachfassen...

Danke.

Jörg

[Rolf B]

Hallo Jörg,

Habe ich shcon versucht, hat nichtr funktioniert. Es wird nichts in das Suchfeld eingesetzt.

Hast Du im Browser gedebuggt? Hast Du überprüft, ob das richtige JS konstruiert wurde oder vll ein Syntaxerror entstanden ist? Der Nachteil dieser Konstruktion ist der Kontextwechsel im Kontextwechsel - du verwendest PHP, um JavaScript zu generieren; d.h. wenn in $_REQUEST['mySearch'] etwas steht, das von JavaScript nicht verstanden wird, bricht Dir der JS-Code im Browser ab.

Was würde McGyver RolfB tun?

Ich würde eine Testausgabe generieren:

console.log('Treffer: ' + $('.qs_input').length);

$('.qs_input').val('".$_REQUEST['mySearch']."');
$('.qs_input').trigger('input');

Wenn dabei "Treffer: 0" herauskommt, hast Du ein Timing-Problem.

Also ok, eigentlich würde ich das nicht tun, ich würde es ordentlich lösen - aber das willst Du ja nicht 😉

Rolf

[Jörg]

Hallo McGyver,

Hast Du im Browser gedebuggt? Hast Du überprüft, ob das richtige JS konstruiert wurde oder vll ein Syntaxerror entstanden ist?

Eigentlich ja. Und ja, da ist ein JS Error drin, der hat aber imho nichts hiermit zu tun und beeinflusst das auch nicht.

Was würde McGyver RolfB tun?

Ich würde eine Testausgabe generieren:

console.log('Treffer: ' + $('.qs_input').length);

$('.qs_input').val('".$_REQUEST['mySearch']."');
$('.qs_input').trigger('input');

Treffer: 1 Also gibt es das Inputfield rechtzeitig bereits.

Also ok, eigentlich würde ich das nicht tun, ich würde es ordentlich lösen - aber das willst Du ja nicht 😉

Unter uns: Ich finde auch die Fehlersuche interessant. Vielleicht auch gerade, weil ich damit alleine überfordert bin. Zum beispiel den McGyver mit der consolen-Ausgabe merk ich mir, der war schonmal gut.

Wie kann ich weiter debuggen, warum das Inputfield nicht mit dem wert belegt wird? Noch ne Idee zum debuggen?

Ansonsten würde ich morgen mal meinen Browserdebug posten.

Jörg

[Rolf B]

Hallo Jörg,

Wie kann ich weiter debuggen, warum das Inputfield nicht mit dem Wert belegt wird?

Normalerweise durch Setzen von Breakpoints im JavaScript und genaues Analysieren dessen, was da passiert. Statt einer console-Ausgabe kann man auch ein

debugger;

Statement einsetzen. Wenn die Entwicklerwerkzeuge auf sind, hält das Script dann an (man kann auch in der Source-Ansicht einen Breakpoint setzen, aber das kann beim Seitenstart schief gehen, wenn sich Zeilennummern verschieben).

Wie man das alles macht, kann ich aber nicht im Forendialog erklären.

Rolf

[Jörg]

Hallo Rolf,

Wie man das alles macht, kann ich aber nicht im Forendialog erklären.

Ich nutze in php den debugger im phpStorm. Meine Meinung ist, dass der Debugger wirklich etwas bringt, wenn man vieles ohnehin auch mit Kontrollausgaben hätte erreichen können. Er vereinfacht die Sache natürlich ungemein und man wird auf Vieles aufmerksam, was man über Kontrollausgaben nicht gesehen hätte. Aber im Grunde muss man schon wissen, was man wo sehen will oder müsste und was nicht. Ist also kein Zauberwerkzeug, wenn man programmiertechnisch nicht weit genug ist.

Und das scheinbt mir hier grad der Fall bei mir zu sein.

Ich bekomme den QS nicht getriggert, was auch immer ich versuche.

Mein Suchvalue wird ins das Inputfeld eingesetzt, aber das Plugin springt nicht drauf an.

$('.qs_input').val('".$_REQUEST['mySearch']."').trigger('input');

macht also nicht das, was wir erwarten.

Jörg

[Der Martin]

Moin,

Ich nutze in php den debugger im phpStorm.

aber hier geht um um clientseitiges Debugging - also in der Phase, wo das PHP-Script längst gelaufen ist, seine Arbeit (hoffentlich) korrekt erledigt und das Ergebnis an den Client geschickt hat.

Wechselwirkungen zwischen Server- und Client-Scripting können schwierig zu überblicken sein, wie du gerade feststellt. Ein Grund mehr, sie nicht auch noch mutwillig zu vermischen.

Aber im Grunde muss man schon wissen, was man wo sehen will oder müsste und was nicht. Ist also kein Zauberwerkzeug, wenn man programmiertechnisch nicht weit genug ist.

Eben. Ein Werkzeug kann einem die Arbeit erleichtern - aber man muss trotzdem wissen, wie's prinzipiell geht. Und man muss auch noch das Werkzeug an sich handhaben können. Ein Akkuschrauber mit umfangreichem Zubehör und 56teiligem Bit-Set ist toll - aber dann sollte man auch Torx von Innensechskant (aka Inbus) unterscheiden können.

Live long and pros healthy,
 Martin

[Jörg]

Hi Martin,

Ich nutze in php den debugger im phpStorm.

aber hier geht um um clientseitiges Debugging - also in der Phase, wo das PHP-Script längst gelaufen ist, seine Arbeit (hoffentlich) korrekt erledigt und das Ergebnis an den Client geschickt hat.

Ich wollte damit nur sagen, dass ich ganz grundsätzlich schon mit dem Einsatz/Umgang eines Debuggers vertraut bin, ich aber nicht sicher bin, dass er mir in diesem Fall viel bringen würde. Soll heißen, JS-mäßig fällts mir schwer, den Torx vom Inbus zu unterscheiden 😉

Jörg

[Jörg]

Hallo,

ich versuche, das per JS erzeugte Inputfeld zu triggern, aber es gelingt mir nicht. Weder über einen "input" selber, noch (anschließend) über den "Rechtspfeil" des bereits im Focus liegenden Inputfeldes.

$('.qs_input').val('".$_REQUEST['mySearch']."').trigger('input');
$('.qs_input').trigger({type: 'keypress', which: 39, keyCode: 39});

Beide Fälle erreichen nichts.

Wenn ich dagegen auf der Tastatur den Rechtspfeil drücke, dann wird der JS-Effekt des Inputfeldes ausgelöst.

Weiß wer, warum?🙄

Jörg

[Rolf B]

Hallo Jörg,

okay, ich bin drauf reingefallen, dass ich deine Version von quicksearch nicht habe. Kannst Du dein jquery.quicksearch.js irgendwo online bereitstellen? Ich hätte zwar ein paar Ideen, aber die basieren auf den mir vorliegenden Sourcecodes und deiner ist älter. Und da Du Dich weigerst, auf eine neue Version zu migrieren, muss ich mich halt mit deiner Version abquälen...

Rolf

[Jörg]

Hallo Rolf,

okay, ich bin drauf reingefallen, dass ich deine Version von quicksearch nicht habe.

Oh, tut mir leid. Das war nicht bewußt oder beabsichtigt.🙂

Kannst Du dein jquery.quicksearch.js irgendwo online bereitstellen? Ich hätte zwar ein paar Ideen, aber die basieren auf den mir vorliegenden Sourcecodes und deiner ist älter. Und da Du Dich weigerst, auf eine neue Version zu migrieren, muss ich mich halt mit deiner Version abquälen...

Ich bin absolut bei Dir, was den fehlenden Code angeht. Deshalb hatte ich genau heute früh schon die Idee, den Code irgendwie zugänglich zu machen, ich wußte nur nicht, wie und wo. Ich habs dann in ein fiddle gespeiechert.

Im Übrigen gvehts mir hier nur noch um den Sportsgeist in mir, dieses Problem zu lösen, denn in der Praxis ist es sogar vorteilhaft, den Suchbegriff nur einzutragen und das Suchfeld auf focus zu stellen, was man über die Voreinstellungen machen kann (siehe Quellcode des Scriptes).

Trotzdem würde ich das Problem gerne lösen (oder besser...die Lösung kennen), wie man das Suchfeld triggert.

Jörg

[Rolf B]

Hallo Jörg,

okay. Das ist ein ziemlich anderer Code 😀

(1) die ID kannst Du beeinflussen, indem Du die Option randomElement setzt. Über die Option inputClass kannst Du auch die Klasse beeinflussen.

(2) ein API gibt's nicht, und das einzige Event, auf das gelauscht wird, ist keydown. Aber nur mit bestimmten KeyCodes. D.h. einfach nur .trigger reicht nicht.

Schaun wir mal:

• Ich würde Dir empfehlen, das <BR> vor dem <span> in Zeile 158 zu entfernen. Das bringt die Anzeige unnötig in Bewegung - keine gute Idee.
• Ansonsten scheint es zu genügen, keydown zu triggern. Parameter sind nicht nötig.
• Du solltest dem Parameter aber noch einen addslashes-Aufruf gönnen. Andernfalls fliegt der Code auf die Nase, wenn ein ' irgendwo in der Eingabe ist oder ein \ am Ende steht. Eventuell injiziert Dir sonst sogar jemand PHP Schadcode. Bobby Tables lässt grüßen… (Ja, ich weiß, dass hier kein SQL läuft. Aber PHP-Injektion gibt es auch.)

$('.qs_input').val('".addslashes($_REQUEST['mysearch'])."').trigger('keydown');

(Edit: Punkt ergänzt)

Grundsätzlich würdest Du Dir das Leben vermutlich leichter machen, wenn Du JavaScript nicht als String generierst, sondern für die Erzeugung des Script-Statements aus PHP aussteigst. An der Stelle, wo Du den Request-Parameter brauchst, steigst Du mit <?= ... ?> kurz wieder in PHP ein, um den Wert zu ermitteln. Es muss <?= sein, nicht <?php, weil Du an der Stelle ja nur einen Wert brauchst und keine Befehle ausführen willst.

   // irgendein PHP gedöns
?>
<script>
   $(function() {
      $('table#table_example tbody tr').quicksearch( {
         position... attached... labelText... loaderText...
      });
      $('.qs_input').val('<?= addslashes($_REQUEST['mysearch']) ?>')
                    .trigger('keydown');
   });
</script>
<?php
   // weiter mit PHP

Rolf

[Jörg]

Hallo Rolf,

okay. Das ist ein ziemlich anderer Code 😀

Ok.

(1) die ID kannst Du beeinflussen, indem Du die Option randomElement setzt. Über die Option inputClass kannst Du auch die Klasse beeinflussen.

Stimmt, habs auch gesehen. Aber leider zu spät, jetzt habe ichs schon über die Klasse gemacht, geht auch gut.

$('qs_input').val('".addslashes($_REQUEST['mysearch'])."').trigger('keydown');

Das hatte ich schon zuvor ausprobiert, aber das hat tatsächlich keinen Effekt und triggert nicht. Jedenfalls verschwienden keine Einträge, die nicht der Suche entsprechen.

Grundsätzlich würdest Du Dir das Leben vermutlich leichter machen, wenn Du JavaScript nicht als String generierst, sondern für die Erzeugung des Script-Statements aus PHP aussteigst.

Kann sein, dass das im JS-Fall tatsächlich einfacher ist. Grundsätzlich mag ich das Ein- und Aussteigen aus dem PHP-Kontext total ungerne. Keine Ahnung, warum...

Jörg

[Rolf B]

Hallo Jörg,

Das hatte ich schon zuvor ausprobiert,

Nein, hast Du nicht. Zumindest hast Du es hier nicht aufgeschrieben. Du hast keypress getriggert, nicht keydown, das sind verschiedene Events.

Sorry für den vergessenen Punkt übrigens, es muss natürlich $('.qs_input') und nicht $('qs_input') heißen.

Ein- und Aussteigen aus dem PHP-Kontext total ungerne. Keine Ahnung, warum...

Wenn Du da Performance-Einbußen befürchtest - keine Sorge. Das macht keinen Unterschied. Es ist nicht so, als müsste für jedes <?php ... ?> ein neuer Prozess angeworfen werden. Eher andersrum: das, was zwischen ?> und <? steht, wird eigentlich nur zu einer Art von ECHO.

Das Zusammenmontieren von HTML oder JavaScript als PHP String ist dagegen sehr umständlich, Du musst mit den Anführungszeichen aufpassen und es hindert deinen Editor am passenden Syntax-Highlighting.

Rolf

[Jörg]

Hallo McGyver,

Nein, hast Du nicht. Zumindest hast Du es hier nicht aufgeschrieben. Du hast keypress getriggert, nicht keydown, das sind verschiedene Events.

Der Kerl weiß besser, was ich ausprobiert habe, als ich selber. und das Schlimme, er hat auch noch recht. 😂😂

Sorry für den vergessenen Punkt übrigens, es muss natürlich $('.qs_input') und nicht $('qs_input') heißen.

Das hatte ich schon bemerkt und korrigiert, tats trotzdem nicht. Aber da war noch ein kleiner Fehler drin, nämlich $_REQUEST['mysearch']. Das auch noch in $_REQUEST['mySearch'] korrigiert und was soll ich sagen? Dat Dingen läuft!🤗 Wahnsinn, Rolf. Find ich saustark. 👍👍👍

Ein- und Aussteigen aus dem PHP-Kontext total ungerne. Keine Ahnung, warum...

Wenn Du da Performance-Einbußen befürchtest - keine Sorge. Das macht keinen Unterschied. Es ist nicht so, als müsste für jedes <?php ... ?> ein neuer Prozess angeworfen werden. Eher andersrum: das, was zwischen ?> und <? steht, wird eigentlich nur zu einer Art von ECHO.

Nein, darum gehts nicht. Ich weiß nicht warum, aber ich mag es einfach nicht gerne. Kann ich wirklich nicht weiter umschreiben. Folge ist aber, dass ich es verhindere, wo immer möglich.

Das Zusammenmontieren von HTML oder JavaScript als PHP String ist dagegen sehr umständlich, Du musst mit den Anführungszeichen aufpassen und es hindert deinen Editor am passenden Syntax-Highlighting.

Dasist wohl wahr. Trotzdem habe ich mich daran nach all den Jahren irgendwie gewöhnt. 😇

Danke für Deine geniale Hilfe!

Jörg

[Rolf B]

Hallo Jörg,

Der Kerl weiß besser, was ich ausprobiert habe, als ich selber. und das Schlimme, er hat auch noch recht. 😂😂

🍻

Dann hast Du jetzt ja Feierabend und kannst entspannt zugucken, wie die Ungarn gewinnen 😜

Rolf

[Jörg]

Hallo Rolf,

Dann hast Du jetzt ja Feierabend und kannst entspannt zugucken, wie die Ungarn gewinnen 😜

Mache ich. Und als Deutsch/Ungar gewinne ich heute auf jeden Fall 🤗 Ich tippe aber auf 1:1.

Jörg

[MudGuard]

Hi,

Dann hast Du jetzt ja Feierabend und kannst entspannt zugucken, wie die Ungarn gewinnen 😜

Jetzt wollt ich grad schreiben "Noch isthat Polen nicht verloren". Aber das Spiel ist ja doch schon vorbei …

cu,
Andreas a/k/a MudGuard

[MudGuard]

Hi,

Dann hast Du jetzt ja Feierabend und kannst entspannt zugucken, wie die Ungarn gewinnen 😜

Könnte zu einem elektrisierenden Schwimm-Wettbewerb mutieren, so wie es hier gerade schüttet und blitzt und donnert …

cu,
Andreas a/k/a MudGuard

[Der Martin]

Hallo,

Dann hast Du jetzt ja Feierabend und kannst entspannt zugucken, wie die Ungarn gewinnen 😜

Könnte zu einem elektrisierenden Schwimm-Wettbewerb mutieren, so wie es hier gerade schüttet und blitzt und donnert …

das hatte ich hier um kurz nach sieben. Der nächstgelegene Einschlag war nach der klassischen Zählmethode weniger als 500m entfernt. Der Regen hielt sich dabei allerdings in Grenzen.

Live long and pros healthy,
 Martin

[MudGuard]

Hi,

Könnte zu einem elektrisierenden Schwimm-Wettbewerb mutieren, so wie es hier gerade schüttet und blitzt und donnert …

das hatte ich hier um kurz nach sieben. Der nächstgelegene Einschlag war nach der klassischen Zählmethode weniger als 500m entfernt. Der Regen hielt sich dabei allerdings in Grenzen.

Hier war's - solange es noch unterscheidbar war - teilweise unter 1s zwischen Blitz und Donner.

Dann ne ganze Weile so viele Blitze und Donnerschläge, daß die nicht mehr zuzuordnen waren.

Die Sat-Anlage im Haus war auch ausgefallen … Gut, daß da ein Antennen-Techniker im Haus wohnt.

Jetzt hat sich's wettermäßig etwas beruhigt.

cu,
Andreas a/k/a MudGuard

[Der Martin]

Hallo Andreas,

Hier war's - solange es noch unterscheidbar war - teilweise unter 1s zwischen Blitz und Donner.

also in unmittelbarer Nähe. Das erinnert mich an ein Gewitter, das ich bei meinem früheren Arbeitgeber erlebt habe. Das Nachbargrundstück gehörte einer Baufirma, und dort stand ein für Baustellen typischer Gitterkran. Während eines heftigen Unwetters schlug ein Blitz in diesen Kran nebenan ein. Abgesehen vom intensiven Lichtblitz fand ich es auch gespenstisch, dass sich sofort meine Haare aufgestellt haben.

Der Blitzeinschlag hat, obwohl er in den Kran auf dem Nachbargrundstück erfolgte, auch bei uns einige Baugruppen der Telefonanlage "beyond all repair" zerstört.

Jetzt hat sich's wettermäßig etwas beruhigt.

Dann ist's ja gut.

Live long and pros healthy,
 Martin

[1unitedpower]

Der Nachteil dieser Konstruktion ist der Kontextwechsel im Kontextwechsel - du verwendest PHP, um JavaScript zu generieren; d.h. wenn in $_REQUEST['mySearch'] etwas steht, das von JavaScript nicht verstanden wird, bricht Dir der JS-Code im Browser ab.

Um das nochmal etwas deutlicher zu formulieren: der Code ist anfällig für XSS-Angriffe. Wenn man schon JavaScript-Code generieren möchte, dann muss man den Kontextwechsel beachten. In vielen Fällen reicht schon ein json_encode aus, um aus einem PHP-String einen JavaScript-String zu machen.

[Jörg]

Der Nachteil dieser Konstruktion ist der Kontextwechsel im Kontextwechsel - du verwendest PHP, um JavaScript zu generieren; d.h. wenn in $_REQUEST['mySearch'] etwas steht, das von JavaScript nicht verstanden wird, bricht Dir der JS-Code im Browser ab.

Um das nochmal etwas deutlicher zu formulieren: der Code ist anfällig für XSS-Angriffe. Wenn man schon JavaScript-Code generieren möchte, dann muss man den Kontextwechsel beachten. In vielen Fällen reicht schon ein json_encode aus, um aus einem PHP-String einen JavaScript-String zu machen.

Danke nochmal für den nachdrücklichen Hinweis und einen Lösungsansatz.

Jörg

[Jörg]

Ich habe das Script mal online gestellt. Ich war mir nicht sicher, ob ich das hier posten soll/darf/kann.

Jörg

[Gunnar Bittersmann]

@@Jörg

Meine Frage ist, ob ich den "Suchbegriff" auslesen und im Querystring weiter geben kann.

Suchbegriff anhängen geht dann so: Codepen

• Event delegation nutzen, Eventhandler für ein Elternelement registrieren
• Wenn das Event durch Click auf einen Link ausgelöst wurde (bei dir anpassen: einen Link innerhalb einer solchen Tabelle), dann
  • überschreibe den Parameter im URI, wenn schon vorhanden
  • ansonsten: füge ihn hinzu, mit vorangestelltem
    • '?', wenn es noch keinen Query gibt
    • sonst '&'

Statt link.href = url.href; kann man auch location = url.href; machen, dann wird der Original-URI des Linkelements im DOM nicht überschrieben. Klappt aber in CodePen mit dem target="_blank" nicht so gut.

😷 LLAP

[Rolf B]

Hallo Gunnar,

danke für das Beispiel.

Wie siehst Du meinen Vorschlag mit dem Form, das die Verzweigung zum Formular mit Buttons realisiert und das Suchfeld einfach mitnimmt?

Rolf

[Gunnar Bittersmann]

@@Rolf B

Wie siehst Du meinen Vorschlag mit dem Form, das die Verzweigung zum Formular mit Buttons realisiert und das Suchfeld einfach mitnimmt?

Links sind Links und Buttons sind Buttons. Jörg schrub ja, dass es Verweise zu unterschiedlichen Zielen sind – also Links.

Ob man das auch so auffassen kann, dass es verschiedene Submit-Buttons des Suchformulars sind, vermag ich ohne genauere Kenntnis des Anwendungsfalls nicht einschätzen.

Mit „man“ meine ich hier insbesondere Nutzer assistiver Technologien wie Screenreader, die damit klarkommen müssen, wie die interaktiven Elemente angesagt werden.

😷 LLAP

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Suchbegriff anhängen geht dann so: Codepen

Nachtrag: Bei dir ist newSearch natürlich nicht statisch, sondern der aus dem Suchfeld ausgelesene Wert.

😷 LLAP

[Jörg]

Hallo Gunnar,

Suchbegriff anhängen geht dann so: Codepen

Nachtrag: Bei dir ist newSearch natürlich nicht statisch, sondern der aus dem Suchfeld ausgelesene Wert.

Danke erstmal, aber das habe ich ehrlich gesagt anders gelöst, da bei mir auch der Link immer identisch aufgebnaut ist.

		$(document).ready(function () {
		$('.form_go').on('click', function(){
		var mySearch = $('.qs_input').val();
        $(this).attr('href', function() {
        return this.href + '&mySearch=' + mySearch;
        });           
		});
		});	

Jörg

[Rolf B]

Hallo Jörg,

uiuiui.

(1) $(document).ready(function() { ... }); ist veraltet. jQuery empfiehlt, nur noch $(function() { ... }); zu verwenden. Hm. Hab ich das nicht vor mind. einem Jahr schonmal geschrieben? Vielleicht nicht Dir.

(2) Du musst den Wert von mySearch für URLs maskieren. Was ist, wenn Dir jemand ein ?, & oder # ins Suchfeld tippt? Dazu verwendet man die encodeURIComponent Funktion.

Rolf

[Jörg]

Hi Rolf,

(1) $(document).ready(function() { ... }); ist veraltet. jQuery empfiehlt, nur noch $(function() { ... }); zu verwenden. Hm. Hab ich das nicht vor mind. einem Jahr schonmal geschrieben? Vielleicht nicht Dir.

(2) Du musst den Wert von mySearch für URLs maskieren. Was ist, wenn Dir jemand ein ?, & oder # ins Suchfeld tippt? Dazu verwendet man die encodeURIComponent Funktion.

wird beides geändert 😉

Jörg

[Gunnar Bittersmann]

@@Rolf B

(1) $(document).ready(function() { ... }); ist veraltet.

Also ich würd sagen: jQuery an sich ist veraltet. 😏

Es war mal gut gegen Probleme, die heute nicht mehr bestehen:

• Browserinkompatibilitäten ausgleichen und Polyfills bereitstellen
• ein API fürs DOM, wovon vieles Einzug in Vanilla-JavaScript gehalten hat

Dummerweise basieren einige Anwendungen/Biblotheken auf jQuery anstatt dass sie in Vanilla-JavaScript geschrieben wären. Das ist so ziemlich der einzige Grund, heute noch jQuery einzusetzen.

😷 LLAP

[Jörg]

Hallo Gunnar,

Dummerweise basieren einige Anwendungen/Biblotheken auf jQuery anstatt dass sie in Vanilla-JavaScript geschrieben wären. Das ist so ziemlich der einzige Grund, heute noch jQuery einzusetzen.

Genau davon habe ich einige eingebaut, für die es kein Vanilla-JS-Adäquat gibt. Insofern ziehe ich es mit durch.

Jörg