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
