User talk:Anaminus/API Documentation Changes: Difference between revisions

From Legacy Roblox Wiki
Jump to navigationJump to search
>Tomtomn00
>Quenty
No edit summary
Line 4: Line 4:
:I would be tempted to go for {{`|Object}}. API is a reasonable fit as well. {{User:NXTBoy/sig|date=08:26, 5 May 2012 (UTC)}}
:I would be tempted to go for {{`|Object}}. API is a reasonable fit as well. {{User:NXTBoy/sig|date=08:26, 5 May 2012 (UTC)}}
:: I initially went against {{`|Object}} because member pages would be included under the namespace, but they're not "Objects". Thinking about it just now, since a member page would only be a subpage of an object page, {{`|Object}} may work after all. --[[User:Anaminus|Anaminus]] 04:37, 5 May 2012 (EDT)
:: I initially went against {{`|Object}} because member pages would be included under the namespace, but they're not "Objects". Thinking about it just now, since a member page would only be a subpage of an object page, {{`|Object}} may work after all. --[[User:Anaminus|Anaminus]] 04:37, 5 May 2012 (EDT)
::: I like API.  Its nice and short, and make sense. {{User:Quenty/sig|date=May 7}}


==Possible implementation, retaining autonomy==
==Possible implementation, retaining autonomy==

Revision as of 00:52, 7 May 2012

"API" Namespace

Does "API" make a good name? Does it describe the contents of the namespace? (a reference/documentation of Roblox classes) Alternatives might be "ClassRef", or "ObjectBrowser", I'm not really sure. Any suggestions? --Anaminus 01:41, 5 May 2012 (EDT)

I would be tempted to go for Object. API is a reasonable fit as well.
08:26, 5 May 2012 (UTC)
I initially went against Object because member pages would be included under the namespace, but they're not "Objects". Thinking about it just now, since a member page would only be a subpage of an object page, Object may work after all. --Anaminus 04:37, 5 May 2012 (EDT)
I like API. Its nice and short, and make sense. - Quenty (talk • May 7)

Possible implementation, retaining autonomy

I've had a go at building a new template backend for a system like this. Unlike the old one, the data goes on the same page as the one presented to the user, and there are no auxiliary pages like /superclass and /properties. Have a look at them at User:NXTBoy/Instance, User:NXTBoy/BasePart, and User:NXTBoy/Part

09:29, 5 May 2012 (UTC)
If unique and inherited members are going to be separated anyway, why not just completely remove inherited members and link to the superclass instead? --Anaminus 17:05, 6 May 2012 (EDT)
So that the viewer can instantly see which superclass they need to look at, rather than navigating further and further up the tree until they find the member they want.
21:10, 6 May 2012 (UTC)
Great idea: get all of these done. Like you LocalSettings.php idea. --~ ⇒TomTomN00 @ 21:19, 6 May 2012 (UTC) 17:19, 6 May 2012 (EDT)
That makes sense. Though I dislike that the wikitext looks nothing like the page. I find it to be confusing and somewhat intimidating. --Anaminus 17:28, 6 May 2012 (EDT)
I don't think I can make it any simpler, short of perhaps replacing {{{1}}} and {{{2}}} with more descriptive names. I think it would be ok providing some HTML comments were put around it explaining what to do.
21:42, 6 May 2012 (UTC)
Actually, it's too simple. It needs more arguments on the properties to allow sensible autonomy.
21:57, 6 May 2012 (UTC)

Opinion

I agree with every single thing you've said on this page, except the following:

  • I think the API namespace should instead be named the Documentation namespace.

Also, I have the following suggestions:

  • Showing deprecation by putting a line through the object or member name, showing preliminary with italic text. These conventions are what the object browser uses, anyway.

And here are some remarks:

Making this system work might require complex template manipulation or might even be impossible to do automatically, but, really, your idea is so well-thought that it'd be worth it. Using namespaces and subpages gives us technical advantages provided by MediaWiki, such as being able to get the name of a member or object easily, or such as being able to list all the members specific to a class through the special pages.

Also, we really really really really need the ParserFunctions extension. We really need it. It would make templates easier to make, reduce the load time of these and give us more technical features that we didn't have before.

And here are some remarks concerning the disambiguation:

I think the disambiguation should be done with the templates I added on the wiki not long ago, which are identical to what Wikipedia uses. And I think we should choose the third option you mentioned, a mix of both redirecting and disambiguation pages. --JulienDethurens 14:01, 5 May 2012 (EDT)

"Documentation" seems a bit long for a namespace. It also doesn't really describe what it contains. Documentation of what? Anything? "Object" as a namespace makes more sense to me.
If you look at the mockup I provided, it takes preliminary and deprecated objects into account. Though that's more related to appearance anyway, so it doesn't need to be included in this outline.
If we were to wait out for the Lua extension to MediaWiki in place of using templates, it would provide cleaner, faster implementations. I'll experiment with it. --Anaminus 17:19, 6 May 2012 (EDT)

My Oppinion

I would support this happening, but it sometimes does take a while for them to update LocalSettings.php and add new extensions. --~ ⇒TomTomN00 @ 21:25, 5 May 2012 (UTC)