Skip to content
This repository has been archived by the owner on Jan 12, 2018. It is now read-only.

Provide subviews directly when rendering instead of via globals #17

Open
augustl opened this issue Feb 10, 2012 · 5 comments
Open

Provide subviews directly when rendering instead of via globals #17

augustl opened this issue Feb 10, 2012 · 5 comments
Labels

Comments

@augustl
Copy link
Contributor

augustl commented Feb 10, 2012

Currently, a view needs to be made globally available with Serenade.view("my_view", tmpl) when subviews are used. This also puts some restrictions on what the controller can be - it currently has to be a constructor, for example.

It would be better if the subviews could be provided to aView.render.

var view = Serenade.view(tmpl);
var element = view.render(model, controller, {
    myView: function (model) {
        return otherView.render(model, myOtherController);
    }
});

In the template we have - view myView. This will cause myView to be called on the 3rd argument passed to render. This function is assumed to return a DOM element, such as the DOM elements render on another view will provide.

I think having a 3rd argument for this is better than using the controller, since view names might conflict with what you otherwise have on your controller.

The model passed would be the current model, be it for the template root or the current collection model.

@jnicklas
Copy link
Collaborator

I've been thinking about something like this for helpers as well, I don't like the fact that they are global. Local helpers would be very useful, we could even use them for rendering views. And getting away from having to define controllers and views globally would be super.

var view = Serenade.view(tmpl);
var element = view.render(model, controller, {
    myView: function () {
        return otherView.render(this.model, myOtherController);
    },
    anotherHelper: function() {
        return document.createElement('div')
    }
});

in view:

div
  - myView
  - anotherHelper

@jnicklas
Copy link
Collaborator

Not sure if we should only have local helpers though, or if there should still be some way of defining them globally?

@augustl
Copy link
Contributor Author

augustl commented Feb 10, 2012

You're refering to this.model in the helper. A helper can be called in multiple contexts for multiple different models. N times for a collection and once for a single model, for example. Therefore, I think it makes more sense to pass in the model as an argument, rather than changing either this.model or the value of this to accommodate for the change of contexts.

View helpers is a very good name for this feature. A view has a model, a controller, and optionally a helper. Makes sense!

I personally never found the global views useful. I think it's better if it's the programmers responsibility to keep a global reference to a view. Something like:

mynamespace.views.foo = Serenade.view(tmpl);

Most apps have a namespace setup like this anyway, and it lets Serenade avoid having a private black box of views stored somewhere. A little harder, but I think the end result has more clarity, more simplicity, and less magic. Also, the presence of view helpers makes the internal name based references useless in my taste. I'd much rather have my own plain reference to a view, and plainly call it in a helper, than having a named internal reference in my templates, as it is today.

If the built-in global views are removed, it might anger people that has grown used to them though :) So perhaps it makes sense to keep the global views, at the very least as a deprecated feature.

@augustl
Copy link
Contributor Author

augustl commented Feb 13, 2012

Added an implementation of this, see https://github.com/augustl/serenade.js/tree/view-helpers.

https://github.com/augustl/serenade.js/commit/e6132d315f65efc51e3c0a3d7a24d36997a26abd is an unrelated fix, perhaps I should put it in a separate branch/issue?

@augustl
Copy link
Contributor Author

augustl commented Mar 16, 2012

In my experience, the extra helper object is not really needed. The methods might as well get called on the controller.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants