1 Aug
2019
1 Aug
'19
8:58 p.m.
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.fawaadali98(a)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 <slauriere(a)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 <slauriere(a)xwiki.com
> <mailto:slauriere@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
>
>