28 Jun
2019
28 Jun
'19
12:02 p.m.
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/a…
)
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