Give Y.mojito an interface for adding controllers, binders, etc. #405

Closed
mridgway opened this Issue Aug 17, 2012 · 4 comments

Comments

Projects
None yet
3 participants
@mridgway
Collaborator

mridgway commented Aug 17, 2012

This would deprecate or eliminate support for attaching things directly to Y.mojito.xxx. Expect downstream breakages.

@drewfish

This comment has been minimized.

Show comment
Hide comment
@drewfish

drewfish Aug 17, 2012

Contributor

Wouldn't this be contrary to the way YUI modules are usually authored?

Contributor

drewfish commented Aug 17, 2012

Wouldn't this be contrary to the way YUI modules are usually authored?

@mridgway

This comment has been minimized.

Show comment
Hide comment
@mridgway

mridgway Aug 17, 2012

Collaborator

We're already subverting that by storing them in our own container and requiring that they be added to that container. In my mind, Mojito is a framework that should allow adding special types of modules (controllers, binders, etc.) just like YUI does. Either that or not store them in a container and just instantiate them based on class name regardless of their namespace.

Collaborator

mridgway commented Aug 17, 2012

We're already subverting that by storing them in our own container and requiring that they be added to that container. In my mind, Mojito is a framework that should allow adding special types of modules (controllers, binders, etc.) just like YUI does. Either that or not store them in a container and just instantiate them based on class name regardless of their namespace.

@ericf

This comment has been minimized.

Show comment
Hide comment
@ericf

ericf Aug 21, 2012

Collaborator

I'm curious what you envision this interface looking like, and how it would be fundamentally different than placing constructor functions on some namespace.

Collaborator

ericf commented Aug 21, 2012

I'm curious what you envision this interface looking like, and how it would be fundamentally different than placing constructor functions on some namespace.

@mridgway

This comment has been minimized.

Show comment
Hide comment
@mridgway

mridgway Aug 21, 2012

Collaborator

It is not fundamentally different from using namespaces explicitly, but it gives us more control over this namespace. We've already had to have BC breaks because the namespacing was incorrect in our archetypes and examples, and I'd like to prevent this from happening again (except this one more time to use the API).

This may change depending on how the YAF integration works (whether if it even uses the controllers, binders, models namespaces), but if we have a hard expectation of where a developer's objects need to be stored, we should abstract it out.

Collaborator

mridgway commented Aug 21, 2012

It is not fundamentally different from using namespaces explicitly, but it gives us more control over this namespace. We've already had to have BC breaks because the namespacing was incorrect in our archetypes and examples, and I'd like to prevent this from happening again (except this one more time to use the API).

This may change depending on how the YAF integration works (whether if it even uses the controllers, binders, models namespaces), but if we have a hard expectation of where a developer's objects need to be stored, we should abstract it out.

@mridgway mridgway closed this Oct 15, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment