how to create and DESTROY Alpaca fields about alpaca

[Ognian]

Ups, not looking good enough; there is a destroy()...
But it looks like there is still something left over, after destroy...

[uzquiano]

The $.alpaca method should return the $ object so that's definitely an error. I'm fixing that in master.

With respect to memory cleanup, the destroy() method internally calls $(domEl).remove() so they should be roughly equivalent. What are you seeing in memory that is left over?

If you have some sample code, I can check it out. The objective of the destroy() method is for absolutely everything to clean up.

One possibility is that the $.tmpl engine may be keeping around cached copies of templates compiled during render. We need those to clean up as well. However, first, I'd like the understand what it is that you are observing?

[Ognian]

I'm dynamically generating and destroying different forms. And alpaca is loaded by the dojo amd loader. One problem is maybe that i'm still not able to correctly load the amd build of alpaca and therefore I'm still loading the normal one which still works... But what I observe is that not all memory is freed. At the moment I don't have a simple example since in the one I'm testing now there is also a server part and a mongodb also involved ;-)

The way I tested was actually like: http://gent.ilcore.com/2011/08/finding-memory-leaks.html ; and without the alpaca part the app behaves pretty good...

[uzquiano]

Good catch. I found a memory leak where the Form control wasn't calling down to child controls to release memory. I've committed up the change and would ask if you could run your tests again. I suspect memory will behave much nicer.

Curious what you find. I'm still thinking the jTmpl $.template cache should be cleaned up on destroy. Albeit, the total size of that allocation, even if it stays around, should be small and bounded. The reinstantations of the control ends up overwriting the old templates in cache so for a fixed # of templates, you'd have a fixed total size. Probably not too big of an issue but still one that is on my mind.

[Ognian]

Yes, now it is better, but I still see something from the template cache... although now things are much better.

The provided example was of much help for me, thank you very much.

I'm still unsure which Object created by alpaca is the top one: Is it the form from renderdField.form in the renderForm callback or is it the result of Alpaca("#form"); and what to do if there is no form property but a view one...

And one more thing, when having the dojo loader in trace mode I see the following:
trace:loader-finish-exec:jquery/jquery-latest.min public/modules/dojo/dojo.js:1672
Error: multipleDefine public/modules/dojo/dojo.js:1821
mix.uid public/modules/dojo/dojo.js:1821
public/modules/dojo/dojo.js:332
forEach public/modules/dojo/dojo.js:93
req.signal public/modules/dojo/dojo.js:331
defineModule public/modules/dojo/dojo.js:1522
def public/modules/dojo/dojo.js:1764
public/modules/alpaca/build/package/components/alpaca/alpaca.js:2533
public/modules/alpaca/build/package/components/alpaca/alpaca.js:2536
runFactory public/modules/dojo/dojo.js:1094
execModule public/modules/dojo/dojo.js:1223
execModule public/modules/dojo/dojo.js:1214
public/modules/dojo/dojo.js:1258
guardCheckComplete public/modules/dojo/dojo.js:1238
checkComplete public/modules/dojo/dojo.js:1253
onLoadCallback public/modules/dojo/dojo.js:1415
onLoad public/modules/dojo/dojo.js:1649
src: public/modules/dojo/dojo.js:1824
info: public/modules/dojo/dojo.js:1824
. public/modules/dojo/dojo.js:1826
trace:loader-finish-exec:alpaca/alpaca public/modules/dojo/dojo.js:1672
trace:loader-finish-exec:dojo/has public/modules/dojo/dojo.js:1672
trace:loader-finish-exec:dojo/has!0 public/modules/dojo/dojo.js:1672

Any Idea on this?

[uzquiano]

I'm really interested in this AMD loading issue you're seeing with Dojo. Do you think you could write a small Dojo test or something like that (an HTML page, perhaps loading from a Dojo CDN) that uses the AMD to reproduce the problem?

We're using AMD quite successfully with requirejs but I am aware that the window global namespace is being polluted in one case. Which means that the AMD wrappers, while they work, aren't purely modularized. I'd like to correct that and I suspect it might be related to the issue you're seeing.

I'm happy to work on it and fix it. I just need a way to reproduce the stack trace you've provided?

[uzquiano]

I put in a fix that seems to make Dojo happy. Dojo was correct in that it identified a duplicate define() call which we no longer needed. At this point, if people want to use the AMD version of Alpaca, we have a separate build (a component) so there's no need for the main Alpaca.js file to support AMD loading in and by itself.

When you run a build (ant clean package), you'll find the AMD modules located in /build/package/components. The Dojo test references the Alpaca component. We're using the component convention since that is compatible with Twitter Bower, Component and many other new wave JavaScript dependency managers.

Thanks a ton @Ognian for supplying the test. It really helped. You're awesome!

Can you give it a shot and let me know if it works for you? I also cleaned up the destroy() methods as I think I understood the confusion you encountered with the additional .form property. You can now call destroy() on the top level control OR the form. It doesn't matter, but I would suggest the top level control for best practice.

[Ognian]

It looks good now. I made a short test and don't see something left over now. I'll continue to watch on this...

[uzquiano]

Sounds awesome. I'll close this for now. Really glad to have knocked this out.
Thanks for all of your hard work!

[Alchaves]

I'm having the same problem with destroy().

I'm trying to destroy() some required fields and visualy they are gone, but it doesn't let me proceed with the form.