nicht angemeldet
Für eine halbwegs brauchbare Selektor-Engine noch einmal ein halbes Jahr.
Keine Ahnung, was Du damit meinst. Ist mir jedenfalls noch nicht abgegangen.
Du bist professioneller JavaScript-Programmierer und kannst mit dem Begriff nichts anfangen? Ähm. Gut. Ich wusste nicht, dass man zeitgemäßes DOM Scripting OHNE eine Selektor-Engine machen kann.
Selektor-Engines sind seit 2003 Bestandteil der meisten Frameworks und Toolkits. jQuery nutzt beispielsweise Sizzle. Sie erlauben einem, Elemente im DOM über CSS-ähnliche Selektor auszuwählen. $('#el .class[attr=val]') gibt einem etwa alle Element-Objekte mit der Klasse class und dem Attribut attr="val" im Element #el zurück.
mein Problem ist halt, das ich nie vor dem Problem stehen möchte, daß beim Kunden irgendein Problem auftritt, das ich nicht verstehe, weil ich keine Lust habe, ein Framework so komplett zu studieren, daß ich es gleich selbst schreiben könnte. Aus dem Grunde stehe ich dem etwas bis ziemlich reserviert gegenüber...
Frameworks kochen auch nur mit Wasser. Wer auf dem Level ist, alles selbst zu schreiben, der kann auch Framework-Code verstehen. Es treten keine Probleme auf, die man nicht in absehbarer Zeit lokalisieren kann. Liegt der Fehler in der Bibliothek, muss man höchstens einen Workaround einbauen, bis in der nächsten Version der Fehler behoben ist.
Sieh das mal aus der umgekehrten Sicht: Der Kunde ist an denjenigen gebunden, der anstatt allgemein verbreiteter, gut dokumentierter, automatisiert getesteter, regelmäßig aktualisierter Bibliotheken eine selbstgebastelte Software einsetzt. Kann oder will derjenige nicht mehr daran arbeiten, so steht der Kunde auf einer 20.000-Euro-Software, die nur eine Person auf der Welt versteht. Einen anderen Entwickler kann er nicht daran setzen; der würde so lange den Code studieren müssen, da könnte er ihn auch gleich neu schreiben.
Es hat schon seinen Grund, warum es große offene und etablierte Softwareprojekte gibt, die von einer Community getragen werden: Sie sollen verhindern, dass jeder seinen eigenen inkompatiblen und (höchstwahrscheinlich) unwartbaren Kram codet. Auf die unberechenbare Situation, solch eine Software weiterentwickeln zu müssen, würden ich mich nicht einlassen und Kunden eher empfehlen, die Software neu entwickeln zu lassen. Und zwar mit einer konventionellen Werkzeugkiste, in die sich jeder JavaScripter auf dem Arbeitsmarkt anhand der Dokumentation in einer paar Tagen einarbeiten kann.
Mathias