Whatever the method used, it should not have to render each page for each
link in the page. This would kill performance.
Rendering should be launched when the user wants to see the preview..
An alternate method could be to store previews as images. This is something
that is done on CryptPad. However there are some potential rights issues
with this approach as the image preview is client side in the case of
CryptPad so it can only be created in the context of a specific user.
Ludovic
--
*Ludovic Dubost*
*Founder and CEO*
ludovic(a)xwiki.com
skype: ldubost
Blog:
XWiki on the cloud
<http://www.xwiki.com/en/products/try-xwiki-cloud> - Try Cryptpad: Secure
realtime Wysiwyg Editing <https://cryptpad.fr>
On Fri, Aug 31, 2018 at 11:12 AM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
On Fri, Aug 31, 2018 at 12:01 PM, Eduard Moraru
<enygma2002(a)gmail.com>
wrote:
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
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?
>
> >
> > 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).
The rendering transformation could simply add a CSS class name on the link
and pull the required JavaScript. It doesn't have to render the linked
page. The real problem is that you can't specify which transformation to
execute per request and that you need to restart the server to enable a new
transformation.
> 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 in
a
span for
now?
I'm not really sure what you mean. When the popover is displayed, a div
is
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/
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 let
me
> 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
>
>
> --
> Stéphane Laurière
> XWiki
www.xwiki.com
> @slauriere
>
--
Stéphane Laurière
XWiki
www.xwiki.com
@slauriere