The result looks very nice!
The loading time seems a bit long, probably because of the entire page
rendering, but that should not be a big problem.
Thanks,
Eduard
On Tue, Feb 19, 2019 at 9:52 AM Stéphane Laurière <slauriere(a)xwiki.com>
wrote:
Hi Eduard, Hi devs,
I'm following up on this discussion which I had left aside for a while:
Eduard Moraru:
Hi, Stephane.
On Tue, Aug 28, 2018 at 10:49 AM Stéphane Laurière <slauriere(a)xwiki.com>
wrote:
Vincent Massol:
Hi Stephane,
> On 28 Aug 2018, at 08:55, Stéphane Laurière <slauriere(a)xwiki.com>
wrote:
>
> Hi all,
>
> I would like to contribute an extension that will display page preview
popovers when hovering wiki links, similarly to what MediaWiki offers:
>>
>>
https://www.mediawiki.org/wiki/Page_Previews
>>
https://blog.wikimedia.org/2018/05/09/page-previews-documentation/
Sounds like a nice extension!
However, how are you going to extract the "summary" of a page? In
Wikipedia, pages have a certain structure and, at the beginning of each
page, you have at least the first paragraph that is describing the
resource. Even the Wikipedia API allows you to get the "extract"
(summary/topic) of a page and that is what the Wikipedia feature is using
as text content to display in that preview popup.
In XWiki, the usecases are not defined and you could have anything
inside a
page. Do you plan to show the entire page content
inside that preview? Do
you plan to have an empirical approach in order to get some sort of
summary
by e.g. displaying just the first paragraph as
well? What's the approach?
My proposal would be to make the approach configurable, so that the
preview could be anything ranging from the full page to any element of the
page. The default configuration could consist in displaying 1) the first
block that matches one of the following: Paragraph, List, Quotation, Table.
2) the first image attached to the page, if any. What do you think?
In a second step, that could be nice to let the users define custom
configurations to adapt the previews to their needs.
Sounds nice. Do you plan to implement it as a Rendering Transformation
(similar to
what the Glossary app do) or as Javascript code?
Definitely JavaScript + REST API would be the way to go here, to avoid
rendering, at display time, all the linked pages on the server side. Each
preview should be obtained when the user asks for it, i.e. when
displaying
the preview. Optimisations could be done to
prefetch the data, but that
would also increase the network traffic and server load, while improving
the user experience (i.e. not having to wait for the preview popup to
load
its content).
OK great, we agree on JavaScript then. I published a first experiment,
welcoming code reviews and also feedback regarding the user experience:
https://github.com/xwiki-contrib/application-page-preview
https://dev.xwiki.org/xwiki/bin/view/Drafts/Page%20Preview%20Application
At the moment, the code is using a dedicated service rather than the REST
API because it allows some flexibility such as the ability to display in
the preview the first image attached to the target page even if it's not
present in the content itself (this is probably something that should be
made configurable).
In a first try, I had extracted the preview on the server side using the
XDOM API. However, following a discussion with Anca, I realised that it's
probably more efficient to send the whole page rendered content and to let
the client display only part of it.
> Actually I had not considered the rendering
transformation option. At
> first glance, plain JavaScript code seems more lightweight to me without
> any downside but if you see pros for using a transformation, please let
me
> know. There's one issue with plain
JavaScript at the moment though: the
> Bootstrap popover feature in version 3.x adds a div next to the clicked
> element. In our case, this means adding a div to the surrounding
> span.wikilink, which is not allowed in HTML5. However, Bootstrap 4
popovers
> work differently: they're added as direct
childs of the body:
>
https://getbootstrap.com/docs/4.0/components/popovers/ so the issue
will
be fixed
once we migrate. What do you think? Can we live with a div ina
span for now?
I'm not really sure what you mean. When the popover is displayed, a divis
indeed created with javascript and added as sibling to the popover
trigger
element. If you make the "span" element
the trigger instead of the link,
then you would get perfectly valid HTML. Example with Bootstrap 3:
http://jsfiddle.net/vqT5f/1322/
You're right, I had certainly tried to add a popover the "a" element
indeed, thank you for your help.
Stéphane
Thanks,
Eduard
>
>>> Its name could be 'application-page-preview-popover' - what do you
> think? As discussed with Caty yesterday, the extension will use the
> Bootstrap popovers. Should you have any need or suggestion, please letme
> know.
>>
>> So it depends on the technology you wish to use. If it’s a
> transformation, I would name it "transformation-preview”. If it’s
> JS/webjar, I guess you’ll need a JSX object to load it so I guess
> "application-page-preview” would be fine.
>
> I see, but in any case, with or without a transformation, I think we
will
> need some JS + CSS code anyway, won't we?
As far as I can see, the
glossary
> extension is an application containing a
transformation, so we could go
for
> "application-page-preview" as well,
with or without transformation,
what do
> you think?
>
> Stéphane
>
>
>> Thanks
>> -Vincent
>>
>>> If the name is ok, can I ask you for the creation of a repository and
> JIRA project?
>>>
>>> Stéphane