Forums

I think the 'talking to an API' is a layer (or two) above Y.Model - but there's some discussion https://gist.github.com/0fe7ff471d8bafb57878 about that.

Y.Model is the representation of the data, wherever it's come from and going to. Satyam's point, I think (excuse me if I've missed it though) is that representing database data is an extremely common use-case for many of the users of YUI (certainly the avg joe's). Y.Model has some problems in this situation, and may well do in other situations. Satyam's gallery module tries to fix this, and makes more sense to my mind (esp. separating meta and data).

What'd be nice to work out (I'm not familiar enough with this, sorry) is how easy it is to swap GalleryModel and GalleryModelMultiRecord in for Model and ModelList in widgets - datatable being an obvious one. It'd be nice if widgets could not bake in Model/ModelList (I don't think datatable does).

This has gone a bit off-topic: I'll return a little, and add support to what Marc and Ilya have been saying... It won't be too long before I have to start with the YUI3 - mobile happy app...

Thanks

Matt

This discussion has already been carried on several other threads, always with the same outcome. In fact, there was a very long discussion prior to Y.Model announcement, several of us put a lot of time into that. Perhaps it is not that we should further talk about it, perhaps it would be good for you to read all that has been written about it.

Yes, if I am unhappy about isNew() I can write my own, in fact, I can write my own Model. Oh, wait a minute, I already have! So, thanks for the advise but I've already done it.

Y.Model might have been designed with one narrow focus in mind and yes, intermediaries on the server might compensate for the shortcomings of Y.Model. A RESTful service might, for example, provide an alias for a field called clientId if I happen to have a client table with such a field name for its main key which clashes with an existing attribute on Y.Model because nobody thought about separating data and meta data and turned everything into attributes. Sure, I can do that.

I believe I am quite capable of working around the limitations of such a narrowly focused design, or drop it altogether and use something else. Oh, wait a minute, I've already done that too. Thanks again for the advice.

By holding on to such a bad design and making further parts of YUI dependent on it, such as DataTable, you guys are just digging yourselves deeper into the hole.

Two YUIConfs ago DataTable was released just to have something fancy to announce. In this last release, DataTable was redone from scratch. Y.Model along the rest of the components in the app framework was rushed to the last YUIConf. Eventually, it will have to be fixed, or might be obstinately held on to. Lets hope no new components get announced in future YUIConfs.

Has anybody done any work on Phonegap and not comboloading? Is it excessively painful?

I think that would be a good first step. If we could provide a plugin for setting up an environment for doing Phonegap-compatible development, it could encourage some more porting of mobile UI controls.

Is there *anyone* with experience on using yui 3 and Phonegap together? It seems a natural fit but there is ZERO documentation available on it. I find it hard to believe that somewhere in Yahoo there isn't a couple of projects doing just this. Any kind of help would be appreciated so we don't have to reinvent all the wheels (and possibly badly). I mean, loading, pre combo-loading, packaging, integrating with the phone functionality, services, the tips and tricks, etc etc. On the one hand I'm dying to get started, but on the other hand I know I can't spend the time getting over all off the getting started hurdles, especially without documentation. It's frustrating.

Awesome! Looking forward to it!