One could cache the old (core) proto class in question into a "base" property of the new class before extending and overriding, and then do a check against required conditions to execute the new code, otherwise apply the old method...
Here is the code I posted to solve the Parenizor problem (from the Douglas Crockford site) in prototype... this type of technique could easily be applied to overriding the prototype core classes in a maintanable manner... just be sure you do your due diligence and regression test your changes.
Parenizor = Class.create();
Parenizor.prototype =
{
initialize: function(value)
{
this.setValue (value);
},
setValue: function(value)
{
this.value = value;
},
getValue: function()
{
return this.value;
},
_toString: function()
{
return "(" + this.value + ")";
}
};
ZParenizor = Class.create();
ZParenizor.prototype =
{
initialize: function(value)
{
//cache the super class
this.base = new Parenizor(value);
//inherit
Object.extend(this, this.base);
//override
Object.extend (this,
{
_toString: function()
{
if (this.getValue())
return this.base._toString();
return "-0-";
}.bind(this)
});
}
};
alert(new ZParenizor(5)._toString());
alert(new ZParenizor()._toString());
On 7/19/06, Todd Ross <
[EMAIL PROTECTED]> wrote:
Maninder, Singh wrote:
> Your solution works perfect for me (from the first round of testing that I have done).
I'm glad to hear that.
> There is just one small issue -
>
> Currently, I have made changes to my prototype file.
> But, this means that tomorrow if new version of prototype comes
> out, it's going to be a pain maintaining it.
I've taken a very strong position on this issue in the past; offering
code out-of-tree is creating maintenance burdens for the people who
adopt it. I am, however, making every effort (specifically, I've filed
a bug report with a patch ready to review) to get this code included
into Prototype proper. It's your decision on whether you choose to
adopt it or to come up with an alternative solution. You asked for a
patch and I provided. :)
> What do you suggest - should we extend and add these lines (which
> would mean duplicating a lot and still no guarantee of not making
> changes in the future)?
Personally, I feel that patching prototype.js for a change like this
(it's not a fringe change; it makes changes to core parts of
Ajax.Request) is the best approach. Ryan suggested that maybe it could
be reworked as a separate include. You two are welcome to try. Please
post your solutions if you choose to pursue it.
> I wish Sam would incorporate this.
In the FIVE MONTHS that this patch has been available, it's not received
a single comment from Sam or other developers / users. If you'd like to
see it included, then I'd suggest you add a "me too"/"tested" comment to
the bug report. That is, once dev.rubyonrails.org is back on-line.
Todd Ross
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
