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
