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