Fawad, Caty, I had mostly technical aspects in mind when proposing a call, I overlooked that UX and design also need to be discussed so that we make sure to align our views for the upcoming weeks. Let's see in a private channel how we can align our agenda to make this happen, if you feel like it. Apologies for having acted a bit in a rush.
Cheers Stéphane
Hi all, The setup for shapes has been done. What I have in mind now is to have a Shape Editor similar to the Point Editor with interactive tools to create shapes. Stephane, if you have anything else in mind for interactively creating shapes then please let me know so that we are on the same page. I will work on it as fast as I can so we can move on to the implementation of Indoor Maps. Best, Fawad Ali On Tue, Jul 30, 2019 at 11:46 AM Stéphane Laurière <slauri...@xwiki.com <mailto:slauri...@xwiki.com>> wrote: 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
-- Stéphane Laurière XWiki – https://xwiki.com
