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.
