Forums

Hi,

It would seem that mixing Models with Widgets is unsupported.

When I extend model with Y.Base.create, and add in WidgetParent & Widget, the toJSON starts to act funny. It does indeed return the result of getAttrs, however, many, many of these properties are not serializable as json (and understandably so).

In order to fix this, I need to override toJSON in my extension class and only return those properties I know will work, or to call CLASS.superclass.toJSON and then do some housekeeping with dozens and dozens of attributes by deleting the non-serializable ones from the array. I prefer the former as who knows what attributes Widget will receive over it's life. I prefer the latter because I don't want to modify my own toJSON everytime I add a new prop.

Mixed the otherway, extended Y.Widget then adding in Parent & Model, toJSON doesn't even work. It's just a blank array.

Are there plans to allow mixing of the Widget & Model classes? How about Model and other arbitrary Classes?

Heh, sorry for the multi-posts, but I want to reinforce the 'includeInSync' Feature.

That would also be helpful, at least in a model/widget situation, where you do have other attributes relevant to the widget, such as Node inputs or other Widget controls you have defined, but do not need them sent to the server.

Wouldn't one then have to listen for changes on the model, then sync them to the widget? Further, wouldn't one also have to listen for changes on the widget and sync them to the model? It would seem that is the worst of the alternatives I offered above, as there would be tons of listeners and syncing logic.

Still, for DT architecture it would make sense, since it needs to offer arbitrary attributes.

My point was that this is one of the first scenarios of using YUI3 since the beginning where two native components do not work together out of the box. They are ignorant of each other and incompatible with each other, which seems to go against the very grain of the framework.

Hi Eric,

Thank you for the detailed information, as well as that link to the documentation. I understand your points, and empathize with your conundrum.

While the points you made make sense for generic situations, mine is more nuanced and makes a better case for interoperability vs layering. My Widget is a WidgetParent, in addition to a model. This Widget also contains a ModelList, which are all of the WidgetChildren for this particular model.

I have a great need for the interoperability of all facets of the classes, including all of the niceties that come with Widget/WidgetParent/WidgetChild and all of the niceties that come with Model/ModelList. When I render my parent, I need all of my children to render. When I sync my parent, I need all children to sync. When I load my Model(parent)/ModeList(children)/Model(child) from remote, I need WidgetChildren/WidgetParent and Widget to take care of that end. In this case, Y.View is not advanced enough for me.

I will carry on with my integration, hoping this is my only stumble, but I have a greater hope for the unification of these two areas.

Hi Eric,

Believe me, I'm not excited about going down this path either, and I'm still debating the merits of the choice.

I have a complex WidgetParent that is filled with tons of custom properties. It just so happens that this WidgetParent has WidgetChildren that could number in the dozens, possibly hundreds. Each of the Children has dozens of properties and arbitrary attributes (They are all their own classes, extended from WidgetChild), where they each take care of their own properities.

These properties of both the WidgetChild and WidgetParent are controlled by numerous widgets (lower case) on the page, such as drop downs, inputs, radios, checkboxes, colorpickers, etc. These widgets are then tied by events to update the attributes of their respective widget on change. This way, when everything is dialed in like a user wants it, they click the save button and all I'm doing is persisting these attrs to the db.

These properties are all persisted in a database, and need to be pulled from the database on load. The widgets need to be instantiated from the data so that all properties exist as they did the last time a persist took place.

I need REST/JSON synchronization of these properties, and possibly the ability to detect whether they are modified.

Since the Model, and ModelList are not blessed to be compatible with Widget, it's may even be in my best interest to write my own special case model, modeled after model (heh), so that I don't have to worry about future implementations of Model/Widget affecting my attempted duck punching.

In essence, yes, I believe you that Y.View is best suited for rendering models in most cases. However, I need Y.Widget because of the rendering/add/remove/delegate/contentBox/boundingBox/attr change relationships they provide.

By the way, one question for you:

Suppose I have a class:

Foo = Y.Base.create('foo', Y.Model, [Y.Widget, Y.WidgetParent], {
add: function(i) {
Foo.superclass.add.call(this, i);
/*would really like a way to call Y.WidgetParent add() here.*/
/*do my own stuff*/
doMyOwnStuff();
}
})

How do I call Y.WidgetParent's add?

Sorry for not using code tags. Some arbitrary limit on it, I guess.