1 Aug
2019
1 Aug
'19
8:54 p.m.
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
--
Stéphane Laurière
XWiki – https://xwiki.com
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