Element clone storage again #2193

Closed
satazor opened this Issue Jan 6, 2012 · 9 comments

Comments

Projects
None yet
3 participants
Contributor

satazor commented Jan 6, 2012

Sorry for opening a ticket related to cloning an element storage again, but the other one was closed.

Basically, we do want to clone the element storage in some situations.
Unfortanly, we where unable to do this directly so we made a workaround that worked in 1.4.1 (ugly):

(function() {

    //TODO: Solve this / send a ticket to mootools

    var get = function(uid){
            return (storage[uid] || (storage[uid] = {}));
    };

    var storage = {};

    Element.implement({

        retrieve: function(property, dflt){
            var storage = get($uid(this)), prop = storage[property];
            if (dflt != null && prop == null) prop = storage[property] = dflt;
            return prop != null ? prop : null;
        },

        store: function(property, value){
            var storage = get($uid(this));
            storage[property] = value;
            return this;
        },

        eliminate: function(property){
            var storage = get($uid(this));
            delete storage[property];
            return this;
        },

        cloneStorage: function(from) { 
            var fromStorage = get($uid(from));
            storage[$uid(this)] = Object.clone(fromStorage);
        }
    });

})();

This does not work anymore because the $uid is not exposed as of 1.4.2.

Someone suggested to manually do this by looking at Element.Storage, but doing console.log(Element.Storage) returns undefined..

Any suggestions?

Contributor

satazor commented Jan 6, 2012

We still can apply the hook by doing using Slick.uidOf(this).
Still, don't you guys think that the Element's storage could be exposed so we can manually do this without overriding mootools methods?

Owner

ibolmo commented Jan 7, 2012

We've talked about it before, but we haven't come up with many reasons to do this. Moreover, it's a matter of protection as well since the storage is deleted on garbage collection. If there are additional references to the storage object, then that's a memory leak in IE < 9

Contributor

satazor commented Jan 8, 2012

I'm using mootools as the base library for a single page app, on top of a private MVCS framework.
Correct me if i'm wrong, but the garbage collection is only made on page unload right?

Owner

ibolmo commented Jan 8, 2012

Not necessarily, when you destroy an element you also destroy its storage.

On Sun, Jan 8, 2012 at 5:11 AM, André Cruz <
reply@reply.github.com

wrote:

I'm using mootools as the base library for a single page app, on top of a
private MVCS framework.
Correct me if i'm wrong, but the garbage collection is only made on page
unload right?


Reply to this email directly or view it on GitHub:
#2193 (comment)

Contributor

satazor commented Jan 8, 2012

Allright, I will keep this hook until a solution appears..

Owner

ibolmo commented Jan 8, 2012

Frankly, it's a few lines. I'm of the opinion (and favor) of everything being public.

If it's comforting, in 2.0 this point is moot since the Element can be subclassed and you can modify storage to your heart's content. (At least in theory, hehe.)

Owner

ibolmo commented Jan 8, 2012

@cpojer @arian

What do you guys think? A getter and setter method for storage? This way users/devs can add cloneStorage without modifying Moo.

Contributor

satazor commented Jan 11, 2012

That would be awesome.

Member

fakedarren commented Feb 20, 2013

Closing due to wontfix status and age and new stuff (prime/elements)

fakedarren closed this Feb 20, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment