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 <slauri...@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 <slauri...@xwiki.com> > > wrote: > > > >> Vincent Massol: > >>> Hi Stephane, > >>> > >>>> On 28 Aug 2018, at 08:55, Stéphane Laurière <slauri...@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 > >
