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)

I was looking at the Category Tree extension. Instead of attempting to load everything at once it, as it says, loads parts of the tree on demand. It would require extra resources, but I think it would be really neat to apply a similar method here. If someone whips up something really neat, it might convince a certain someone to add those extra resources. --Anaminus 15:08, 2 January 2011 (UTC)

As you can see, I mentioned retrieving member lists with AJAX previously. Problem is, there's no way of easily testing such an add-in: User js files doesn't seem to be enabled on this wiki. Also we still seem to be missing any users with server access

NXTBoy (talk • contribs)

15:28, 2 January 2011 (UTC)

Yeah async requests are the way to go to not overload the page with information... Camoy • Contribs (January 2 2011)

I was thinking of doing a similar thing with the object pages themselves, loading member information only when they are clicked on.

Templates

Shouldn't we need to change the page so that it uses the Object template completely instead of a mix of the ObjectList and Object templates? Plus, the ObjectList template is deprecated still uses the Name_(Function) pages which don't exist for new methods. Legend26 (talk | contribs) 01:17, 23 December 2011 (EST)

Template for auto-generating services on the reference page?

Does such a template for auto-generating objects into the class reference page exist? We have Template:ClassReference, perhaps Template:ServiceReference ?

Because I really do not want to do that. Objects that are no longer documented the old way (i.e, old classes) but are included in this section are...

Physics Objects	Player Objects
AutoJoint	LocalBackpack LocalBackpackItem Stats CharacterMesh

Network Properties
NetworkReplicator NetworkServer

There are also objects not included at all, including TweenService, and possibly others that I can't think of off the top of my head.

Something different.

Julien has suggested that there is a better way to accomplish the goal of this page, ie redirecting to Category:ROBLOX Lua Objects. Anybody have any thoughts on that. I'm a little fond of this page, but I'd like to hear what everybody thinks. Thanks!--Gordonrox24 | ^Talk 20:39, 4 May 2012 (EDT)

Do whatever you want, but, please, don't keep this abomination there one more second. As it currently is, I'd literally say it is harmful to the wiki. It uses the old object documentation system, it takes two years to load, it doesn't even list half the objects that exist and it is just a pure mess in general.

Now that I've complained about how horrible it is and everything... well.. I'm not sure what else we could do with it than redirecting it to the category. Of course, we have the {{ClassReference}} template, but it becomes outdated every time the admins add an object. In fact, all of these problems all come back to a main problem: the object documentation system itself. We'd need to make a completely new one, but that'd require a lot of work. We currently have problems when many properties, methods or events have the same name. We also need to change the currently ridiculous name of objects and perhaps separating the object documentation into separate namespaces would be a good idea too. --JulienDethurens 22:57, 4 May 2012 (EDT)

I've been working on a few proposals that address these issues. I've posted them here. --Anaminus 01:40, 5 May 2012 (EDT)

As for this page, I've been thinking that grouping classes together might be the way to go. For example, some groups might be Parts, Values, Bodies, and GUIs. I attempted grouping classes together when I made that navbox. --Anaminus 01:49, 5 May 2012 (EDT)

Whose idea was it to name the pages RBX.lua.{Name} (Object) anyway? I have to agree with Julien, the current version needs to be replaced. Something like the navbox that anaminus linked to above is probably the most user friendly and fastest loading page we can get. Listing all the members of each object on this page only puts however much stress on the wiki servers and the seer size of the page dissuades anyone from updating it. Legend26 (talk | contribs) 02:24, 5 May 2012 (EDT)

Note that {{ClassReference}} is currently used to generate the derived classes box, so should be kept up to date.

NXTBoy (talk • contribs)

08:23, 5 May 2012 (UTC)

The {{ClassReference}} template is just another flaw of the current object documentation system. The idea suggested by Anaminus would fix that issue. Of course, changing the whole object documentation system would require an incredible amount of work, but it'd be worth it. As for the idea of grouping instances like in Anaminus's navbox, that'd be an excellent idea. Grouping instances together would be very user friendly, and, though it would require to be manually updated, would still be a lot nicer than both the category and what the current ClassReference page offer. --JulienDethurens 14:05, 5 May 2012 (EDT)

{{ClassReference}} is the only sensible way to automagically create a derived classes box. You could argue that such a box isn't really needed, but if it were, it would be a maintenance nightmare to do it by hand.

NXTBoy (talk • contribs)

19:06, 5 May 2012 (UTC)

The reason it would be a nightmare is because of the complexity of the templates. You're trying to use templates for a job they're simply not meant for. My page content proposal is a step back; it sacrifices all concepts of automation in order to have an opaque model that's easy to understand, and therefore can be easily edited and managed by anyone.
If you want this wiki to step forward while keeping such automation, then the only real solution is to either create an extension specifically for this wiki, or install an existing extension that can handle the job (I've been looking into this a bit, and Semantic MediaWiki might be a possible solution). Waiting until MediaWiki comes out with Lua modules may also be a better solution. I'd love to have documentation that generates automatically; I'd also love for it to be simple. I'd choose the latter over the former, but having both would be even better. --Anaminus 17:07, 5 May 2012 (EDT)

I think you mean a transparent model. I think autonomy can be achieved with simpler templates.

NXTBoy (talk • contribs)

21:53, 5 May 2012 (UTC)

How so? If you're referring to User:NXTBoy/Part, I spent quite a while trying to figure out how that works, which says something about its simplicity. My definition of simplicity involves "flat" transclusions, or transclusions that don't transclude anything else. --Anaminus 18:35, 5 May 2012 (EDT)

I'm sure the ParserFunctions extension would make a lot of things possible... Not that, of course, but it'd make lots of things possible and easier. --JulienDethurens 15:44, 5 May 2012 (EDT)

I've been asking for those ever since I joined the wiki. That was two years ago. Since then, I've worked out how to use obscure tricks to emulate most of the useful parserfunctions. Having said, that, I still want them as much as I did two years ago - the {{#if:}} parserfunction should be more efficient than my {{if}} template, and having the string parsing built into ParserFunctions really would be awesome. More awesome though is the current plans by MediaWiki to abolish most of the templating system in favor of lua code.

NXTBoy (talk • contribs)

20:49, 5 May 2012 (UTC)

I actually disagree with that. There's a difference between markup languages and programming languages and what they're planning to do is to change from a markup language to a programming language. Yet, I feel a markup language is more appropriate for what they're trying to do. And even if it had been a good idea, I would have preferred JavaScript instead of Lua. --JulienDethurens 16:56, 5 May 2012 (EDT)

Wikimarkup goes further than a markup language - it's too powerful. The fact that I can write if and switch statements emphasizes that. Better to use a programming language to program than to coerce a markup language to do it. Also, sometimes a programming language IS a markup language - XSLT, for instance. I too would have preferred javascript, but it was decided to be unsuitable. Lua isn't too awful. Also, http://www.mediawiki.org/wiki/Extension:Lua. We need this.

NXTBoy (talk • contribs)

21:01, 5 May 2012 (UTC)

Mediawiki will eventually use Lua. I do agree that Anaminus has something correct. And, Media's wiki markup ISN'T good enough for what we're trying to do here. If we do use the Lua extension, make sure it's markup corresponds with Mediawiki's new markup w/ Lua. - Quenty (talk • May 5)