On Jan 13, 10:33 am, h3 <[email protected]> wrote: > In my example yes, because it was a simplified scenario. Your method > most likely is more efficient with small codebase, but when I deal > with many components and events it does get ugly.
The dialog plugin is built entirely in this fashion and has a fair number of elements and event handlers. Take a look at it and see how you feel about it. To me, I would much rather have one spot to look for how an element is built, how it's modified and what event handlers it has, rather than looking in three or four different methods, but that may just be personal preference. In all honesty, I highly doubt anyone is building a ton of functionality on a single element on init so I don't see the need to split everything out. > One of the thing that bugs me is that you can't continue to refer to > the widget as "this" within the callback function. So you have to > assign > "this" to a variable so it can be accessed from the callaback's scope. You're doing this anyway with your event binding method. The events are still referencing widget inside the event handlers, so I don't see what you're gaining. Also, if you don't like the inconsistency, then just use widget all the time instead of this. > Also, when working with many DOM elements it can get confusing to > assign them all to "this", mixing them with the widget's methods. This would be personal preference. Nothing is stopping you from doing widget.ui.someElement instead of widget.someElement in either design pattern. But really when are you going to have an element variable name that's the same as a method name? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "jQuery UI" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jquery-ui?hl=en -~----------~----~----~----~------~----~------~--~---
