• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

[jquery] Drop-Verhalten bei "Droppable" mit ungewünschtem Effekt

Rhinhold

Jerseymac
Registriert
01.03.05
Beiträge
452
Hallo allerseits,

wie ich hier schon mal erläutert hatte, soll ich für unser Institut einen Bachelor-Semesterplan für unsere Webpräsenz erstellen.

Nun bin ich mittlerweile - nach vielen Unterbrechungen, Zwangspausen, Konzeptionsphasen, usw. - relativ weit gediegen damit.

Den aktuellen Stand findet ihr hier: Bachelor-Semesterplan!
Bitte nicht am Design mäkeln, das ist alles noch absolute Rohkost. ;)

Zum Problem:


Ich habe für das Verschieben, Platzieren und Sortieren die jquery-eigenen UI-Komponenten "draggable", "droppable" und "sortable" verwendet. Nun hänge ich sozusagen am Übergang von "Droppable" zu "Sortable" - nämlich bei den dropzones (also den Semestern).

Konkret:
Wenn Ihr mal die Module verschiebt, die bereits im 1. Semester platziert sind, werdet Ihr merken, dass hier lediglich die "Sortable"-Komponente arbeitet - und zwar wie gewünscht. Platziert Ihr aber mal zum Test verschiedene Module im 2. Semester und wollt diese anschließend ebenfalls sortieren, so werdet Ihr merken, dass hier einige Dropzones "aufleuchten" - also ihre "accept"-Eigenschaft kund tun. Wirklich dorthin verschieben könnt Ihr Module dort hin aber nicht, da ich beim Ablegen die "Draggable"-Komponente kille (Aufgrund der vielen Abhängigkeiten unter den Modulen, möchte ich das nachträgliche Verschieben verbieten, stattdessen offeriere ich nur ein Trash-Icon, mit dem das Modul wieder gelöscht werden kann.).


Mein Wunsch:


Weg mit der "accept"-Eigenschaft, sobald die Module mal platziert sind!

Nicht nur, dass das unschön aussieht und es durchaus auch immer wieder mal zu kleineren Problemen führen kann, weil man die Module immer noch zu anderen Dropzones ziehen kann (und von dort evt. Skriptbefehle aufgesaugt werden).
Das Hauptproblem: Es suggeriert dem Nutzer, er könne das Modul tatsächlich verschieben - was er aber ja faktisch nicht kann (und auch nicht können soll!)!


Der Code:


Da ich ja mit vielen Dropzones und noch viel mehr draggables arbeiten muss, habe ich den Weg gewählt, den Dropzones unter "accept" zwei CSS-Klassen zuzuweisen. Das sieht dann z.B. für das 1.Semester so aus:

Code:
$(".container ul#sem1").droppable({
	[COLOR="RoyalBlue"]accept[/COLOR]:[COLOR="SeaGreen"] '.toSem1, .toAll'[/COLOR],
	activeClass: 'drop-accept',
	hoverClass: 'drop-active',
	tolerance: 'intersect',
	drop: function(event, ui) {
	        ...
	}
});

Die Klasse ".toAll" besitzen alle Semester, da es einige Module gibt, die nicht an bestimmte Semeter gebunden sind. Andere jedoch bekommen im HTML-Code z.B. die CSS-Folge "toSem1 toSem2 toSem5" zugewiesen - somit sind sie nur mit dem 1., 2. und 5. Semster verlinkt.



Mein erster Lösungsversuch:


Ich dachte mir, ich könnte das einfach alles umgehen, in dem ich beim Ablegen der Module nicht nur die "Draggable"-Komponente kille, sondern auch die CSS-Klassen "toSem1, toSem2, ..." .

Aber dem war leider nicht so. Die Folge: Zwar leuchten nun die dropzones nicht mehr auf beim erneuten Anfassen - das liegt aber nur daran, dass sie gar nicht erst damit aufhören. Klingt komisch, ist aber so. ;)

Soll heißen: Möchte ich ein Modul in ein Semester platzieren, so leuchten erst einmal - korrekterweise - alle dropzones mit der passenden "accept"-Eigenschaft auf. Lasse ich dann das Modul in eines der Semester fallen, so leuchten die anderen dropzones aber weiter und kehren nicht wieder zu ihrer alten CSS-Formatierung (also -Klasse) zurück. :mad:


Wo ist also die Lösung?


Somit sehe ich zwei Ansatzmöglichkeiten für eine evt. Lösung:
a) Erzwingen der CSS-Formatierung, nachdem das Modul platziert wurde (wie/wo auch immer)
b) Individuelles Killen der "accept"-Eigenschaft (wie/wo auch immer)


Habt Ihr vielleicht eine Idee? Vielleicht stehe ich auch einfach nur auf dem Schlauch und sehe den Wald vor lauter Bäumen nicht... o_O

Schönen Dank schonmal im Voraus für Ideen!

Schöne Grüße
Rhinhold
 

MasterofDistres

Kleiner Weinapfel
Registriert
07.12.06
Beiträge
1.139
Wollte mir gerade mal die Seite anschauen, aber Safari gibt 60 Javascript Fehler aus - bist du gerade dran am Arbeiten? ;) Weil die ganzen Drag-Funktionien funktionieren nicht ;)
 

Rhinhold

Jerseymac
Registriert
01.03.05
Beiträge
452
*staun* Tatsächlich! Bei mir verweigert Safari auch seinen Dienst. Dagegen haben Firefox und auch Opera keine Probleme damit. Oh weh, was denn nun schon wieder??

Hast du vllt. eine Browseralternative für den Moment?
 

Rhinhold

Jerseymac
Registriert
01.03.05
Beiträge
452
-- Problem (selbst) gelöst!

Für den Fall, dass noch jemand das gleiche Problem plagt, hier mein Lösungsweg:

Verhindern kann man die accept-Eigenschaft einfach über den Umweg, dass man die CSS-Klassen, die von den Dropzones akzeptiert werden, verändert (z.B. über SwitchClass). Ich schreibe also einfach in die drop-Funktion der Dropzones die Funktion rein, wonach beim Ablegen alle entsprechenden CSS-Klassen umbenannt werden (z.B. "toSem2" in "toSem2false") - schon interessieren sich die anderen Dropzones nicht mehr dafür. Beim Zurücksetzen wird der Vorgang dann einfach wieder rückgängig gemacht.

Ein Folge-Problem, dass dadurch aber entsteht, ist folgendes:

Wird ein Draggable-Element von gleich mehreren Dropzones akzeptiert (und diese tun das durch ihre ".drop-accept"-CSS-Klasse kund), dann kann es passieren, dass nach dem Ablegen (und dem Verändern der "accept"-CSS-Klassen; s.o.) einige der anderen Dropzones weiterhin "leuchten"; obwohl das Element bereits platziert ist. Die CSS-Klasse ".drop-accept" wird in diesem Fall in den Dropzones einfach nicht wieder gelöscht. Das habe ich gelöst, indem ich einfach zu der obigen Funktion hinzugefügt habe, dass alle ".drop-accept"-Klassen in allen Dropzones gelöscht werden sollen (über "removeClass("drop-accept")").

P.S.: Warum auch immer: Safari verweigert nun nicht mehr den Dienst! ;)