Re: Javascript data types

I agree with those arguments, but I don't think a custom script is a good
solution.

I am fairly certain that the desired flexibility can be achieved by:

(a) Creating a new parent category and making the following sub-categories
of it: Javascript data types; Javascript objects; and DOM objects/interfaces

(b) Setting the form to generate the option list from all pages in the new
parent category (
http://www.mediawiki.org/wiki/Extension:Semantic_Forms/Defining_forms#Autocompletion
).

(C) Changing the property type from "enumeration" to "page" and removing
the "allowed values" list

There would probably also need to be some changes to the templates so that
the object type only shows up as "RangeError" and not
"dom/Selection/RangeError" (the full page name).

The net result would be that if you wanted to list a given object or
interface type as the return value of a method, all you would have to do is
make sure that a reference page for that object or interface existed and
was properly categorized.

If anyone with a love of all things Semantic MediaWiki (or a desire to
learn!) is able to make that happen, please do.  Feel free to contact me
directly if you want to bounce around ideas about how to implement it.

If no one else takes control, I will look at it more closely later in the
summer when I start working on the SVG templates.

AmeliaBR





On 14 July 2014 12:22, PhistucK <phistuck@gmail.com> wrote:

> This is a major obstacle at the moment (and has been since the beginning),
> unfortunately.
> I do not think this should be a closed list. Any interface, prototype or
> class can be a "javascript data type". We should not need to explicitly add
> types, this does not scale and makes contributors needlessly dependent on
> administrators in order to finish articles.
> If it must be a closed list (or if it cannot be updated at real time) due
> to a Wikimedia/Semantic Wiki limitation, then perhaps an automated script
> that runs every night or every hour and updates this list according to all
> of the API Interface (I am not sure regarding the name of the page
> template, sorry) names.
>
>
> ☆*PhistucK*
>
>
> On Mon, Jul 14, 2014 at 8:33 PM, Julee Burdekin <julee@adobe.com> wrote:
>
>>  Hi, Rob!
>>
>>  There is a Range object in the spec.[1] So I would add it. But where? I
>> noticed the ES6 draft separates out the language & specification types.[2]
>>
>>  Maybe we should have a separate type section for specifications?
>>
>>  What do others think?
>>
>>  J
>>
>>  [1]
>> http://www.w3.org/TR/DOM-Level-2-Traversal-Range/ecma-script-binding.html
>>  [2] https://people.mozilla.org/~jorendorff/es6-draft.html (see table of
>> contents)
>>
>>  -------------------
>> Julee Burdekin
>> Content Strategist
>> Adobe Web Platform
>> @adobejulee
>> julee@adobe.com
>>
>>   From: Rob^_^ <iecustomizer@hotmail.com>
>> Date: Monday, July 14, 2014 at 1:35 AM
>> To: WebPlatform Public List <public-webplatform@w3.org>
>> Subject: Javascript data types
>> Resent-From: WebPlatform Public List <public-webplatform@w3.org>
>> Resent-Date: Monday, July 14, 2014 at 1:36 AM
>>
>>    Hi,
>>
>> re: http://docs.webplatform.org/wiki/dom/Range/cloneRange
>>
>> as Range and RangeError are not in the list at
>> http://docs.webplatform.org/wiki/Property:Javascript_data_type
>>
>> I end up with a nonsense Return Value description....
>>
>> “Returns an object of type Object”
>> [object Range]
>>
>> I am pressed for time, so I have flagged the item as almost ready....
>> awaiting Range object to js data-types.
>>
>> Comments/Advice?
>>
>> ...seems to me that the js object types should be open to editor
>> discretion as ‘objects’ can be anything one wants....
>>
>> var WPO={‘toString’:function(){return ‘[object WPO]’;}}
>>
>> there are ‘core’ data-types... number, date, boolean, string, regex and
>> Array, but what were once ‘object’ can now be [object Anything]
>>
>> eg. var test=2; typeof test returns ‘number’
>>
>> Regards.
>>
>
>