(⊃｡•́‿•̀｡)⊃━☆ﾟ.*･｡ﾟ The Backbone Framework: http://marionettejs.com
https://codepen.io/dimatabu/pen/WNwwEvx?editors=1010
childViewEventPrefix.it seems that this api was designed mostly for collection child views.
_eventPrefix should be defined in a parent view and this prefix will be used for all children events.same api is used in a view with regions and this is not a thing i am looking for.
(also,
{childVIewEventsPrefix: true } will trigger true:childeventname on parent)
ButtonView = View.extend({
triggers: {
'click':'click'
}
});
View.extend({
onRender() {
this.showChildView('resolve', new ButtonView());
this.showChildView('reject', new ButtonView());
},
onResolveClick() { ... },
onRejectClick() { ... }
})so, i am looking for a way to implement this
should i proxy this childview's events on every childview setup.in case of
region this prefix may be defined as region option.in case of collection view - childViewEventsPrefix - is good enough
but in case of
addChildView this name should be option of each added view.but childViewEvents at the moment expect that all children will proxy up events with the same prefix, so i think you dislike this idea ))
1 reply
this.render() is called on parentview? In https://jsfiddle.net/fbL819mz/5/ I have an example when executing toggle will destroy the childview; the problem is the parent (LayoutView) is provided with an instance of the view whose lifecycle is managed separately in my real application?
Hello everyone, I have (possibly stupid) question, but was not able to find an answer anywhere else.
I have a triggers ('click input[type="radio"]': 'bundle:selected') connected to a childView.
It's basically radio button, it's calling data in a componentModel on a click. This works just fine and there is no problem with it. What I need to do is to preselect the radio button when the page loads (or even before) and call the same data as i would click on that. I am able to select that radio button with initialize(), but this will not call the related functions.
I am totally new to Marionette. Thank you for any reply.
@tni711 sure you can load marionette in js tags locally or from a CDN https://cdnjs.com/libraries/backbone.marionette. These fiddles https://jsfiddle.net/user/marionettejs/fiddles/ work that way
Thank you Paul! I ended up using the template setup by Abiee in Github in https://github.com/abiee/es6-marionette and then updated the dependencies to latest version. The demo still works! I now have a playground to explore the latest Marionette API.
Hi all, hi @paulfalgout ,
with a little bit of surprise I just read v5 is "dropping its dependency on Backbone" - with some though, though, this definitley makes sense... Can you confirm this understanding:
Marionette (as dealing with Views) will become independent of Backbone's View, but I could still happily use Backbones Model/Collection approach for Marionette CollectionViews or similar things?
I don't want to waste your time justifiying this decission, but is there a chat log / blog post / documentation on the ideas on this matter?
I also want to express my thanks for keeping the library not only alive but growing!
This is correct. Backbone will still be supported. v5 is still in alpha, very early stages. Made the release for a couple of reasons.. to get the train on the tracks instead of just talking about it and so it could be pushed to a benchmark for testing the proposed changes.
I perhaps closed the related issues a bit too soon doing some fall cleaning, but we’ve had discussions open about losing the dependency for a while.
The two big outstanding changes expected are making views non-destructive to views in their regions and dropping the Backbone.View dependency. And after working on the regions for a while it was clear that the region work depended on dropping Bb.View which unfortunately slowed velocity a bit along with core contributors getting caught up in other things.
At this point I don’t know if this’ll stir up more community effort, but I’m at least commited to trying it and seeing how a backbone-less marionette works for people. It should be nearly 100% compatible if some configuration is set, but by default we’re looking to no longer utilize jquery or cache the $el on the view and region.
This opens the door to a variety of possible template/renderer solutions and improve performance.. And allows for various other little fixes that were never going to be addressed by Backbone itself.
Blog post will come when the tests are fixed and the docs are mostly updated.. Probably with a release candidate. For now, anyone adventurous enough to wade through the changes can try it, but needs to cook a bit before it’s broadcasted.
Oh one other v5 breaking change which may be substantial for someone.. view’s will no longer query the dom for an el set as a string.. so if anyone was doing this:
const myView = View.extend({
el: ‘.foo-selector'
});They’re now going to have to do this:
const myView = View.extend({
el: document.querySelector(‘.foo-selector’)
});But I don’t suspect that was a frequently used pattern for people.
TBH, I used this approach "in my early days" (back on v2) when I did not really get the right understanding of "how it should be done" and Layout and View were split... Yes, long time ago, but some old apps are still alive.
Still, this is a totally valid BC break for a new version.
Personally, during my latest dev, I was always trying to go "without $" but used getUI or other things instead, inspired by a blog post quite some time ago, having in mind that one day it might be possible to drop jquery as well... This sounds awesome!
It should be nearly 100% compatible if some configuration is set,
@paulfalgout can you explain the thought there, regarding "configuration"?