Stéphane, Your suggestions regarding the Point Editor are also very helpful. I will make a sheet for PointClass as it will be much better. I will do the same with Shape Editor and ShapeClass as leaflet easily converts map items to GeoJSON.
Best, Fawad On Thu, Aug 1, 2019 at 11:54 PM Fawad Ali <m.fawaadal...@gmail.com> wrote: > 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 >> >>
