Hi,

> My continuing problem is I have to "surgically" excise the X-JSON from the
> header each time on the client side before I issue a new Ajax call.

Why?

> Is there a Prototype API call that can selectively remove the X-JSON
> attribute and its content from the response?

Your best bet is to avoid keeping an enduring reference (directly or
indirectly) to the response. I'm not aware of any explicit API to do
it, but I believe the X-JSON stuff comes through in two ways: As the
`headerJSON` member of `response` and also as a second parameter (now
deprecated) to the success callback. So if you're creating a closure
within your success callback, the simplest solution is ... not to. :-)
If that's not an option, then be sure to declare the second parameter
and then set both of them to undefined before exiting the success
handler, e.g.:

onSuccess: function(response, json) {
    // Do you stuff...

    // At the end
    response = json = undefined;
}

...but again, that's not my recommended approach.

> I am
> investigating a servlet filter but still do not know how to filter X-JSON
> header attribute and simply rewrite the rest to the outputstream.

I don't understand. If you don't want the X-JSON header being sent,
why can't you stop it being sent in the first place? Why would you
need to add a servlet filter? If you're not in control of the origin
response, I don't think I'd muck with its headers (it's probably
relying on that data); if you are, I'd prevent the header being set
there.

FWIW,
--
T.J. Crowder
Independent Software Consultant
tj / crowder software / com
www.crowdersoftware.com

On Aug 26, 12:27 pm, chrysanthe m <chrysant...@gmail.com> wrote:
> Hi TJ
> Interesting, I never would have expected that but the client side is
> persistent so it has to accumulate.
> My continuing problem is I have to "surgically" excise the X-JSON from the
> header each time on the client side before I issue a new Ajax call.  I am
> investigating a servlet filter but still do not know how to filter X-JSON
> header attribute and simply rewrite the rest to the outputstream.  That is a
> more elegant solution.  But I am back to client side
>
> Is there a Prototype API call that can selectively remove the X-JSON
> attribute and its content from the response?
>
> Also what is the limit to the size of the X-JSON attribute.  If I need to
> handle very large JSON encoded data structures what is a better way?  tia.
>
> On Thu, Aug 26, 2010 at 4:37 AM, T.J. Crowder <t...@crowdersoftware.com>wrote:
>
>
>
> > Hi,
>
> > Just make sure that nothing is continuing to reference the object, and
> > it will be available for garbage collection. When (or if) it gets
> > garbage-collected is up to the interpreter.
>
> > Sometimes it can be subtle when something continues to have a
> > reference to an object, particularly when creating closures[1]. For
> > instance, here's an Ajax call that expects to get a JSON response. The
> > code sets up a situation where all of the objects related to the Ajax
> > response (including the one(s) created by deserializing the JSON
> > string) are kept in memory, probably unnecessarily:
>
> > * * * *
> > new Ajax.Request("myurl", {
> >    onSuccess: function(response) {
> >        if (response.responseJSON && response.responseJSON.stuff) {
> >            var container = $('container');
> >            container.update({
> >                bottom: response.responseJSON.stuff
> >            });
> >            $(container.lastChild).observe('click', function(event) {
> >                // Handle it when the new stuff is clicked
> >            });
> >        }
> >    }
> > });
> > * * * *
>
> > The culprit in the above is the click event handler. Since the click
> > event handler is a closure, it keeps a live reference to everything in
> > scope where it's defined -- and since the element keeps a reference to
> > the click handler and the click handler keeps a reference to
> > `response` and everything in it, all that stuff is stuck in memory and
> > cannot be garbage collected.
>
> > The above code can be refactored to prevent that, by making the click
> > handler *not* a closure over the response (e.g., define it elsewhere
> > and then just use it):
>
> > * * * *
> > new Ajax.Request("myurl", {
> >    onSuccess: function(response) {
> >        if (response.responseJSON && response.responseJSON.stuff) {
> >            var container = $('container');
> >            container.update({
> >                bottom: response.responseJSON.stuff
> >            });
> >            $(container.lastChild).observe('click',
> > handleClickOnStuff);
> >        }
> >    }
> > });
> > function handleClickOnStuff(event) {
> >    // Handle it when the new stuff is clicked
> > }
> > * * * *
>
> > The click event handler no longer closes over the Ajax response, and
> > so once the success handler has finished, nothing will continue to
> > have a reference to the response and it's all available for garbage
> > collection. The above also has the advantage of not creating a new
> > function each time the Ajax call is done; instead, you reuse the same
> > click handler function.
>
> > Alternately, you can use the "null out" approach, which looks like
> > this:
>
> > * * * *
> > new Ajax.Request("myurl", {
> >    onSuccess: function(response) {
> >        if (response.responseJSON && response.responseJSON.stuff) {
> >            var container = $('container');
> >            container.update({
> >                bottom: response.responseJSON.stuff
> >            });
> >            $(container.lastChild).observe('click', function(event) {
> >                // Handle it when the new stuff is clicked
> >            });
> >            response = undefined; // <== This is the change
> >        }
> >    }
> > });
> > * * * *
>
> > In the above, the click handler will continue to have a reference to
> > the `response` parameter, but you've broken that parameter's reference
> > to the `response` object, and so the click handler doesn't keep that
> > object (and the things it refers to) in memory. I don't like this
> > approach, but you see it done a lot, and like all tools it does have
> > its place in certain limited situations. It discourages reuse, though,
> > and still involves a memory impact every time you run it -- it creates
> > a new copy of the event handler and a new execution context for it --
> > but at least the large item referenced by `response` isn't kept
> > around.
>
> > None of this is remotely limited to JSON stuff. Change the call so it
> > returns text or HTML instead of JSON and change
> > `response.responseJSON.stuff` in the above to `response.responseText`
> > and you have the same problem -- the text will be kept in memory by
> > the click handler if the handler is a closure over the response.
>
> > When I first learned this about JavaScript and closures, I freaked out
> > a little bit. OMG! My functions must be keeping all kinds of rubbish
> > in memory! Ack! But don't worry, once you understand closures, you are
> > in complete control of what they do and don't keep references to --
> > and they're a wonderfully powerful tool in your toolkit.
>
> > [1]
> >http://blog.niftysnippets.org/2008/02/closures-are-not-complicated.html
>
> > HTH,
> > --
> > T.J. Crowder
> > Independent Software Consultant
> > tj / crowder software / com
> >www.crowdersoftware.com
>
> > On Aug 25, 10:06 pm, chrysanthe m <chrysant...@gmail.com> wrote:
> > > Hello
> > > Is thee a way to remove a json object processed by prototype client side?
> > > My objects are very large and will get larger so I must be frugal and
> > clean
> > > up after each processing.  Also is there a way to increase the size of
> > the
> > > header to a maximum(what?).  tia.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Prototype & script.aculo.us" group.
> > To post to this group, send email to
> > prototype-scriptacul...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > prototype-scriptaculous+unsubscr...@googlegroups.com<prototype-scriptaculou 
> > s%2bunsubscr...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/prototype-scriptaculous?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.

Reply via email to