Assistent?

[henfri]

Hallo,

Klasse. Das war es (die Klammern müssen weg).
Das ist echt super und eine riesige Erleichterung. Im Preview funktioniert es sogar das Licht zu schalten.

Folgende Anregungen sind nur das I-Tüpfelchen:

• es wäre gut, wenn die Klammern {} kein Problem wären
• Bei den Icons wäre gut, wenn die Suche bei der Autovervollständigung so sucht, dass das (schon) geschriebene nicht am Anfang sein muss. Z.B. wenn man "arrow" tippt, sollte er "control_arrow.svg" und auch "arrow_left" finden. Ich wusste jetzt z.B. nicht, was ich tippen musste, um einen Pfeil zu finden. Auch bei den Items wäre das vielleicht eine Überlegung wert -da bin ich aber nicht sicher.
• Es wäre gut, wenn ein "Tab" das Popdown-Menü der Auto-Verfollständigung öffnet, auch wenn man noch nicht drei Buchstaben getippt hat

Aber wie gesagt: Das ist alles schon auf sehr hohem Niveau.

Gruß,
Hendrik

[AndreK]

Hallo henfri

schön wenns gefällt .

habe noch mal upgedatet

folgende Anmerkungen :

"es wäre gut, wenn die Klammern {} kein Problem wären" -> das ist umgesetzt

"Bei den Icons wäre gut, wenn die Suche bei der Autovervollständigung so sucht, dass das (schon) ...." -> ist eingebaut, man kann nun mit "STRG+9" oder mti der Maus eine Wildcardsuche im autocomplete dict einschalten. Ich dachte die Wildcardsuche kann manchmal auch lästig sein - deshalb ein/ausschaltbar

"Es wäre gut, wenn ein "Tab" das Popdown-Menü der Auto-Vervoll....." -> das ist eingebaut - Hotkey ist "STRG+Space", den Tab hab ich nicht verwendet weil der "Indent - Spaces" einfügt

Es wird nun die Anzahl der Einträge in den jeweiligen Autocomplete-Dicts angezeigt.

Gruss Andre

[wvhn]

Hallo Andre,

tolle Arbeit. Der widget constructor funktioniert auf Anhieb und sieht schon sehr, sehr gut aus. Folgendes ist mir noch aufgefallen:

• die als 'deprecated' markierten widgets sollten nicht mehr unterstützt werden. Wenn das in der Umsetzung zu aufwendig ist, können wir das aber auch dadurch lösen, dass wir diese in dem Release löschen, in dem der widget constructor offiziell enthalten ist.
• in den dicts hast Du die einzelnen Elemente schon nach Eigenschaften sortiert. Es wäre klasse, wenn dies auch kontextsensitiv angeboten würde. 'icon' ist z.B. ein Darstellungstyp für den Stateswitch, aber der WC bietet bei der Typangabe alle vorhandenen icons an. (Eigenschaften Color und Widget).

widget_constructor_icon.PNG

• Nach erstmaligem Rendern muss ich die Seite komplett neu laden (die Eingaben sind dann weg), damit ich ein neues Widget rendern kann (Firefox, Apache2 in Form von XAMPP auf dem PC)
• Das Eingabefenster akzeptiert mehrere Zeilen, zeigt aber in Zeile 2 bei einem zweiten Widget keine Tooltips mehr an (ist OK, aber man sollte darauf hinweisen, dass jeweils nur ein Widget bearbeitet werden kann.

Wenn das Fenster "Widget-Preview" nichts anzeigt, könnte man es auch für eine kurze Bedienungsanleitung nutzen.

Vielen Dank!!

Gruß
Wolfram

[AndreK]

Hallo Wolfram,

Du hattest zum Test (lt. Screenshot) nicht den letzen Stand. Die "deprecated" Items werden auch als solche ausgewiesen.
Ich kann diese auch komplett rausnehmen, oder auch über eine Checkbox "abschaltbar/zuschaltbar" machen.
Die "deprecated" Widgets komplett rausnehmen fände ich nicht so glücklich. (Nur meine Meinung)
Es gibt sicher noch User (da gehöre ich auch dazu) die noch alte Widgets im Einsatz haben (wenn auch nur auf dem Backup-System)

Ich würde mich für das kontext-sensitive dann auf die jeweilige "type"-Eigenschaft des Parameters stürzen. Das sieht nach dem was ich gesehen habe gut gepflegt aus.

type = "image" oder "icon" -> Icon Dict
type = "item" -> Item Dict
type = "color" -> Color Dict

das dann alles als "enhält" Vergleich mit Umwandlung in Kleinbuchstaben, dann müsste auch "icon_on" / "icon_off" falls vorhanden noch treffen.
Falls keine Vergleich oben trifft dann Anzeige von "Allem" oder "Nichts", dies aber wieder umschaltbar. Das Auto-Set Dict würde dann immer beim Wechseln von einem
Paramter zum nächsten gesetzt und könnte dann immer noch manuell umgeschaltet werden.
Wie ist Eure Meinung dazu ? Vielleicht hat noch jemand andere Vorschläge/Ergänzungen für die Eingrenzung der Dicts ?

Es ist aktuell nur möglich ein Widget zu erstellen. Mehrere Zeilen sind vorgesehen um hier auch mit Zeilenumbrüchen eine bessere Lesbarkeit zu erzielen (das funktioniert auch schon)

Das mit mit Neuladen nach dem "Rendern" sollte nur auftreten wenn nicht in einem neuen Fenster gerendert wird. Der "inline" Preview ist ein IFrame. Hier wird dann beim Laden der Seite innerhalb der Browser-Sitzung auch die index.php neu geladen. Diese passt dann zwar zum Iframe aber zum Rest nicht mehr.
Dazu habe ich keine Lösung ?? (Vorschläge gerne willkommen) (Ich weiß jetzt auch wieso mal jemand gesagt hat "Iframes sind böse")

Falls das auch Auftritt (mit der letzten aktuellen Version) beim Rendern in ein neues Fenster gerne nochmal eine Info.

Was gehen müsste, ist eine "einfache" Anzeige der Doku zum "WC" im Preview - schau ich mir mal an.

Screenshot des letzten Standes anbei

Anregungen gerne willkommen.

Gruss Andre
widget_constructor.jpg

[wvhn]

Hallo Andre,
der Stand war vom 25.4. 18:13 aus Deinem Repository. Ich teste nochmal mit dem allerletzten.

Das Attribut 'type' / zum Teil auch 'style' ist mehrdeutig und eigentlich immer nur aus dem Docstring ablesbar. Beim Stateswitch ist es die Darstellung der Buttons (icon, micro, mini, midi), beim Select kommt noch 'menu' dazu, beim Input sind es ganz andere Begriffe. Vielleicht reicht es auch, für diese Optionen im Tooltip nur die Erklärungen im Docstring zu "highlighten" und keine Auswahlliste anzuzeigen.

Wegen der deprecated Widgets: ich würde halt niemanden animieren wollen, in der v2.9.x noch mit veralteten Widgets anzufangen. Im nächsten großen Release werden die ziemlich sicher nicht mehr drin sein.

Gruß
Wolfram

Edit: Das Ding ist echt genial... Aktueller Stand von heute: erneutes Rendern klappt übrigens, so lange man das neue Fenster nicht schließt. Einmal geschlossen, macht er kein neues Fenster mehr auf.

[AndreK]

Hallo Wolfram,

vielleicht war ich nicht päzise genug. Jeweils zum Paramter liefert die Funktion "twig_docu" (welche ich nutze) ein Attribut "type" (je Parameter)
Das steht so nicht in der smartvisu-Doku, wird aber geliefert :-)

Das ist zum Beispiel bei
"basic.stateswitch(id, item" -> type = item
bei :
"basic.stateswitch(id, item, type" -> type = type
bei :
"basic.stateswitch(id, item, type, text" -> type = text
bei :
"basic.stateswitch(id, item, type, text, icon" ->; type = image

Bei

basic.select(id,item,type" -> type = type

"style" kommt in der gelieferten JSON-Struktur gar nicht vor

Ich habe mal die komplette Info die "twig_docu" liefert angehängt. Mi... , anhängen geht nicht, per PN geht auch nicht
Wenn Du mir per PN Deine mail-Adresse zukommen lässt sende ich Dir das gerne mal, da stehen viele interessante Dinge drin.



Gruss Andre

P.S.: Das mit keinem neuen Fenster öffnen hab ich so gemacht damit man nicht mit Fenstern überflutet wird. Das wäre vielleicht auch noch eine Option als Check-Box (öffne neues Fenster "X"). Das "erste" Fenster prüft ja auch auf Änderungen der Datei und reloaded selbstständig, ausser man ist auf einen TWIG-Fehler gelaufen, dann wird auch nichts automatisch reloaded, dann hilft nur STRG+F5

[henfri]

Wie ist Eure Meinung dazu ?

Das klingt sinnvoll.

Gruß,
Hendrik

[Onkelandy]

Das mit dem Type sollte wie beschrieben klappen. Wir hatten ja auch mal die Idee den Type Typ in der inline Doku gleich mit anzugeben, das fände ich schon sehr cool. Ich denke, gemeinsam wären wir da auch recht rasch mit allen Widgets durch. Dann könnte man nämlich auch hier die dicts vielleicht sogar dynamisch anpassen!? Also wenn da steht @param{item(bool)=} könnten nur die bool Items aus shng geladen werden. Wäre bestimmt auch nochmals ein Stück übersichtlicher und sofern im Popup darauf hingewiesen wird auch Vermeidung von Fehlern.

Bei den deprecated Widgets bin ich ganz bei Wolfram - die sollten imho aus dem Widget Creator raus. Wenn man noch alte Widgets im Backup hat, okay, funktioniert ja, aber erneut alte Widgets erstellen sollten wir unbedingt verhindern. Die neuen Widgets sind ja auch viel besser, ein Umstieg lohnt

Danke für die super Arbeit!

[AndreK]

Hallo,

ich habe den "Tag der Arbeit", mangels "Hecken-Festen", genutzt um den "wc" mal weiter zu bringen.

Folgendes ist jetzt neu :

- es werden "genestete Widgets" unterstützt.
- die deprecated Widgets werden weggefiltert. (Kann über einen Paramter im JS-Teil gesetzt werden -> "remove_deprecated = true" in Datei ändern)
- die "Wildcard"-Suche ist zu/abschaltbar (es wird dann bei Eingabe von "arr" auch 'control_arrow_down' usw angezeigt.
- das AutoComplete Dict kann mittels CTRL+Space auch komplett geöffnet werden ohne Eingabe von einem "Suchbegriff"
- das AutoComplete Dict wird mittels der Werte von paramter->type automatisch gesetzt (kann aber dennoch manuell umgeschaltet werden)
- das AutoComplete Dict kann mit CTRL+6 ausgeschalten werden
- wenn parameter->type nichts brauchbares liefert wird das AutoComplete Dict ausgeschalten (kann aber wieder manuell eingeschalten werden)
- der parameter->type wird wie folgt ausgewertet : color/colour -> Farb-Dict - item -> Item-Dict - icon/imange -> Icon-Dict (es wird immer auf "enthält" geprüft)
- Im Preview auf der wc-Seite wird eine kurze README, die es auch auf Git im Ordner ./widget_constructor/ als MD-Datei gibt, angezeigt.
- das CodeMirrot unterstützt nun auch "Bracket-Matching"
- das zu "rendernde" Widget wird inkl. der geschweiften Klammern in die Zwischenablage kopiert, so dass man es dann direkt in die entsprechende HTML-Datei einfügen kann.
- was in einem Zwischenstand schon war aber nicht im ersten sind ein Preview im Tooltip für Icons und Colors.

Ich glaube alles, was bisher so aufgelaufen ist, eingebaut zu haben, falls ich was vergessen habe bitte kurze Info

Bitte nochmal testen und gerne Rückinfo was noch geändert werden sollte.

Gruss Andre

[Onkelandy]

Ganz großes Kino, vielen Dank für das super Update!!
Ich habe ein paar kleinere Bugs/Probleme entdeckt.

Hier möchte ich ein dynamisches Icon in einem stateswitch Widget angeben. Nesting funzt prinzipiell, aber die Vorschläge nicht. Ist "Wildcard Search" deaktiviert, kommt nach Tippen von icon. gar nichts. Mit Wildcard Search kommt ein Ergebnis, allerdings deutet die Vorschau im Tooltip auf ein nicht vorhandenes Bild hin (vielleicht nur bei mir so..? Das vorgeschlagene Icon heißt jquery.mobile.icons.min.)
wc_icon.png

Möchte man nach Rendern eines Widgets ein neues Widget anlegen, klappt das Pulldownmenü nicht wirklich. Es wird nicht erkannt, dass ich wieder bei 0 starten möchte..?
wc_secondtry.png

Startet man "blank" mit icon., passen die Einträge icon0 und icon1 nicht wirklich. Ist zugegebenermaßen ne kleine Kleinigkeit
wc_widgeticon.png

Eventuell wär's noch net, den Tooltip ausblendbar zu machen, zB, um im Menü darunter zu navigieren..?

Danke und gute Nacht!

[henfri]

Klasse, vielen Dank für das Update!

[wvhn]

Startet man "blank" mit icon., passen die Einträge icon0 und icon1 nicht wirklich.

Das hatte ich mit „kontextsensitiv“ gemeint. Wenn man Listeneinträge mit der Eigenschaft „Color“ an dieser Stelle ausblenden könnte, wäre das Klasse.

[AndreK]

Hallo,

habe ein wenig nachgebessert.

Das icon "jquery.mobile.icons.min" wurde angezeigt weil im Ordner /icons/ws/ eine Datei "jquery.mobile.icons.min.css" liegt. Keine Ahnung ob die dahin soll ?
Ich prüfen nun auf Datei-Endung "svg". Dann werden nur die icons im Dict aufgeführt.

Wenn kein Widget gewählt wurde (im Editor steht) wird nur das Widget-Dict angezeigt, ist dann auch nicht umschaltbar.

Hier möchte ich ein dynamisches Icon in einem stateswitch Widget angeben. Nesting funzt prinzipiell, aber die Vorschläge nicht. Ist "Wildcard Search" deaktiviert, kommt nach Tippen von icon. gar nichts. Mit Wildcard Search kommt ein Ergebnis, allerdings deutet die Vorschau im Tooltip auf ein nicht vorhandenes Bild hin (vielleicht nur bei mir so..? Das vorgeschlagene Icon heißt jquery.mobile.icons.min.)

Hier wird auf Grund des ersten Widget ein "Icon" erwartet, es wird automatisch auf "icons" gefiltert. Der "wc" weiß ja nicht das Du hier eine "Funktion" also ein weiteres Widget einfügen möchtest. Möglichkeiten wären :
- Bei Parameter-Typ "Icons/Image" im Autocomplete-Dict auch Widgets aufführen ? Meinugen ?
- Stand gestern kann/muss man das Dict an der Stelle manuell umschalten

Das aktuelle Dict wird immer unten rechts angezeigt.

ich habe noch eine Close-Button im Tooltip-Fenster eingebaut.

„kontextsensitiv“

Das ist "kontextsensitiv" - allerdings dann mit ein paar anderen Einschränkungen - siehe oben.
Schau Dir den aktuellen Stand vielleicht nochmal an.

Gruss Andre

[Onkelandy]

Das besagte css File braucht es wohl tatsächlich. Nach SVG zu filtern ist jedenfalls eine gute Idee.
Wegen icons und Widgets. Könnte man nicht nach dem "." abfragen? Die Standardicons haben alle keinen Punkt im Namen. Somit könnte beim Parameter "icon" eine Widgetliste kommen, sobald man einen Punkt eintippt?

Was noch ein cooles Feature wäre: wenn zB beim Stateswitch für den Typ dezidierte Varianten angegeben sind wie "icon", "mini", etc. könnten auch nur diese Optionen im Autocomplete als Liste auftauchen. Das würde die Sache noch mehr vereinfachen.

Sollen wir noch die Sache mit dem item Typ angehen? Wie beschrieben, zB wenn hinter dem item im @param in Klammer der Typ steht (oder auch mehrere Typen mit Komma getrennt), werden nur die entsprechenden Items gelistet? Wäre super.

Wärs eventuell möglich, wenn man nur einen Beistrich eintippt, dass automatisch ein leeres '' erzeugt wird? Weiß nicht, ob es zu Problemen führen kann. Aber zB wenn ich basic.stateswitch(, 'itemname') eintippe, könnte vor dem ersten Komma '' eingesetzt werden?

Vielen Dank für die super Arbeit.

[AndreK]

Hi OnkelAndy,

Wegen icons und Widgets. Könnte man nicht nach dem "." abfragen? Die Standardicons haben alle keinen Punkt im Namen. Somit könnte beim Parameter "icon" eine Widgetliste kommen, sobald man einen Punkt eintippt?

Das würde ja automatisch passieren wenn bei "Icons" die icons und die widgets im autocomplete dict sind. Es würden dann die Icons + Widgets vorgeschlagen bis Du den Punkt eingibst. Ich denke bevor ich hier was ändere wären mehr Meinungen ganz gut.

Sollen wir noch die Sache mit dem item Typ angehen? Wie beschrieben, zB wenn hinter dem item im @param in Klammer der Typ steht (oder auch mehrere Typen mit Komma getrennt), werden nur die entsprechenden Items gelistet? Wäre super.

Ich kann das gerne wenn die Struktur klar ist einbauen. Könnte man ja exemplarisch an einem Widget testen.
Das würde auch heißen man muss die "twig_docu"-Funktion anpacken damit der Typ sauber rüberkommt. Ich habe im Moment keine Debug-Umgebung für PHP, ohne die krieg ich das nicht hin. Sonst wer ?
Freiwillige vor !

Den Item-Typ aus shNG bekomm ich sicher hin.

Was noch ein cooles Feature wäre: wenn zB beim Stateswitch für den Typ dezidierte Varianten angegeben sind wie "icon", "mini", etc. könnten auch nur diese Optionen im Autocomplete als Liste auftauchen. Das würde die Sache noch mehr vereinfachen.

Das mit den dedizierten Typen wäre aus meiner Sicht genauso zu handhaben wir die Datentypen der items. Separater Ausdruck in der Doku der durch "twig_docu" entsprechend aufbereitet wird.
Auch hier Freiwillige vor !

Wärs eventuell möglich, wenn man nur einen Beistrich eintippt, dass automatisch ein leeres '' erzeugt wird? Weiß nicht, ob es zu Problemen führen kann. Aber zB wenn ich basic.stateswitch(, 'itemname') eintippe, könnte vor dem ersten Komma '' eingesetzt werden?

Hier bin ich gerade noch am experimtieren mit "closeBrackets" (gibts als fertiges Addon für CodeMirror) - das macht dann automatisch die Klammern + Quotes zu.
Das Addon zerschiesst aber im Moment den CSS-Teil - keine Ahnung wieso, muss ich suchen. Wäre das eine Lösung ?
Ansonsten wäre noch die Idee zu prüfen ob es vor dem aktuellen Komma, und vor dem vorletzten Komma, bzw einer Klammer, zwei Hochkommas gibt.
Das heißt aber die Eingabe ab dem Cursor rückwärts Zeichen für Zeichen zu untersuchen. Nicht sehr schön.

Gruss Andre