Property talk:Has item type

Change proposal

Now, I'm considering changing this property to type "String" (type "page" has an automatic wikilink whenever called, and type "string" does not), but this property is set on 22722 pages so I'd like to gather any opinions before making the change.

I've repurposed this property from the weapon, trinket and armor infoboxes to include values from more precise item types (e.g. if the item "Has weapon type=Axe", then "Has item type=Axe" too), but unfortunately where the value is a redirect it stores the destination page instead of the source. Example: If I set [[Has item type::Gloves]] then the value is stored as [[Has item type::Equipment]] because Gloves redirects to Equipment. As far as i'm aware this would be a selfish change which would fix the vendor table row template without any real effort.

The first alternative to this is to reconfigure {{vendor table row}} and {{vendor table row result format}} to ask for the other properties but fallback to item type (this method still results in 4 additional properties being asked for which we could avoid). The second alternative is to revert my changes to the weapon, armor and trinket infoboxes, but this will mean that the tables on Scholar Glenna won't work as intended (currently they use a lightweight version of vtr because the subobjects prevent the page being edited. In response to the second alternative, we could hardcode the item type on the Scholar Glenna page.

My personal preference is to change this property to type String and be done with it, and then I'll add links to any infoboxes that need fixing later. -Chieftain Alex 19:56, 26 March 2016 (UTC)

The weapon, trinket, and armor infoboxes are equipment subtypes. Equipment itself is an item type. Identifying Has weapon type and Has item type is redundant and indicates bad design. That's pretty much what you refer to when you say "more precise item types" and using item type as a fallback. The current solution is having properties like Has equipment supertype or hardcode an #arraymap, which are more like hacks. The reason Has item type is a page property is because the item type is guaranteed to have a page, same with Has weapon type. This is powerful because it allows us to do subqueries. I'm not sure why we redirect our armor types to the equipment page, it should at least redirect to armor. I'd rather create a page for each armor type and something we should do anyways.

We can look at trying out subproperties again since SMW has been upgraded. This would have addressed these issues already but we couldn't get them working.--Relyk ~ talk < 20:53, 26 March 2016 (UTC)

I'm not sure if subproperties are going to help in this case (they do sound neat but are not going to address this problem I think - you can't query for the parent subproperty and return the children if they exist as replacements for the parent). Targeting the query isn't the problem, even if it is bad design to set both properties.

What I want to do is reduce the number of queries in {{vendor table row}} for each row from 10 properties to 6 properties (ignoring the item icon template at the moment):

|?Has armor weight class
|?Has item type
|?Has armor type
|?Has weapon type
|?Has trinket type
|?Has upgrade component type
|?Has item rarity
|?Has level requirement
|?Has equipment prefix
|?Has upgrade component

to

|?Has armor weight class
|?Has item type
|?Has item rarity
|?Has level requirement
|?Has equipment prefix
|?Has upgrade component

the purpose of which is to reduce template footprint and allow more templates per page without producing 502 errors.

I guess another route to this would be to use a different result format template + different query depending on the header options, so that if for example the facts column is hidden then we don't query for facts. -Chieftain Alex 11:36, 27 March 2016 (UTC)