Stéphane, I agree that GeoJSON would be a much portable and standard option. I went with the structure I implemented because I was directly working with leaflet docs. I have one concern though and that is the flexibility of GeoJSON. By flexibility I mean that it will be harder for XWiki users to get used to the GeoJSON as opposed to the "points" and "options" properties of ShapeClass. Nonetheless, I am going with the GeoJSON now.
Best, Fawad On Thu, Aug 1, 2019 at 11:37 PM Stéphane Laurière <slauri...@xwiki.com> wrote: > 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 > >
