Neues Modul das den schönen nivo slider wrapped

[Fabian]

Hallo,

ich habe mal den nivo slider: http://nivo.dev7studios.com/ in ein websitebaker modul gepackt.
Würde mich über Kommentare oder Änderungsvorschläge freuen.

Source ist zu finden unter: https://bitbucket.org/sturm/wb-nivo-slider/overview

Bzw. als modul angehängt an dieses Post.

Viele Grüße
Fabian

[maverik]

Wenn ich die view.php in Zeile 26/27 richtig interpretiere

Code:

// activate jquery
echo '[[jQueryInclude]]';

setzt Dein Modul jQueryAdmin voraus. Das solltest Du dazu schreiben denn nicht jeder verwendet dieses Modul.

[Stefek]

Hallo Fabian
(ich hoffe, nicht der Goldschmied Fabian )

Also sehr schön sauber programmiert.
Und ausbaufähig.

Danke dafür.

Diese Sachen hier:
<script type="text/javascript">
$(window).load(function() {
    $('#slider').nivoSlider({
        effect:'fade',
        animSpeed:500, //Slide transition speed
        pauseTime:4000,
        pauseOnHover:true,
        controlNavThumbs:true
    });
});
</script>
... also die Einstellungen, könnte man gut in eine Extra Einstellungen Seite unterbringen, sodass man nicht die view.php bearbeiten muss.

Nun, ich weiß nicht, was Deine weiteren Pläne damit sind, aber auf jeden Fall ist das eine nette Grundlage für einen Ausbau.
Ich habe vor ein paar Tagen überlegt, etwas ähnliches zu machen, wobei man aber unter Einstellungen des Moduls den Namen eines Ordners im Media Verzeichnis angibt und dann in der modify.php die Bilder als Thumbs angezeigt werden, die man über eine Checkbox auswählen kann.

Wie auch immer... ein sehr netter Beitrag.

Ähnlich wie mein Vorredner würde ich es aber auch gut finden, wenn ein Fallback geben würde, für die, die jQuery nicht verwenden.
So ungefähr könnte man das machen (als Beispiel):

Code:

<?php 
$string = ''
if (/*jQadmin Check*/){
$string .= '[[jQueryInclude]]';
}else{
$string .= "<script type=\"text/javascript\">\n\t"
."if (typeof jQuery == 'undefined'){\n\t\t"
    ."document.write(unescape(\"%3Cscript src='".WB_URL."/include/jquery/jquery-min.js' type='text/javascript'%3E%3C/script%3E\"));\n\t"
    ."}\n\t"
    ."/* ]]> */\n" 
    ."</script>\n";
}
echo $string;

Übrigens, User Ruud hat auch etwas ähnliches als Admin Tool gemacht (mit vielen Einstellungsmöglichkeiten).
Interessant würde das ganze, wenn man auch andere (nicht nur nivoSlider) Slider Plugins verwenden (leicht einbinden) könnte.

Gruß,
Stefek

[maverik]

wenn ein Fallback geben würde, für die, die jQuery nicht verwenden.
So ungefähr könnte man das machen (als Beispiel):

Wenn ich das auch wieder richtig interpretiere laufen hier die Leute wieder vor die Wand die JQA nicht verwenden aber jQuery über register frontend modfiles eingebunden haben. Das sollte auch noch berücksichtigt werden.

Ist jQuery eingebunden?
Wenn ja > ok.
Wenn nein > gibt es JQA? >> nimm den >> ansonsten binde selber ein

Irgendwie so, bin ja kein Coder

[BlackBird]

Scheint mir ein bißchen umständlich zu sein, es als Modul zu machen, wenn Du dann sowieso auf jQueryAdmin zurückgreifst. Aber das ist ja Deine Entscheidung.

Bei dem Fallback auf das jQuery, das WB mitliefert, solltest Du berücksichtigen, daß das eine ältere Version ist. Das solltest Du dann vorher testen.

[maverik]

jQuery, das WB mitliefert, solltest Du berücksichtigen, daß das eine ältere Version ist

Auf der Entwicklerseite wird folgendes angegeben

Code:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js" type="text/javascript"></script>

In der aktuellen SVN vom erscheinenden WB 2.8.2 befindet sich derzeit genau diese Version, sprich 1.4.2. Von daher sehe ich keine Probleme. Bei mir mit jQuery 1.4.4 läuft es auch einwandfrei.

Sofern jQuery über register frontend modfiles eingebunden ist einfach bei der jetzigen Version Zeile 27 in der view.php auskommentieren.

[BlackBird]

Normalerweise arbeiten die Leute aber mit einer Release-Version. Und das ist immer noch 2.8.1 mit jQuery 1.3.

[testör]

Normalerweise arbeiten die Leute aber mit einer Release-Version. Und das ist immer noch 2.8.1 mit jQuery 1.3.

Der Download von WB 2.8.1 hat in /include/jquery/jquery-min.js die Version 1.4.1 und jQuery UI 1.7.2. Die Version 1.3 wird nur so mitgeliefert, aber eigentlich ist sie überflüssig.

[BlackBird]

Schön, daß wir das geklärt haben. Die ist trotzdem älter als 1.4.2. Aber sei's drum, da Fabian sich bereits entschieden hat, auf jQA aufzusetzen, müßte er nur noch eine precheck.php mitliefern, die das entsprechend prüft. Ob er einen Fallback machen will oder nicht, ist ja seine Sache.

[dbs]

Getestet hab ich es nicht, aber aus den Beiträgen geht hervor, dass die erste Version viel besser und einfacher als jQA-Plugin zu realisieren wäre. Sogar die Einstellungen wären komfortabel über das Backend zu bearbeiten.

Eine Modul-Version ist natürlich immer interessant für leute die jQA nicht nutzen.
Eine Version die jQA voraussetzt ist irgendwie am User vorbei.

Ich wäre für eine Modulversion die auf WB-jQuery setzt.
Das Plugin für jQueryAdmin ist später schnell gebastelt.

[BlackBird]

Das Plugin ist schon fertig.

[Fabian]

Hallo!

Erst mal vielen Dank für die vielen Kommentare. Und danke für das Kompliment für den schönen Code. Auch wenn ich glaube das da noch viel zu verbessern ist

Die Dinge die ich bisher aufgeschnappt habe:

1. Mehr Konfigurierbarkeit im Backend.
Das wäre eine schöne Sache. Es sollte so wenig wie möglich hart codiert sein.
Allerdings weiß ich nicht, ob ich zu diesem Punkt in nächster Zeit komme.
Für meine Belange ist das Plugin im Moment ausreichend und da ich noch einiges anderes anpassen muss,
wollte ich mich da nicht weiter aufhalten.

2. jQuery Admin vs. WB jQuery
Zu dem Punkt kann ich wenig sagen. Ich hatte beim Entwickeln selber meine liebe Mühe heraus zu finden wie ich überhaupt jQuery laden kann. Und als es dann ging, hab ich es gelassen.
Am liebsten wäre mir hier auf jeden Fall eine Lösung die sowohl mit dem default WB als auch mit jQuery Admin zusammenarbeitet. Also eine Lösung wie sie Stefek vorgeschlagen hat.
Wäre toll wenn es da von WB Seiten her einen Vorschlag gibt, der dann in beliebige Modulen übernommen werden kann.

3. Andere slider javascripts integrieren
Hmm k.a. ob das eine gute Idee ist. Ich denke einiges von dem Code wie z.b. das frontent.css file
hängen ja stark mit dem verwendeten Plugin zusammen. Da wäre es dann evtl. einfacher ein neues Plugin zu schreiben, als das bestehende so zu verbiegen, dass es mehrere unterstützt.
Würde aber Patches natürlich aufnehmen

Wenn das mit jQuery gelöst ist, dann macht es evtl. Sinn das irgendwo upzuloaden?

Viele Grüße und vielen Dank
Fabian

[Fabian]

Hallo dbs,

Getestet hab ich es nicht, aber aus den Beiträgen geht hervor, dass die erste Version viel besser und einfacher als jQA-Plugin zu realisieren wäre. Sogar die Einstellungen wären komfortabel über das Backend zu bearbeiten.

ich glaube hier ist ein Missverständnis. Das Plugin ist ein "normales" WB Plugin kein jQuery Admin Plugin.
D.h. die Einstellungen sind wie üblich im Backend zu machen und es lässt sich als ein einfacher Abschnitt in beliebigen Seiten inkludieren. Aber es braucht halt irgend woher ein geladenes jQuery. Und da ein [[jQueryInclude]] bei mit gereicht hat, da ich jQueryAdmin eh schon installiert hatte, hab ich es dabei belassen. Alle anderen Versuche davor waren irgendwie nicht so erfolgreich

Viele Grüße
Fabian

[dbs]

du meinst du hast ein modul gemacht und kein jQA-plugin. sonst verwirrts du mich.

du brauchst dir um das laden von jquery keine gedanken machen.
besser noch, du sollst dir keine gedanken machen wie dein modul jquery laden kann.
jquery wird in wb auf zwei arten geladen. entweder oder.
entweder register frontend modfiles im head oder über jqueryadmin.
du kannst also geladenes jquery voraussetzen.

wenn das aber eine standalone-lösung sein soll, dann müsstest du echt abfragen ob jquery geladen wird und zwar ob von wb oder von jqa und falls nicht lädst du es mit deinem modul aus include/jquery. aber wie gesagt, halte ich für überflüssig.

[Stefek]

Hallo Fabian

3. Andere slider javascripts integrieren
Hmm k.a. ob das eine gute Idee ist. Ich denke einiges von dem Code wie z.b. das frontent.css file
hängen ja stark mit dem verwendeten Plugin zusammen.

Ja, Du hast recht.
Leider gibt es (noch) keine vernünftige Methode in WB, von "irgendwo in irgendeinem Modul oder sonstwo" eine CSS Datei anzugeben, die in den Head geschrieben wird.
Das versuche ich anzuregen und ich glaube auch, dass die Devs da in diese Richtung auch schon gedacht haben, nur dass die im Moment eben an anderen "Baustellen" dran sind.

Im Falle Deines Modules gäbe es dann nämlich mehrere Möglichkeiten, CSS Files "on demand" zu integireren (und zwar im HEAD, wo sie hingehören).
Ob als kleine Plugins, die dann sowohl die HTML Struktur (Template) als auch die benötigten CSS/JS Files mitliefern, oder als "einfache Variante" einen Ordner im Medienverzeichnis dafür vorzusehen.

Ich bin ziemlich sicher, dass es irgendwann mal einfacher sein wird, diese Sachen zu machen.

Tob Dich erstmal aus an dem, was Du da machst.
Ich habe hier grade ein Projekt, für das ich auch einen Slider brauchen werde - vielleicht entsteht da im Verlauf meines Projekts etwas, das man dann mit Deinem Page-Modul kombinieren könnte.
(Meins geht mehr in die Richtung wie in meinem vorigen Post angedacht, doch auch hier fehlt mir einfach die Möglichkeit, es mit Plugins aufzustocken - das geht erst dann vernünftig, wenn man selbst entscheiden kann, welche Dateien in den Kopf geschrieben werden sollen, statt nur auf die frontend.css.)

Übrigens, dass frontend.css Konzept ist noch aus Zeiten, wo jQuery und die "Not" mehrere CSS Files einzubinden noch nicht so präsent war.

jQuery läßt sich einfach über JS nachladen.
CSS zwar auch, aber das ist eine etwas zu untragbare Methode.

Gruß,
Stefek

[BlackBird]

Leider gibt es (noch) keine vernünftige Methode in WB, von "irgendwo in irgendeinem Modul oder sonstwo" eine CSS Datei anzugeben, die in den Head geschrieben wird.

Doch, die gibt es.

[Stefek]

Leider gibt es (noch) keine vernünftige Methode in WB, von "irgendwo in irgendeinem Modul oder sonstwo" eine CSS Datei anzugeben, die in den Head geschrieben wird.

Doch, die gibt es.

Ja, mit Simple_HTML_DOM - stellt eine ganze Klasse zur Verfügung (und istim OpF schon seit langem drine.)
Mit " in WB " ist aber nicht " an WB " gemeint.

Stefek

[BlackBird]

Wäre nicht der erste Workaround, der zum Standard wird. (Wie die register_*() Funktionen.) Und besser ein guter, funktionierender Workaround als gar keine Lösung.

Ich meinte natürlich JQA bzw. LA, aber ich denke, das weißt Du auch so.

[Stefek]

jQadmin und der andere Bolide sind in Einfachheit einer einfachen Methode, die das handlet nicht gewachsen.

Wie ich schon an anderer Stelle ausführte, jQa ist nicht wirklich gut.
Schau Dir den HEAD Teil der Seiten von Leuten, die mit jQa Wildwuchs praktizieren, dann weißt auch Du, was ich meine.

Aber wie dem auch sei, jedem sein Päckchen...

Stefek

[BlackBird]

Das ist ja nur _Deine_ Meinung, und die sei Dir vergönnt. Da Du Deine Vorbehalte nie wirklich fundiert begründen konntest, gibt es dazu auch nichts weiter zu sagen. Du brauchst es ja nicht einsetzen. Du solltest vielleicht ignorieren lernen.

[Stefek]

Da Du Deine Vorbehalte nie wirklich fundiert begründen konntest...

Es gibt nichts, das "fundiert" begründet werden müßte.
Es reich ein Blick in den Output, also das, was nach dem Rendern der Seite im Browser ankommt.
Speziell im HEAD Bereich der Seite.

Ich sage nicht, dass jQadmin und sein Nachkömmling schlecht programmiert sind.
Vieles davon ist sehr brauchbar. Die Idee, ganze Plugins samt CSS, Images und der übrigen Dateien hochladen zu können ist sogar sehr gut (wenn auch nicht neu).

Aber Du wirst Dir eingestehen, wenn Du ehrlich bist, dass die von mir oben angesprochene Methode für WB sinvoll ist.

Du musst es nicht persönlich nehmen.
Ignorieren ist weit aus kritischer, als man annimmt.

Stefek

[BlackBird]

Es reich ein Blick in den Output, also das, was nach dem Rendern der Seite im Browser ankommt.
Speziell im HEAD Bereich der Seite.

Vielleicht willst Du mir ja mal per PN mitteilen, was Du damit meinst, denn ich verstehe nicht, was daran schlecht sein soll. Im Gegenteil - JQA räumt den HEAD auf und verschiebt sogar ungültiges CSS aus dem Body in den Header. Aber ich möchte diesen Thread nicht weiter zweckentfremden. Ich bin für konstruktive Vorschläge immer zu haben, aber für ein lapidares "das Ding ist schlecht" ohne wirkliche Begründung habe ich nichts übrig.

[mr-fan]

Aber Du wirst Dir eingestehen, wenn Du ehrlich bist, dass die von mir oben angesprochene Methode für WB sinvoll ist.
Du musst es nicht persönlich nehmen.
Ignorieren ist weit aus kritischer, als man annimmt.

also zum Großteil liegt der "Head" Wildwuchs an den Benutzern von JQA weil es halt so einfach ist da ein Häckchen dort eins dann hab ich noch das plugin drin und dies und jenes....

andererseits sind manche Dinge in den Plugins sehr umständlich bzw. erhöhen die Fehlerquote (loader.preset mit den Einstellungen für DAUS erzeugen immer ein wenig Overhead, andere technische Dinge um solchen zu vermeiden sind damals ein wenig untergegangen - wollte da von Anfang an beim testen das JS und CSS nur geladen wird wenn bestimmte (einstellbare) Faktoren performant per PHP gefunden werden...(z.B. rel="fancybox" id="tolleclasse" class"toTop") und sonst nicht...das ist während der Entwicklung zugunsten anderer features hinten geblieben, aber nicht so tragisch....soviel PHP kann ich um selektiv automatisch die Plugins zu laden....

Für module die eh selektiv Plugins laden bzw. brauchen ist es geeignet. und für Templates sowieso.....besonde rs LibraryAdmin hab ich schon mal im Test und dort geht das mit CSS und JS man kann sich seine eigenen Codesnippets was HTML, CSS und JS angeht...

mfg martin

[BlackBird]

... andere technische Dinge um solchen zu vermeiden sind damals ein wenig untergegangen - wollte da von Anfang an beim testen das JS und CSS nur geladen wird wenn bestimmte (einstellbare) Faktoren performant per PHP gefunden werden...(z.B. rel="fancybox" id="tolleclasse" class"toTop") und sonst nicht...das ist während der Entwicklung zugunsten anderer features hinten geblieben, aber nicht so tragisch....

Das ist nicht ganz richtig. Da die Plugins in der Regel extrem flexibel sind - man die Effekte z. B. an eine beliebige CSS-Klasse oder ID oder whatever binden kann -, kann man auf diese Weise nicht sicherstellen, daß wirklich alles geladen wird, was gerade gebraucht wird. Das mag für den sogenannten DAU klappen, weil der sich meist mit den vorhandenen Bindings zufrieden gibt, aber sobald einer anfängt, das Zeug an andere Elemente zu binden, wird es zu fehleranfällig und unflexibel.

Aber wir sollten das wirklich nicht weiter hier diskutieren. Dafür gibt's ein eigenes Forum.

[Stefek]

... andere technische Dinge um solchen zu vermeiden sind damals ein wenig untergegangen - wollte da von Anfang an beim testen das JS und CSS nur geladen wird wenn bestimmte (einstellbare) Faktoren performant per PHP gefunden werden...(z.B. rel="fancybox" id="tolleclasse" class"toTop") und sonst nicht...das ist während der Entwicklung zugunsten anderer features hinten geblieben, aber nicht so tragisch....

Das ist nicht ganz richtig. Da die Plugins in der Regel extrem flexibel sind - man die Effekte z. B. an eine beliebige CSS-Klasse oder ID oder whatever binden kann -, kann man auf diese Weise nicht sicherstellen, daß wirklich alles geladen wird, was gerade gebraucht wird. Das mag für den sogenannten DAU klappen, weil der sich meist mit den vorhandenen Bindings zufrieden gibt, aber sobald einer anfängt, das Zeug an andere Elemente zu binden, wird es zu fehleranfällig und unflexibel.

Aber wir sollten das wirklich nicht weiter hier diskutieren. Dafür gibt's ein eigenes Forum.

Na, dann schön, dass Du es mal zugibst.

Wie ich oben schon sagte, es gibt Aspekte vom jQadmin, die tatsächlich sinnvoll sind.

Das was Martin oben beschreibt (danke für die Stellungnahme eines tatsächlichen Benutzers) wurde vor langer Zeit, auf meinen Wunsch hin bereits vom User Aldus gemacht. Er hat ein Snippet namens "xfindclass" (oder so ähnlich) geschrieben.
Die gleiche Idee (ob zufällig oder darauf aufbauend - das weiß ich nicht) wurde dann vom User Thorn in den OpF Admin integriert. Hier kann man beliebig Files nachladen, aber wie das da genau geht, will ich jetzt nicht weiter erörtern.
Worum es mir geht, ist einfach mal zur Sprache zu bringen, dass ich mir solche Dinge nicht "nur oberflächlich" anschaue, um dann eine "lapidare Aussage" dazu zu äußern.
Nein, mir geht es um eine Methode, die tut was man erwartet.
Ich weiß, dass die Lösung nicht einfach ist.
Die Probleme werden ja erst durch die Verwendung aufgeworfen und diese Problemstellung braucht eines vernünftigen Kompromisses, der auch auf Core-Basis funktioniert.

Mit dem OpF Dashboard klappt es wunderbar, gestaltet sich aber schwerer, wenn man Module damit "kreuzen" will, da hier, genau so wie beim jQadmin (wie auch jedem anderen Tool ähnlicher Zielsetzung) die Verbreitung eine Rolle spielt.
Anders als beim Core, wird es immer mal Leute geben, die das Tool nicht an Board haben.

Wenn Du (Bianka) wirklich an einer vernünftigen Lösung interessiert bist, dann kannst Du Dich an mich wenden.
Es gibt sicher Wege, etwas dem Coreteam zu unterbreiten, das zumindest nach einem guten Ansatz aussieht.

Ich könnte mir vorstellen, dass jQadmin (oder sein Nachfolger) viel praktischer wäre, wenn man zukünftig (so ab Version 2.9.0) ohne diese Droplets Jonglage (ist das ein Wort?) auskommt.
Die zusammengetragenen Ideen und Ausarbeitungen (können ja grobe Konzepte sein), sollten allerdings nicht nur auf jQueryAdmin ausgerichtet sein.

Gruß,
Stefek