30 Jul
2019
30 Jul
'19
8:46 a.m.
Hi Fawad,
I would go for approach C as well, that is storing all shape data entirely in json, since
most probably the shapes will either by imported directly from preexisting data in json or
any equivalent, or drawn by hand on a map. I see no real use case yet for an intermediary
input where part of the data would be entered via a form, then by hand. Query-wise, I
don't think we will need to retrieve a huge quantity of shapes with any given property
value that would need to break down some specific values into dedicated properties. In
case we do some day, we could either build a dedicated index I would say, or fill in
dedicated properties automatically from the json input via a listener.
Cheers,
Stéphane
Hi Stéphane, Ecaterina and everyone,
Hope you all had a wonderful weekend.
So I am working on shapes and wanted to know how I should deal with the large number of
options for each shape type. As expected, the options are different for each shape type.
I have multiple approaches in mind for this:
*Approach A:* Using the normal properties of XClass, create all the options for a shape
type as properties for that class. This will in turn increase the class size as a lot of
options will exist for each shape type.
*Approach B:* Use a static list or array to define the value of each shape type option. I
have tried and it seems we cannot make use of key value pairs in static list or any other
data type in XWiki so I am not completely sure of the implementation using static lists.
*Approach C:* Create a single TextArea property for options in each shape type class. The
user can pass a JSON of options in that TextArea. Imho I prefer this approach since JSON
is a standard format and it will give the user freedom of which options to use.
WDYT?
Best,
Fawad Ali