Hi everyone,
Hope to find you well.
Their flow is actually completely in line with what I have in mind as well
> (except I may prefer personaly to have the facet above the result list
> items, to be discussed...)
>
That would certainly be better in my opinion.
I would expect the search button to be closer to the area where the widget
> pops in, that is on the left side in our current setup, what do you think?
It was that way in the previous commits. But the idea of this approach is
to have the left side completely blank with no controls. What it helps in
is to provide a dedicated space for both the popup and search widget. If we
place the search control on the top left, our search control is hidden when
either popup or the search widget is enabled. And if we place the search
widget right beside the search control (to the right of it), it will take
unnecessary space.
One option is to have the close icon to the right of the search widget
popup but it still doesn't fix the problem of search control hiding when
the marker popup is opened.
Indeed, that's an issue. Regarding facets, page Main.SolrSearch behaves
> similarly as far as I understand, and manages to keep the facets in the
> same state visually as how they were before launching the asychronous call,
> doesn't it? So I was thinking we could use the same approach, or is there a
> hidden complexity? As for the search input: the input itself can be
> retrieved from the URL, so we should be able to restore it as well, don't
> we? Can you clarify how separating in two distinct services may help? We
> will need to consider the other states of the map that we want to represent
> in the URL so that specific map states can be shared easily, we could add
> the current selection to the URL's fragment, what do you think?
>
That's exactly what I eventually had in mind besides the JSON service. For
the JSON service, we could have a common place for retrieving any kind of
map data, like a REST API but that was the secondary approach.
What we could do now is utilize the URL parameters. For now, I am thinking
of having a multiple URL parameter that can contain different states of the
map. For example, if we have both the fullscreen and search popup enabled,
we could have the URL parameters "?mfullscreen=true&msearchw=true" where
mfullscreen = map full screen and msearchw = map search widget. Other
parameters like this can be added for different states. WDYT?
We came up with a possible workaround with Anca, which consists in using
> the Velocity "evaluate" macro in order to force the usage of the current
> Velocity context (replace "scriptPage" by "facetDisplayer"):
>
> #set ($script =
> $!scriptPage.content.replaceAll('\{\{/{0,2}velocity\}\}', ''))
> #evaluate($script)
>
> I gave a try to this solution and it worked fine on my end on the example
> mentioned on the forum (not tested yet with the facetDisplayers). We need
> to investigate further though:
That's great, I will check it out as soon as I am able.
Best,
Fawad
On Fri, Jun 28, 2019 at 3:02 PM Stéphane Laurière <slauri...@xwiki.com>
wrote:
> Hi Fawad, Caty, all,
>
> Apologies for the delay. Meantime, I confirm that Caty and I filled in the
> 1st GSoC evaluation for the period, with very positive appreciations.
> Thumbs up Fawad, and good luck with the next steps.
>
> Fawad Ali:
> > Hi Caty, Stephane and all,
> > Hope you are all well.
> >
> > Stephane, your suggestions regarding the filter and search are great but
> I
> > feel the flow of our application is more inclined towards what Ecaterina
> > proposes. I will try implementing the mockups.
>
> That's very helpful to have mockups indeed to align the visions. Their
> flow is actually completely in line with what I have in mind as well
> (except I may prefer personaly to have the facet above the result list
> items, to be discussed...), and I see in the latest version (of today) that
> you made good progress toward that direction. The fullscreen widget is cool
> and works fine. I would expect the search button to be closer to the area
> where the widget pops in, that is on the left side in our current setup,
> what do you think?
>
> > One problem we have though is that both our facets and search lead to a
> > reload of all the content inside the page asynchronously which means any
> > changes made through frontend are lost (like active dropdowns etc.). We
> > need to fix this.
> > Do you think I will have to redo both as a separate JSON service? I can
> > think of a way for search but facets are a little confusing.
>
> Indeed, that's an issue. Regarding facets, page Main.SolrSearch behaves
> similarly as far as I understand, and manages to keep the facets in the
> same state visually as how they were before launching the asychronous call,
> doesn't it? So I was thinking we could use the same approach, or is there a
> hidden complexity? As for the search input: the input itself can be
> retrieved from the URL, so we should be able to restore it as well, don't
> we? Can you clarify how separating in two distinct services may help? We
> will need to consider the other states of the map that we want to represent
> in the URL so that specific map states can be shared easily, we could add
> the current selection to the URL's fragment, what do you think?
>
> > Also, we still haven't found a way to fix the $facetDisplayer problem.
> > (
> >
> https://github.com/xwiki-contrib/application-interactive-maps/blob/master/application-interactive-maps-ui/src/main/resources/Maps/Code/CommonMacros.xml#L221
> > )
> > How do you think we should proceed with this?
>
> We came up with a possible workaround with Anca, which consists in using
> the Velocity "evaluate" macro in order to force the usage of the current
> Velocity context (replace "scriptPage" by "facetDisplayer"):
>
> #set ($script =
> $!scriptPage.content.replaceAll('\{\{/{0,2}velocity\}\}', ''))
> #evaluate($script)
>
> I gave a try to this solution and it worked fine on my end on the example
> mentioned on the forum (not tested yet with the facetDisplayers). We need
> to investigate further though:
>
>
> https://forum.xwiki.org/t/including-code-dynamically-from-a-sheet/5085/3
>
> > Regarding the tests, I will start preparing them as soon as I am done
> with
> > implementing the new search and facets UI.
> > However, I do have confusion as to what kind of functional tests I should
> > perform. I am listing some that I have in mind.
> > - Map is created properly
> > - Facets are working
> > - Search returns expected results
> > - Popup works fine
> > And other similar functions.
> > I will need some guidance as to how I should take a start since I have
> not
> > actually made tests for real applications.
> > After analyzing some of the tests that Vincent and Ecaterina have
> shared, I
> > think we have to perform user actions programmatically and check to see
> if
> > the output we are receiving is correct. Is that right?
>
> I need to look more into the testing framework including the pointers and
> examples provided by Vincent and Caty, and to go through the steps you
> mention in your mail dated from 24/6, I'll get back to you on this.
>
> Cheers
>
> Stéphane
>
>
> > Thanks,
> > Fawad
>
>
