Talk:Class reference

Yeah, so apparently there is a limit for the number of templates that you can include in a single page.

Suggestions? ---User:Mr Doom Bringer (Talk) 20:04, 26 August 2010 (UTC)

I think we can use the for template that NXTBoy made to iterate through each object and include it safely in the page. --Blocco|^{Userpage-Talkpage} 00:42, 27 August 2010 (UTC)

I've already told you my idea, but no harm in posting it here as well. I had suggested creating Class reference/Object, Class reference/Fuction, and Class reference/Event. We could then and copy the templates from the Class reference page and paste them as is into the appropriate subpage. The subpages could then act as templates, and be transcluded onto the Class reference page. This way is very very simple, and it should work as it reduces the number of templates on the Class reference page to three. Looks like you've got something more imaginative in mind, so other suggestions are welcome! :) --Gordonrox24 | ^Talk 23:58, 26 August 2010 (UTC)

Further, I could be wrong, that might actually not do anything lol. As soon as you add a template that has templates in it, the templates in the template get added to the list of templates on page. Meaning that my idea would only make there be three additional templates on the page. hmmmm.... --Gordonrox24 | ^Talk 00:09, 27 August 2010 (UTC)

Could that have been said any more confusingly? Heh. Though, the main issue I seem to notice with the page at the minute, is that its sheer size/length causes a very long load time for the page, the page has to build all the object tables before it 'minimises' them too. Having their members visible at first glance is great, that's how things should be, easy to find, but is it really worth sacrificing load time? May it be better in this one instance, to provide a table of each object with a link to its own page, where the user could find the members there? Wyo 00:34, 27 August 2010 (UTC)

Use Template:ClassReference. It can also be used programmatically. Also, it might be a nesting limit, rather than anything else.

NXTBoy (talk • contribs)

15:29, 27 August 2010 (UTC)

Hmmm. Did a view source. Look at this:

NewPP limit report
Preprocessor node count: 72885/1000000
Post-expand include size: 2097151/2097152 bytes
Template argument size: 919733/2097152 bytes
Expensive parser function count: 0/100

NXTBoy (talk • contribs)

16:09, 27 August 2010 (UTC)

Yes, you can read all about that information over here. I was wondering if it would be possible to generate the original format (just one template) system that I was using, making it one template for the object list drop down, and that template is filled with the object's methods, properties and events. That would be one template per page. The catch is that it's absurdly tedious to actually make that template. So is there a way to generate a page based on another page's content, so that the output page does not involve any templates from anywhere else? ---User:Mr Doom Bringer (Talk) 22:59, 28 August 2010 (UTC)

One of the major reasons that we're going over the limit could be that the system apparently includes the description page for every single member, e.g. including Object:Part includes Object:Part/methods, which in turn includes the article for every single method, although when used with the Object template only the name is displayed. Would splitting the /methods page into /methodnames for the Object template, which only includes a link, and /methods for the documentation page which includes the member descriptions help to reduce the amount of data included in the page? --Sncplay42 23:41, 28 August 2010 (UTC)

You're not reading what I posted: Post-expand include size: 2097151/2097152. Basically, the page is too big. Nothing to do with how many levels of templates there are.

NXTBoy (talk • contribs)

07:44, 29 August 2010 (UTC)

My suggestion would be to try and make the member lists load with AJAX when the entries are expanded, and not otherwise

NXTBoy (talk • contribs)

07:47, 29 August 2010 (UTC)

You're not reading what I'm saying: Go read it again. The page is not too big, the HTML itself it small. If it were to big in size it would be spitting out that error. What the page is is too expensive in template depth searching specifically because we have too many nested templates. Snc has a point, at present the page is digging through too many templates at the same time to load the entirety of the page. So I once again ask, is it possible to instead of including all of the templates, generate individual object pages and include those in a large list. My original system didn't require AJAX or anything else, the issue is that we have too many templates. ---User:Mr Doom Bringer (Talk) 21:13, 29 August 2010 (UTC)

Methods >>

Properties >> Object list >> Result list page

Events >>

Result list Pages > Class Browser

See this bit: Apparently nested transclusions are counted in the limit multiple times. We're hitting the limit much faster than we should be.

If we add "subst:" when including templates, the content of the template is added to the page when saving. If we changed object pages to

{{subst:Object|ClassName}}

This page would only include the object page, without the nested inclusions. Is this the sort of generation you're looking for MrDoom? --Sncplay42 21:39, 29 August 2010 (UTC)

I've solved the issue. My ifexist template is a memory hog, so I've tricked a bunch of pages into shrinking. Works properly now. Might have to do some purging

NXTBoy (talk • contribs)

14:37, 30 August 2010 (UTC)

Actually I want to explore Snc's subst option a bit further. If it's doing what I'm reading it should in theory drastically reduce the load time of the page. Going to play with it. ---User:Mr Doom Bringer (Talk) 04:39, 31 August 2010 (UTC)

Neat! I noticed an actual improvement in the speed of the page loading once it saved. This is actually rather nice. ---User:Mr Doom Bringer (Talk) 04:58, 31 August 2010 (UTC)

Yeah, but it won't auto-update. You don't want to subst each object page into there. Only do that, if at all, when ALL objects are FULLY documented

NXTBoy (talk • contribs)

07:57, 31 August 2010 (UTC)

Edit page directly?

The comment in the page says "NOTE: Do NOT edit this page. Instead, edit the Template page, which will soon autogenerate this". Does this still apply? --SNCPlay42 17:13, 14 September 2010 (UTC)

Erm, the other page DEFINITELY need editing. However, there are some big problems with the main page: it is still gonna be too big, especially if autogenerated. Once MrDoomBringer installs ParserFuncions, things might be compacted a bit. At present, my pseudo-ParserFunctions roughly double the size of every object page.

NXTBoy (talk • contribs)

15:44, 15 September 2010 (UTC)

When will we be seeing this page use the ClassReference template? Camoy • Contribs (December 27 2010)

Ok, I'm thinking to reduce the load time, we go for only showing the new members on this page, and not the inherited members. It's the inheritance that causes the overload. Does this sound like a reasonable approach?

NXTBoy (talk • contribs)

16:45, 28 December 2010 (UTC)

What do you mean new members? I think we should have a tree-like structure (like Anaminus' object tree page), except it won't have any of the methods, properties, or events. Just a folding tree widget that links to the object page itself. That seems okay. I myself don't unfold the members in the class reference that often. I usually just go to the page from there. Camoy • Contribs (January 2 2011)

As in members which originate from that class. Yeah, tree view would be good as well.

NXTBoy (talk • contribs)

14:57, 2 January 2011 (UTC)