Hi all.
Currently, a PropertyValueSnak knows the ID of the property it refers to, and
the DataValue object representing the actual value. The DataValue has a "low
level type" used (in the future) by the storage and indexing layer. But whenever
we want to render or validate a snak, we need the prop
-1
Had to deal with this in the frontend as well and don't think this is
inconvenient. It seems like the cleanest approach. Polluting the Snaks
with information like this for performance or convenience reasons will
probably cause more trouble in the end than keeping it as simple and "pure"
as pos
Hey,
Putting the DataType id in PropertyValueSnaks at this point seems like a
bad idea for several reasons. Doing so would cost us quite some work end
end up with a more complicated system as foundation. If you have a use case
for which the current code is not well suited, I suggest writing new co
Am 13.06.2013 06:38, schrieb Jeroen De Dauw:
> Hey,
>
> Putting the DataType id in PropertyValueSnaks at this point seems like a bad
> idea for several reasons. Doing so would cost us quite some work end end up
> with
> a more complicated system as foundation.
Changing it now would be hard.
Bu
Am 13.06.2013 03:22, schrieb Daniel Werner:
> -1
> Had to deal with this in the frontend as well and don't think this is
> inconvenient. It seems like the cleanest approach. Polluting the Snaks with
> information like this for performance or convenience reasons will probably
> cause
> more troub
How would you use that additional type information?
A PropertyValueSnaks (PVS) referencing a certain property can still have
ANY value of ANY value types, e.g. a value not necessarily matching the
property's data type's data value type. This is something all code should
consider and handle well.
I
Am 15.06.2013 01:17, schrieb Daniel Werner:
> How would you use that additional type information?
For rendering the value, mainly. It seems awkward that I would have to look up
the property's data type in order to render a value associated with that
property. Who sais that values can not exist wit
2013/6/16 Daniel Kinzler
> > - The data type of the property could have changed (we don't support
> changing
> > that as far as I know but I'd always consider it). So you still had to
> fetch the
> > property to compare its current data type with the one of the snak.
>
> Why would I have to check
Hey,
I agree with Daniel Werners last post, though it looks like it has 2 typos
in it. Will highlight them to avoid confusion:
> Just having the data value, taking its *data type* and using a standard
formatter for that data value type would be sufficient
"data type" should just be "type".
> Wi
2013/6/17 Jeroen De Dauw
> Hey,
>
> I agree with Daniel Werners last post, though it looks like it has 2 typos
> in it. Will highlight them to avoid confusion:
>
>
> > Just having the data value, taking its *data type* and using a standard
> formatter for that data value type would be sufficient
Am 17.06.2013 14:02, schrieb Daniel Werner:
> I am in favor of always displaying existing values if possible, even if it is
> not valid against the current definitions (property/datatype) anymore.
> BUT, if the value is not valid against the definition anymore, in many
> situations the display of t
11 matches
Mail list logo
