|Page 1 of 1||[ 6 posts ]|
I've been using the Y.Model and Y.Views extensively throughout my project. It's been working out well so far, but I'm re-evaluating a design choice I made upfront.
At the project's inception with no prior YUI experience, I was pretty overwhelmed with learning YUI and the App Framework. So I decided to have the Y.Views communicate with each other with custom events (which is good), but also made the design choice to have all events be registered/fired on the Y instance.
At the time, I had enough understanding and forethought to not put it on the global YUI instance, fortunately. But for the time being, all custom events are funneled through my single Y instance.
I know I can setup my Views to have event targets/chains, but I'm wondering now, is it worth the extra code?
The obvious downside to having all events on the Y instance is that there could be naming collisions for the event names. But I've been using naming conventions, which have been solving that problem.
Should I take the time to specify event chains/targets on the Views? Will there be a performance bottleneck eventually if I continue to register events on the Y instance?
Any feedback would be appreciated.
I think your approach is feasible.
See also how to structure a Y.App:
It depends on the size of the app.
I usually take the approach of having a Mediator View that listens for events on other views rather than on the Y instance. The Mediator then acts on the event, calling into other views it knows of if necessary. It sits in the back and controls flow and communication. It's a lot like Y.App, only used for a group of related views.
Hi Alberto & Simon,
I've been thinking about using Y.App to be the listener, but since my project does not require the Router, I'd only be using Y.App as a 'controller of sorts' for forwarding custom events fired by the views. In which case, the mediator view idea sounds more in line with what I'd need.
Right now, I register the custom events in the initializer(). So basically all that would change is this registration would occur in the mediator view and I'd need to setup a event target chain b/t the view(s) and the mediator view?
I'm not entirely sure how this would work out. Is there a sample code to demonstrate this Mediator View?
Here is an example of a mediator view: https://gist.github.com/3135950
In many cases however, I find that the best communication between views is when they share models. Often changes on models are what needs to update other views. I think I only use event handlers for views very rarely - I still use mediator views to glue together views and models for more granular sections of a page that is to specific for an Y.App instance to care about.
Thanks for the code snippet and your insight. There's a few different ways to organize my code in light of this discussion. I'll have to let it ruminate for a bit
|Page 1 of 1||[ 6 posts ]|
|You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum