Forums

Hi everyone,

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.

Thanks.

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.

Daniel,

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.