Hi all,
Hope everyone is well.
Please review the application developed so far. I have included a UI test
and map states. I think we should release the application as soon as we can
so that user reviews can be gathered.
Best,
Fawad
On Mon, Jul 1, 2019, 8:26 PM Fawad Ali <m.fawaadal...@gmail.com> wrote:
> 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
>>
>>
