Since implementing a $.map() working on objects is not an easy task, I've given up the idea.
BTW, here is the project if you are interested: http://github.com/gminuses/jquerymvc. Regards On Oct 31, 12:49 am, Scott Sauyet <scott.sau...@gmail.com> wrote: > On Fri, Oct 30, 2009 at 11:13 AM, gMinuses <gminu...@gmail.com> wrote: > > OK, the real-world use is this: > > > I'm writing a plugin for jquery that implements mvc pattern, and it > > works like this: > > > [ ... ] > > > $.mvc.controller({ > > myController: { > > myAction: function() { > > // Pass in a callback function, > > // once model has retrieved the data, > > // it'll pass the data as the first parameter > > // to the callback function > > this.model('myModel').myMethod(function(data) { > > // data returned > > }); > > } > > } > > }); > > > $.mvc.model({ > > myModel: { > > myMethod: function() { > > // model passes the data by returning it directly > > return 'data'; > > } > > }, > > > myAnotherModel: { > > myAnotherMethod: function() { > > this.ajax({ url: './', success: function(data) { > > // or by returning it in the ajax callback function > > return data; > > }}) > > } > > } > > }); > > So, to make sure I understand, you want to write a function (to be > used by an extended $.map) that wraps either myModel.myMethod or > myAnotherModel.myAnotherMethod to be called by myController.myAction, > which will supply a callback function to actually handle the actual > data returned by the methods. Is that right? > > First of all, good luck. Whenever I've needed to get data from a > possibly synchronous or possibly asynchronous source, I've had to > define a method that accepts a callback and extend that in all cases, > even the otherwise synchronous ones. Scoping seems a minor worry > compared to the synchronous/asynchronous dichotomy. I'm really not > sure how you'll manage to do this. Do you already have an > implementation? > > But then the question becomes, how do you want $.map to work for your > object? Does it modify the object in place? (I would strongly argue > against this, not least because that would be at variance with how it > works for sequences.) Is the model object allowed to have methods > that somehow escape the wrapping, like the helper function I defined > above? Can the wrapper function ignore some properties? > > > This is when I need to modify user defined functions to support such > > usage, and it comes the problem of scoping. It'll be very handy if > > $.map() works on objects. > > > And I believe once an application gets more and more complicated, > > it'll stand a good chance that some kind of hash-like objects need to > > be modified. > > Right now, as Robert pointed out, we're using the existence of a > numeric "length" property to determine if an object is array-like. > Are you going to prohibit model classes from having a property named > "length"? If not, how would you distinguish the current array-like > behavior of working only with elt[0], elt[1], ... elt[length -1] and > your new behavior that would use any other named properties? > > It strikes me that it's very easy to add a new $.objMap function if > you find it necessary for your project. I certainly am not seeing any > argument for the widespread utility of adding this to $.map in the > core, nor do I see some possibly trivial implementation that makes it > such a minor addition that we can safely add it without worry. Can > you supply either of those? > > -- Scott -- You received this message because you are subscribed to the Google Groups "jQuery Development" group. To post to this group, send email to jquery-...@googlegroups.com. To unsubscribe from this group, send email to jquery-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jquery-dev?hl=en.
