message box

[vasilisbilias]

Δεν το ξέρω το plugin, αλλά (wild guess) δες μήπως στο css του έχει σεταρισμένο overflow:hidden; στην περιοχή που εμφανίζεται το μήνυμα. Αν ναι, δοκίμασε να το αλλάξεις είτε σε overflow:auto; είτε σε overflow:scroll;

Δεν βρήκα κάτι... Λογικά με jquery θα είναι.

[geomagas]

Συνιστώμενος από το codex του Wordpress εννοούσα, δηλαδή το επίσημο API του Wordpress.

 

Δεν το αμφισβητώ, αλλά προσωπικά το έχω συναντήσει σε άρθρα που εξηγούν πως να κάνεις πράγματα. Όλοι το θεωρούν δεδομένο ότι θα προσθέσεις τον κώδικα που σου προτείνουν "στο functions.php", πράγμα το οποίο δεν το χώνεψα ποτέ.

Θεωρώ πάντως ότι αυτός ο ισχυρισμός θέλει και το link του προς την πηγή. Ξαναλέω, όχι επειδή έχω λόγο να το αμφισβητήσω.

 

Και με το child-theme το ίδιο πράγμα ισχύει. Όταν αλλάξεις theme το child-theme σου θα είναι πάντα εκεί, το μόνο που χρειάζεται να κάνεις είναι να αλλάξεις 2 γραμμές στο style.css του child-theme σου (δηλαδή τις Template και @import). Προαιρετικά αλλάζεις και 2 ακόμα για να είναι πιο σαφής η περιγραφή του child-theme στο back-end όταν το διαλέγεις (δλδ τις Theme Name και Description) .

 

Ακόμα καλύτερα, μπορείς να αλλάξεις μόνο μία, αν έχεις δώσει ένα όνομα που δεν εξαρτάται από το (πρώην) parent. Αλλά δεν είναι αυτό το θέμα.

Τυπικά, αν και αυτό δεν είναι κανείς αναγκασμένος να το ακολουθήσει, ένα child theme "ανήκει" στο parent του. Άρα, αν αλλάξεις theme, τυπικά θα πρέπει να φτιάξεις ένα νέο child, και όχι να αλλάξεις το παλιό. Αντίθετα, τα plugins δεν έχουν parent. Είναι αυτόνομες οντότητες.

 

Από την άλλη μεριά, τα plugins δεν θα έπρεπε να αλλάζουν το παρουσιαστικό ενός site, αλλά το δικό σου το κάνει (φορτώνεις κεντρικό css μέσα από plugin). Αυτό ταιριάζει καλύτερα στις αρμοδιότητες ενός theme παρά ενός plugin.

Αυτό δεν ισχύει. Αν και το theme είναι σαφώς προσανατολισμένο στην εμφάνιση, δεν βλέπω κανένα λόγο να μην αφήσεις ένα plugin να αλλάξει το παρουσιαστικό. Τα plugins είναι από τη φύση τους πιο γενικά.

 

Από τη στιγμή που χρησιμοποιούμε το όποιο cms, θεωρώ πως είναι αυτονόητα πιο ασφαλές να ακολουθούμε το API του για πράγματα που ήδη προβλέπονται και είναι και τεκμηριώμένα. Με αυτό το τελευταίο εννοώ πως εφόσον ο όρος "theme" στο wordpress εμπεριέχει και το παρουσιαστικό και τη λειτουργικότητα του site διότι έτσι είναι κατασκευασμένο να λειτουργεί, δεν νομίζω πως υπάρχει κάποιος σημαντικός λόγος να το αρνηθούμε και να εφεύρουμε δικιά μας μεθοδολογία (η οποία στην καλύτερη των περιπτώσεων θα είναι ελάχιστα δοκιμασμένη συγκριτικά με την επίσημη).

Καμία σχέση με την ασφάλεια... Όσο ασφαλές είναι το ένα, άλλο τόσο είναι και το άλλο. Άσε που, και τα δύο χρησιμοποιούν ακριβώς το ίδιο api, πλην μεμονωμένων εξαιρέσεων (πχ activation hooks).

Και ο ισχυρισμός ότι το theme στο WordPress εμπεριέχει και παρουσιαστικό και λειτουργικότητα είναι μία παρεξήγηση που γεννήθηκε και συντηρήθηκε επειδή ακριβώς συμβαίνει η παραπάνω σύγχυση.

 

Το ιδανικό θα ήταν να περιορίζονταν τα themes στο css και μόνο. Άντε και σε ένα framework που να υποστηρίζει μία markdown γλώσσα για να παράγει html σε πιο αφαιρετικό επίπεδο (να ορίζει πχ περιοχές μενού, widget zones, microdata κ.α.) και ένας μηχανισμός του πυρήνα να τα μετέφραζε σε html ίσως και με τη βοήθεια κάποιων plugins. Εγώ έτσι θα έφτιαχνα ένα cms (σε μία άλλη ζωή ίσως...)

 

Προφανώς ο καθένας είναι ελεύθερος να γράφει τον κώδικά του όπως επιθυμεί, απλώς με αυτά τα 2 ποστς μου ήθελα να επισημάνω τι θεωρείται καλή πρακτική σύμφωνα με το wordpress codex, στον συγκεκριμένο τομέα.

 

Να, γι' αυτό ήθελα το link παραπάνω. Θέλω να δω σε ποιο σημείο το codex ισχυρίζεται ότι το να φτιάξεις ένα child theme είναι καλύτερη πρακτική από το να βάλεις τον κώδικά σου σε ένα plugin.

Όχι οτι πρόκειται να συμφωνήσω όμως μαζί τους κιόλας!

[migf1]

@vasilisbilias:

 

Μόλις κατέβασα το plugin και το δοκίμασα. Παρατήρησα πως από μαμά μεγαλώνει αυτόματα το ύψος της περιοχής του μηνύματος, ανάλογα με το κείμενο του μηνύματος. Υποθέτω πως αυτό που θέλεις να κάνεις είναι να φιξάρεις το ύψος της φόρμας, καθώς και της περιοχής με το μήνυμα, και να προσθέσεις scrollbar στην περιοχή του μηνύματος.

 

Αν ναι, δοκίμασε να προσθέσεις στο css αρχείο του plugin το παρακάτω:

div#cookiewarning div#back div p{
	height: 15em;
}

καθώς και να αλλάξεις το height:auto του div#cookiewarning div#back div{...} από auto σε π.χ.23em.

 

Τα 15em και 23em είναι απλώς παραδείγματα. Βάλε ότι σε βολεύει καλύτερα.

 

@geomagas:

 

To link είναι αυτό που έδωσα στο αρχικό μου ποστ για τα child-themes. Από την 1η κιόλας παράγραφο αναγράφει...

 

A child theme is the safest and easiest way to modify an existing theme, whether you want to make a few tiny changes or extensive changes. Instead of modifying the theme files directly, you can create a child theme and override within.

Σχετικά με την ασφάλεια, δεν εννοούσα security issues, αλλά τη γενικότερη ασφάλεια (δλδ την λιγότερη ανασφάλεια) που αποπνέει η επίσημα συνιστώμενη πεπατημένη ασ πούμε π.χ. στο ότι θα εξακολουθεί να δουλεύει ας intended σε μεταγενέστερες εκδόσεις του wp, αφού αποτελεί την επίσημα τεκμηριωμένη καλή πρακτική.

 

Πάντως όπως έγραψα και πριν, ο καθένας μπορεί να γράφει τον κώδικά του όπως επιθυμεί. Δηλαδή δεν θα χαλάσει και ο κόσμος να γραφεί κώδικας σε plugin αντί σε child-theme, αρκεί να έχει υπόψη του πως τα plugins φορτώνονται πριν από το theme, το οποίο με τη σειρά του φορτώνεται πριν από το child-theme.

 

Ανάλογα το τι θέλουμε να κάνουμε, αυτή η σειρά φορτώματος προϋποθέτει ειδική μέριμνα αν ο κώδικας είναι γραμμένος σε plugin (π.χ. να κάνεις hook μια custom συνάρτησή ως 'after_setup_theme' αν όντως εξαρτάται από κάποια theme initializations). Στο functions.php του child-theme είσαι σίγουρος πως τα πάντα έχουν ήδη φορτωθεί, οπότε έχεις λιγότερους μπελάδες στο κεφάλι σου.

EDIT: Τα διαγραμμένα δεν ισχύουν (επηρεάστηκα από το Theme Blvd framework που το είχα πρόσφατο στο μυαλό μου... περισσότερα εδώ: http://www.insomnia.gr/topic/518846-message-box/page-2?do=findComment&comment=52998636)

 

Σχετικά με το κεντρικό css, θα επιμείνω πως αρμόζει καλύτερα στις αρμοδιότητες ενός theme παρά ενός plugin. Σε αντίθεση π.χ. με μια φόρμα, που ταιριάζει μάλλον καλύτερα να γίνει plugin με shortcode αντί για page-template στο child-theme (αν κι αν το καλοσκεφτούμε κι αυτό ελέγχεται, γιατί τα page-templates μπορούν κάλλιστα να γραφούν ως theme-agnostic μέσα στο child-theme.) Το κεντρικό css σε child-them υπάγεται στην καλή πρακτική που συνιστά η wordpress. Το παράδειγμα με τη φόρμα είναι καθαρά προσωπική προτίμηση του καθενός.

 

ΥΓ. Το concept του theme στο wordpress αντιστοχεί περισσότερο σε framework παρά σε σκέτη εμφάνιση. Ενδεχομένως να είναι ατυχής ο όρος "theme", σίγουρα όμως conceptually αντιστοιχεί περισσότερο σε framework (δλδ εμφάνιση + λειτουργικότητα). Και πάλι από το wordpress codex περί themes:

 

WordPress Themes are files that work together to create the design and functionality of a WordPress site.

Επεξ/σία 20 Φεβρουαρίου 2014 από migf1

[geomagas]

@geomagas:

 

To link είναι αυτό που έδωσα στο αρχικό μου ποστ για τα child-themes. Από την 1η κιόλας παράγραφο αναγράφει...

 

"A child theme is the safest and easiest way to modify an existing theme, whether you want to make a few tiny changes or extensive changes. Instead of modifying the theme files directly, you can create a child theme and override within."

Ναι οκ, αλλά εγώ δεν ρώτησα αυτό. Εγώ ρώτησα που αναφέρεται ότι είναι καλύτερη πρακτική από τη δημιουργία plugin. Δεν είδα επιχειρήματα πουθενά.

Ως προς το "safest and easiest" το μεν easiest είναι εντελώς υποκειμενικό, το δε safest είμαι βέβαιος ότι αναφέρεται σε αντίθεση με το να "πειράζεις" το ίδιο το theme, και όχι σε αντίθεση με το να φτιάχνεις ένα plugin (άλλωσστε το λέει παρακάτω). Αλλιώς θα πρέπει να μας πει για ποιο λόγο το τελευταίο είναι not-so-safe (και δεν υπάρχει κανένας, στο εγγυώμαι!)

 

Σχετικά με την ασφάλεια, δεν εννοούσα security issues, αλλά τη γενικότερη ασφάλεια (δλδ την λιγότερη ανασφάλεια) που αποπνέει η επίσημα συνιστώμενη πεπατημένη ασ πούμε π.χ. στο ότι θα εξακολουθεί να δουλεύει ας intended σε μεταγενέστερες εκδόσεις του wp, αφού αποτελεί την επίσημα τεκμηριωμένη καλή πρακτική.

Μα κι εγώ αυτό εννοούσα. Επικαλείσαι μία επίσημα συνιστώμενη και μάλιστα τεκμηριωμένη καλή πρακτική, που όμως δεν έχω πειστεί ότι αναφέρεται κάπου, πόσο μάλλον να τεκμηριώνεται.

Δεν καταλαβαίνω λοιπόν το φόβο ότι "κάτι θα αλλάξει" και δεν θα είναι "as intended".

 

Πάντως όπως έγραψα και πριν, ο καθένας μπορεί να γράφει τον κώδικά του όπως επιθυμεί. Δηλαδή δεν θα χαλάσει και ο κόσμος να γραφεί κώδικας σε plugin αντί σε child-theme, αρκεί να έχει υπόψη του πως τα plugins φορτώνονται πριν από το theme, το οποίο με τη σειρά του φορτώνεται πριν από το child-theme.

Ε αυτό έλειπε να χαλούσε κι ο κόσμος!

Πάντως, δεν είναι έτσι ακριβώς. Τα plugins τρέχουν πρώτα, μετά το functions.php του child, μετά αυτό του parent. Μόνο το child css συμπεριλαμβάνεται μετά από το parent (αλλιώς δεν θα μπορούσε να υπερισχύσει!).

 

Ανάλογα το τι θέλουμε να κάνουμε, αυτή η σειρά φορτώματος προϋποθέτει ειδική μέριμνα αν ο κώδικας είναι γραμμένος σε plugin (π.χ. να κάνεις hook μια custom συνάρτησή ως 'after_setup_theme' αν όντως εξαρτάται από κάποια theme initializations). Στο functions.php του child-theme είσαι σίγουρος πως τα πάντα έχουν ήδη φορτωθεί, οπότε έχεις λιγότερους μπελάδες στο κεφάλι σου.

Καμία ειδική μέριμνα δεν χρειάζεται και κανένα επιπλέον μπελά δεν έχεις στο κεφάλι σου. Αν εννοείς κάτι που δεν καταλαβαίνω, ένα καλό παράδειγμα θα μου ήταν χρήσιμο.

 

Σχετικά με το κεντρικό css, θα επιμείνω πως αρμόζει καλύτερα στις αρμοδιότητες ενός theme παρά ενός plugin. Σε αντίθεση π.χ. με μια φόρμα, που ταιριάζει μάλλον καλύτερα να γίνει plugin με shortcode αντί για page-template στο child-theme (αν κι αν το καλοσκεφτούμε κι αυτό ελέγχεται, γιατί τα page-templates μπορούν κάλλιστα να γραφούν ως theme-agnostic μέσα στο child-theme.) Το κεντρικό css σε child-them υπάγεται στην καλή πρακτική που συνιστά η wordpress. Το παράδειγμα με τη φόρμα είναι καθαρά προσωπική προτίμηση του καθενός.

Υπάρχει "κεντρικό" και "μη κεντρικό" css; Διότι, τον όρο τον ανέφερες εσύ.

Και τελικά όλα είναι προσωπική προτίμηση του καθενός, και shortcodes μπορείς να βάλεις σε theme, και template να ορίσεις σε plugin, και ότι hook θέλεις μπορείς να "παγιδεύσεις" και στα δύο (εκτός από αυτά που έχουν ήδη εκτελεστεί ώσπου να φορτωθεί το theme )... μην τα ξαναλέμε.

Το θέμα είναι πως διατηρείς τον κώδικά σου πιο συμμαζεμένο και διαχειρίσιμο.

Και κατά πόσον ισχύουν αυτά που διαβάζει κανείς πέρα δώθε (συμπεριλαμβανομένου και του codex) και πως τα μεταφράζει και τα αξιολογεί.

 

ΥΓ. Το concept του theme στο wordpress αντιστοχεί περισσότερο σε framework παρά σε σκέτη εμφάνιση. Ενδεχομένως να είναι ατυχής ο όρος "theme", σίγουρα όμως conceptually αντιστοιχεί περισσότερο σε framework (δλδ εμφάνιση + λειτουργικότητα). Και πάλι από το wordpress codex περί themes:

 

"WordPress Themes are files that work together to create the design and functionality of a WordPress site."

 

Είδες τι εννοώ; Κάτι τέτοια πάνε και λένε, και μετά ο άλλος πάει και φτιάχνει theme που παρέχει 30 shortcodes, favicon, social icons, google analytics, seo, και bonus έτοιμο "product" custom post type!

Επειδή του είπε το codex ότι έχει δικαίωμα να προσθέσει "functionality" και αυτός το θεώρησε ότι του μιλούν για best practices!!!

 

Έλεος!

[migf1]

Χεχε, τα έχεις πάρει ρε συ; Χαλαροί είμαστε πιστεύω

 

Το codex αποτελεί την επίσημη τεκμηρίωση του wordpress (ελπίζω να συμφωνείς) οπότε ότι συνιστάται εκεί το θεωρώ αυτονόητο πως αποτελεί την επίσημη καλή πρακτική.

 

Κοίτα, δεν θέλω να το κουράσουμε με σεντόνια επί σεντονίων (δεν υπάρχει και λόγος άλλωστε νομίζω)... σε αυτό που γράφεις για τα υπερφορτωμένα themes σε νιώθω σε αρκετά σημεία, απλώς εγώ είμαι πιο ελαστικός γιατί έχω αντιστοιχήσει εξαρχής την έννοια του theme ως framework. Ο συγκεκριμένος τρόπος λειτουργίας του WP είναι ευλογία και κατάρα μαζί (όσο μεγαλώνει το site τόσο περισσότερο custom κώδικα πρέπει να γράψει κανείς).

 

Για το functions.php του child-theme έχεις δίκιο, όντως φορτώνεται πριν από το theme. Επηρεάστηκα από ένα πρόσφατο project με το Theme Blvd framework, όπου μπορείς να κάνεις require_once() το .php του framework μέσα στο functions.php του child-theme, οπότε από εκεί και πέρα δεν χρειάζεται το 'after_setup_theme' στα hooks.

 

Sorry about that!

[geomagas]

Χεχε, τα έχεις πάρει ρε συ; Χαλαροί είμαστε πιστεύω

Όχι εντάξει, δεν τα έχω "πάρει"... Με άλλα πράγματα τα παίρνω, εδώ συζήτηση κάνουμε.

 

Το codex αποτελεί την επίσημη τεκμηρίωση του wordpress (ελπίζω να συμφωνείς) οπότε ότι συνιστάται εκεί το θεωρώ αυτονόητο πως αποτελεί την επίσημη καλή πρακτική.

Ναι συμφωνώ ότι αποτελεί την επίσημη τεκμηρίωση. Μία τεκμηρίωση όμως είναι μία καταγραφή λειτουργιών. Δεν μπορεί να προτείνει τίποτα...

Αν συμπεριλάμβανε μόνο την τεκμηρίωση του API (συναρτήσεις, πως συντάσσονται και τι κάνουν) θα ήμουν πιο ευτυχισμένος. Επειδή ακριβώς είναι κάτι "επίσημο", δεν είναι σωστό να περιλαμβάνει απόψεις και κατευθύνσεις, διότι είναι πολύ πιο εύκολο να σε προκαταλάβει.

 

Αν υπήρχε μία (εξίσου επίσημη) σελίδα με best practices, θα μπορούσα να το δεχτώ. Αν και πάλι, δεν θα μπορούσα να καταλάβω το λόγο ύπαρξης της... Αλλά δεν υπάρχει. Όπως ας πούμε υπάρχουν τα coding standards

 

Για το functions.php του child-theme έχεις δίκιο, όντως φορτώνεται πριν από το theme. Επηρεάστηκα από ένα πρόσφατο project με το Theme Blvd framework, όπου μπορείς να κάνεις require_once() το .php του framework μέσα στο functions.php του child-theme, οπότε από εκεί και πέρα δεν χρειάζεται το 'after_setup_theme' στα hooks.

 

Sorry about that!

 

Ντάξει, δεν είναι σημαντικό... Απλά έπρεπε να το αποκαταστήσω για κάποιον που θα κουτουλούσε το thread...

[vasilisbilias]

@vasilisbilias:

 

Μόλις κατέβασα το plugin και το δοκίμασα. Παρατήρησα πως από μαμά μεγαλώνει αυτόματα το ύψος της περιοχής του μηνύματος, ανάλογα με το κείμενο του μηνύματος. Υποθέτω πως αυτό που θέλεις να κάνεις είναι να φιξάρεις το ύψος της φόρμας, καθώς και της περιοχής με το μήνυμα, και να προσθέσεις scrollbar στην περιοχή του μηνύματος.

 

Αν ναι, δοκίμασε να προσθέσεις στο css αρχείο του plugin το παρακάτω:

div#cookiewarning div#back div p{
	height: 15em;
}

 

Θέλω κάτι εντελώς διαφορετικό.....

Να εμφανίζεται το μήνυμα στην οθόνη και ο χρήστης να μπορείς να κινείται μέσα στο site... Θα κάνω κάποιες μικρές διορθώσεις με css ώστε να μην είναι μέσα στην μέση. Το μόνο πρόβλημα είναι το Scroll.

[migf1]

Όχι εντάξει, δεν τα έχω "πάρει"... Με άλλα πράγματα τα παίρνω, εδώ συζήτηση κάνουμε.

 

Ναι συμφωνώ ότι αποτελεί την επίσημη τεκμηρίωση. Μία τεκμηρίωση όμως είναι μία καταγραφή λειτουργιών. Δεν μπορεί να προτείνει τίποτα...

Αν συμπεριλάμβανε μόνο την τεκμηρίωση του API (συναρτήσεις, πως συντάσσονται και τι κάνουν) θα ήμουν πιο ευτυχισμένος. Επειδή ακριβώς είναι κάτι "επίσημο", δεν είναι σωστό να περιλαμβάνει απόψεις και κατευθύνσεις, διότι είναι πολύ πιο εύκολο να σε προκαταλάβει.

 

Αν υπήρχε μία (εξίσου επίσημη) σελίδα με best practices, θα μπορούσα να το δεχτώ. Αν και πάλι, δεν θα μπορούσα να καταλάβω το λόγο ύπαρξης της... Αλλά δεν υπάρχει. Όπως ας πούμε υπάρχουν τα coding standards

Τα στυλ και γενικώς όλα τα "προτεινόμενα" είναι προαιρετικά, ακόμα και τα best-practices. Στο ίδιο μήκος κύματος νομίζω κινούνται και οι πρακτικές που συστήνει το codex και για το θέμα που συζητάμε (δηλαδή επίσημα προτείνουμε αυτό, αλλά δεν απαγορεύεται κιόλας να χρησιμοποιήσετε κάτι άλλο).

 

Ντάξει, δεν είναι σημαντικό... Απλά έπρεπε να το αποκαταστήσω για κάποιον που θα κουτουλούσε το thread...

Για μένα είναι σημαντικό, ακριβώς για το λόγο που εξήγησες, ότι δηλαδή το φόρουμ το διαβάζει πολύς κόσμος. Ειδικά για παιδιά που κάνουν τα πρώτα τους βήματα είναι νομίζω σημαντικό να βρίσκουν αξιόπιστη πληροφόρηση, οπότε πολύ σωστά έκανες και διόρθωσες την ανακρίβεια που έγραψα και σε ευχαριστώ γι αυτό (για τον ίδιο ακριβώς λόγο έκανα μετά την υπόδειξή σου επεξηγηματικό edit στο ανακριβές σημείο του ποστ μου).

 

 

Θέλω κάτι εντελώς διαφορετικό.....

Να εμφανίζεται το μήνυμα στην οθόνη και ο χρήστης να μπορείς να κινείται μέσα στο site... Θα κάνω κάποιες μικρές διορθώσεις με css ώστε να μην είναι μέσα στην μέση. Το μόνο πρόβλημα είναι το Scroll.

Για να είμαι ειλικρινής, με αυτό σου το ποστ με μπέρδεψες. Δεν έχω δηλαδή καταλάβει τι ακριβώς θέλεις να κάνεις. Υποψιάζομαι πως μάλλον θέλεις το μήνυμά σου να εμφανίζεται ως ένα modeless dialog. Σε αυτή την περίπτωση, ίσως είναι καλύτερα να χρησιμοποιήσεις κάποιο jquery plugin.

 

Το jQuery UI για παράδειγμα περιλαμβάνει (μεταξύ πάρα πολλών άλλων) κι ένα dialog widget το οποίο από default είναι modeless (μπορείς να το αλλάξεις θέτοντας το modal property του widget σε true).

 

Μια λίγο πιο γενική συνάρτηση για modeless on-screen messages θα μπορούσε ας πούμε να είναι κάπως έτσι...

function jq_message( title, message )
{
	if (!title) title = 'Message';
	if (!message) message = '';

	jQuery('<div id="myMsgBox"></div>').html(message).dialog({
		appendTo: document.body
		//, dialogClass: 'no-close'
		//, modal: true
		, resizable: false
		, title: title
		//, show: 'clip'
		//, hide: 'clip'
		, buttons: [
			{
			text: "Ok",
			click: function(){jQuery(this).dialog('destroy')}
			}
		]
		, close: function(event, ui) {
				jQuery(this).dialog('destroy');
				jQuery(this).remove();
				}
	});
}

Κι αν θέλεις να μένει σταθερή η θέση του dialog κατά το scrolling του parent, θα μπορούσες να θέσεις με css κάτι σαν το παρακάτω...

.ui-dialog{ position:fixed; }

ΥΓ1. Δεν είμαι βαθύς γνώστης της Javascript/jQuery, οπότε είναι παραπάνω από πιθανό ο παραπάνω κώδικας να μπορεί να βελτιωθεί σημαντικά από κάποιον που τα κατέχει σε μεγαλύτερο βάθος από εμένα.

 

ΥΓ2. Το jQuery UI προσθέτει σημαντικό overhead επειδή περιέχει πάρα πολλά πράγματα, παρόλο που μπορείς να φορτώσεις επιλεκτικά μόνο όσα επιθυμείς. Ίσως είναι καλή ιδέα να δεις κι άλλα παρεμφερή plugins, πιο εξειδικευμένα, που μάλλον θα είναι πιο ελαφριά ή με λιγότερα dependencies ή με πιο απλή/κατανοητή διαχείριση.