Hi, I am out of the country and won't have access to fast Internet in the following 2 weeks, so I won't be able to participate in the call. Sorry.
Caty On Thu, Aug 1, 2019 at 10:03 PM Fawad Ali <m.fawaadal...@gmail.com> wrote: > Stéphane, Ecaterina, > > About the call, I think we should have it so that we all converge on the > things to be done. > However, tomorrow (Friday), I have a call with the Pakistan's GSoC > community at about 5 PM UTC. If the call will be finished in two hours I am > fine with it or we could reschedule it to 2:30 PM UTC or else Monday. > > Best, > Fawad > > > On Thu, Aug 1, 2019 at 11:58 PM Fawad Ali <m.fawaadal...@gmail.com> wrote: > >> 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 >>>> >>>>
