In einer bislang nur als Pre-Release verfügbaren Version 2 gibt es nun von mir das jQuery Plugin AutoSuggest auf GitHub. Das Plugin basiert weitestgehend auf der Version von Wu Yuntao, welcher aber die aktuell verfügbare Version 1.6 nicht mehr wirklich zu pflegen scheint. Ursprünglich wurde das Plugin 2009 von Drew Wilson entwickelt. Das dortige Plugin dort wurde das letzte mal im März 2010 in der Version 1.4 veröffentlicht.
Sicherheit
Als wir das Plugin in der Firma einsetzten, fiel uns jedoch auf, dass es einige schwerwiegende Sicherheitslücke in Bezug zu XSS hat. Der Aufwand war nicht klein, hielt sich aber in Grenzen. Dennoch war schnell klar, dass das Plugin dringend überholt werden muss.
So ist es zum Beispiel in der Ursprungsversion 1.4 nicht möglich, nach einem Stern oder einer eckigen Klammer zu suchen, da intern unnötigerweise die JavaScript-Methode search()
anstatt indexOf()
verwendet wird. Der Hintergrund ist, dass search()
implizit einen regulären Ausdruck bildet. Das heißt natürlich, dass noch andere Zeichen Probleme (also JavaScript-Abstürze!) verursachen.
Des Weiteren sind beide Plugins nicht sicher gegen Cross-Site-Scripting, egal ob nun beabsichtigt oder nicht. Hier war das Problem, dass Input aus nicht sicherer Quelle (also vom Benutzer oder auch vom Server) nicht hinreichend genug escaped wurde. Bereits mit Version 1.7, die ich letzte Woche bereitgestellt habe, ist dieses Problem behoben.
Und.. heißer Scheiß?
Wenn man schon ein Projekt “überarbeitet”, dann sollte man auch mit dem heißen Scheiß nicht geizen. Daher führt Version 2 auch folgende Neuerungen ein:
grunt
Mit Hilfe von grunt wird das gesamte Dependency & Task Management abgefrühstückt. Wenn man das Projekt testen – mittels QUnit – will, dann führt man grunt test
aus. Wenn man das Projekt builden und deployen will, dann führt man einfach nur grunt
aus.
grunt basiert intern auf node.js. Damit ist das Werkzeug im Grunde zu fast allem zu gebrauchen. Nett ist, dass grunt von Haus die Tasks qunit
(QUnit + PhantomJS) und server
mitliefert (quasi ein Standardfeature von node.js). In Kombination mit QUnit und PhantomJS können so per Shell auch Ajax-Tests ganz einfach ausgeführt werden.
Mit grunt wurde auch eine package.json
eingeführt. Die darf nun mal bei neuen Projekten einfach nicht fehlen.
CoffeeScript
Der Code des Plugins wurde in CoffeeScript überführt, um die Entwicklung zu vereinfachen und unnötige Fehler zu vermeiden. Bei der Überführung wurden bereits einige Optimierungen durchgeführt – beispielsweise habe ich alle unnötigen $.each
-“Schleifen” durch echte Schleifen ersetzt.
Und natürlich, dafür gibt es ein grunt Task: coffee
. Ich empfehle an dieser Stelle diesen Blogpost – und natürlich vom demselben Entwickler das Grunt Examples Repository. Dort bieten sich einige Beispiele, wie sich verschiedene Aufgaben (wie etwa CoffeeScript) in grunt integrieren lassen.
(Das selbe gilt eigentlich auch für CoffeeLint (ein noch sehr junges Projekt zum Linten von CoffeeScript), welches aber aus unerfindlichen Gründen nicht wirklich zu Laufen scheint. Wenn jemand dazu Tipps hat.. immer her damit!)
SASS
Das CSS wurde 1:1 in eine SCSS-Variante überführt. Das Ziel für später ist, dass Theming wesentlich einfacher mittels SASS und Variabel nzu ermöglichen.
Concat / Min
Die grunt built-in Tasks erledigen den üblichen Kram: Zusammenkopieren mehrerer Dateien zu einer (in der Regel also dem Distribution-Artefakt) und Minifizieren des CSS- und JavaScript Code. grunt nutzt dafür standardmäßig cssmin und uglifyjs, das ist aber natürlich austauschbar.
Lint
Ebenfalls ein grunt built-in Task ist das Linting via JSHint.
Travis CI
Wir wären kein hippes Projekt, wenn wir unseren Code nicht durch einen Build Server kontinuierlich testen würden. Für GitHub Projekte dieser Größenordnung bietet sich da natürlich Travis CI an. Immer wenn ein Push oder Pull Request auf das Projekt veranlasst wird, informiert ein Hook seitens GitHub die Build Cloud bei Travis. Und danach, wenn es sein muss, direkt böse E-Mails an die Verantwortlichen. So muss es sein.
Zukunft
Zunächst muss das Plugin selber noch optimiert werden. Der Code ist noch zu überarbeiten, die Schritte in Bezug zum Punkt “Sicherheit” sind notdürftig gemacht worden. Darüber hinaus lassen sich einige interne Abschnitte sowohl besser dokumentieren als auch erweiterbar machen (Hooks, Callbacks). Außerdem fehlen noch weitere Beispiele, wie man etwa erweiterte Renderer nutzen kann. Und, wie bereits erwähnt, soll der SCSS-Code so aufgebaut werden, dass man mit dem Ändern von Variablen das gesamte Theming erledigen kann. Dies ist für das Einbinden in eine bestehende “SASS-Infrastruktur” eh wünschenswert.