Project

General

Profile

Actions

Feature #5805

open

TypeAHead SQL value instead of key stored

Added by Nicola Chiapolini almost 6 years ago. Updated about 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
Start date:
10.04.2018
Due date:
% Done:

0%

Estimated time:
Discuss:
Prio Planung:
No
Vote:

Description

Ich habe ein Textfeld mit folgenden Parametern:


typeAheadSql = SELECT shortname AS 'id', CONCAT(firstname, ' ', lastname, ', ', shortname) AS 'value' FROM _right_to_confer_phd WHERE lastname LIKE ? OR firstname LIKE ? or shortname LIKE ? ORDER BY lastname
typeAheadSqlPrefetch = SELECT CONCAT(firstname, ' ', lastname, ', ', shortname) AS value FROM _right_to_confer_phd WHERE shortname=?
typeAheadMinLength = 1
typeAheadLimit = 20
typeAheadPedantic = 0

Die Suche funktioniert, aber beim Speichern wird der Value (firstname lastname, shortname) statt der id (shortname) gespeichert.
Problem scheint, dass JS im hidden Feld den Value statt der id einfügt...


Related issues

Related to QFQ - Bug #5444: typeahead: Nach einem Save wird der key angezeigt statt dem ValueClosed14.02.2018

Actions
Actions #1

Updated by Nicola Chiapolini almost 6 years ago

Scheint typeAheadPedantic = 1 löst das Problem

Evtl. könnte das in der Dokumentation besser erklärt werden...

Actions #2

Updated by Nicola Chiapolini almost 6 years ago

  • Status changed from New to Ready to sync (develop)
Actions #3

Updated by Carsten Rose almost 6 years ago

  • Status changed from Ready to sync (develop) to In Progress
  • Target version set to 55

In Doku besser beschreiben

Actions #4

Updated by Carsten Rose almost 6 years ago

  • Related to Bug #5444: typeahead: Nach einem Save wird der key angezeigt statt dem Value added
Actions #5

Updated by Carsten Rose over 5 years ago

  • Tracker changed from Support to Feature
Actions #6

Updated by Carsten Rose about 5 years ago

  • Status changed from In Progress to New
Actions #7

Updated by Carsten Rose about 4 years ago

  • Status changed from New to Some day maybe
Actions #8

Updated by Carsten Rose about 4 years ago

  • Target version changed from 55 to next9
Actions #9

Updated by Nicola Chiapolini about 1 year ago

  • Prio Planung set to No

Wir sind eben wieder in das Problem gelaufen (v23.1.1), deshalb ein Update

typeAheadPedantic = 1 löst das Problem jetzt nicht, gut möglich dass es das auch früher nicht gelöst hat.

Das Problem tritt auf in einem Textfeld mit dynamic update und typeAhead.

typeAheadSql = SELECT id AS 'id', PC_Stufe3 AS 'value' FROM org_units_fv WHERE PC_Stufe3 LIKE ?
typeAheadSqlPrefetch = SELECT id AS 'id', PC_Stufe3 AS 'value'  FROM org_units_fv WHERE id=?
typeAheadMinLength = 3
typeAheadLimit = 40
typeAheadPedantic = 1

(PC_Stufe3 beginnt mit zahlen)

  • Wenn ich das Feld das erste Mal speichere, landet die ID in der DB.
  • Wenn ich das Formular wieder öffne, ein anderes Feld verändere und wieder speichere, landen die Ziffern aus PC_Stufe3 in der DB

Die Lösung, die wohl auch letztes Mal funktioniert hat, war die Daten gar nicht via Text-Feld sondern via separate afterSave Action zu speichern.

Puzzeling Fact: Die funktionierende Lösung hat ein DB-Feld origin und zwei FormElement nodb_origin (text, mit dem Inhalt oben) und nodb_safe_origin (afterSafe-Action). Wenn ich im sqlBefore-Query von nodb_safe_origin einen Fehler habe, schafft es QFQ irgendwie wieder die Ziffern aus PC_Stufe3 in die DB zu schreiben - obwohl das Formular gar kein entsprechendes Element hat...

Actions #10

Updated by Nicola Chiapolini about 1 year ago

PS: eine zusätzlicher, positiver Effekt der Lösung mit separatem afterSafe ist, dass ich so den Inhalt des Feldes löschen kann, wenn es ausgeblendet wird...

Actions #11

Updated by Carsten Rose about 1 year ago

  • Status changed from Some day maybe to New
  • Target version changed from next9 to 24.2.0
Actions #12

Updated by Nicola Chiapolini about 1 year ago

Und noch ein Hinweis, die Lösung hat doch nicht ganz funktioniert. Das Probelm bestand weiterhin, wen nodb_origin ausgeblendet war. Dann wurde das Fomular immer als verändert betrachtet und die entsprechende Browserwarnung ausgelöst (letztes Mal war wurde das Formular wohl nur zum Erstellen genutzt, dann scheint alles zu funktionieren). Das Problem wurde (hoffentlich) gelöst, indem das wir doch wieder direkt origin bearbeiten, das Feld immer angezeigen aber den Inhalt via sqlValidate prüfen... Nicht besonders elegant.

(Alles in allem scheint es hier zu viele bewegliche Teile mit unerwarteten Interaktionen zu haben. Evtl. könnte die Dokumentation hier weiterhelfen: Wie mache ich ein nur manchmal angezeigtes Formularfeld mit TypeAHead-SQL?)

Actions

Also available in: Atom PDF