Re: [xwiki-devs] [Proposal] Remove XWiki.User enable property and introduce email_check property

[Paul Libbrecht]

Hello Simon,

while writing GPDR-compliant “technical organisation’s measures”, 
I’ve been insertion a statement that says that users who do not 
respond to an actualisation wish of the terms-of-conditions are 
automatically erased. The reason this is needed lies in the fact that an 
explicit agreement is always needed to any change in the 
data-privacy-policy as long as the user-profile contains personal 
information (generally, it does).


As a result, it seems to me that one of these fields should be a date: 
“last activated” or something last this. Per default, we’d just 
make sure that this date is not the date zero. An authenticator that a 
would enable a wiki to be GPDR compliant with TOS and privacy notices 
would then check that the last-activated is later than the last 
modification date of these documents.


I entirely agree that a second property stating that a user is disabled 
because his profile looks to be spam is a necessary thing. Here, I do 
not see a date requirement.


thanks

Paul


On 22 Aug 2019, at 16:01, Simon Urli wrote:


Hi everyone,

I recently (in XWiki 11.6RC1) introduced a new property "enabled" in 
XWiki.User as part of https://jira.xwiki.org/browse/XWIKI-12654 to 
distinguish between inactive users (who have not confirm their 
registration with the token sent by email), and disabled users (who 
are deactivated by an admin, or by a security mechanism).


Now as Marius noticed those two properties are quite redundant, 
especially when you want to know which users are really active.
So it introduces unnecessary complexity and we might even need to 
change existing extension to check enabled users (cf the last comments 
on XWIKI-12564).


So before doing those changes, I propose to fix immediately the issue 
by removing that newly introduced property and by introducing a new 
property only for assessing that users' email are checked.


Then we will only have to check "active" property to check if a user 
is active or not, and we could rely on it to set them enabled or 
disabled in the admin.
The email_check property would be used only for the check email 
mechanism, so it will avoid any confusion in the semantic.


WDYT?
Simon

--
Simon Urli
Software Engineer at XWiki SAS
simon.u...@xwiki.com
More about us at http://www.xwiki.com

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

Thank you for your comments Thomas and Vincent,
Thanks for merging my pull request.

Dear all,

Since 11.4-SNAPSHOT (it will 11.4-RC1 in I suppose), it is possible to 
use the transformation actions INSERT_TEXT and 
INSERT_ATTACHMENT_CONTENT.
This is documented in 
https://dev.xwiki.org/xwiki/bin/view/Community/XARPlugin#HInsertTextContentofaFile


paul

On 18 Apr 2019, at 14:39, Thomas Mortagne wrote:


Hi Paul, I commented the jira issue and the PR.

I don't see any harm in this approach at meast so it's a +1 from me.

On Tue, Apr 16, 2019 at 3:06 PM  wrote:



On 26 Aug 2016, at 13:50, Vincent Massol wrote:

[...]
* What I understand is that you’re not proposing to change the 
XAR
format but to introduce some tooling to generate a XAR from a set 
of

source files, at build time. Correct?

[...]

I am rewaking this rather older subject (see
http://xwiki.475771.n2.nabble.com/XAR-source-projects-should-allow-source-files-td7600774i20.html
and older things mentioned there) with yet another attempt which 
might
satisfy everyone: an attempt to use XAR-Transformations to include 
files

into XARs. It defines two extra transformations:

- INSERT_TEXT (using an XPath expression): inserts the content of the
text file
- INSERT_ATTACHMENT_CONTENT (using a file name): inserts the content 
of

a file in base64

The attempt is detailed in 
https://jira.xwiki.org/browse/XCOMMONS-1614

and has a pull-request and an example realisation.

I claim that this attempt allows project developers to nicely edit 
files
and let them be combined into a xar when it is the time. See the 
issue

for an example realisation.

I would love your comments.

Paul




--
Thomas Mortagne

[xwiki-devs] Request for a nexus account

[Paul Libbrecht]

Dear XWiki developers,

I would like to perform releases for Apps of the https://github.com/xwikisas/ 
repositories.
My current work is on 
[application-googleapps](https://github.com/xwikisas/application-googleapps/). 
To do this, I would need an account on nexus.xwiki.org.

Thanks in advance.

Paul

signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] Hibernate upgrade

[Paul Libbrecht]

Hello Adel,

a small word of warning: each upgrade of `hibernate.cfg.xml` is a kind of 
traumatic experience for a simple installation. It would be good not to do 
several of them!

paul

On 7 Jan 2019, at 10:47, Adel Atallah wrote:

> Hi devs,
>
> As you may know, we are currently using a pretty old version of
> Hibernate in XWiki and we could benefit from its upgrade. The new
> version should bring many bug and security fixes (even though they
> don't all apply to our current version) along with better APIs and the
> possibility to integrate other tools (such as other / newer libraries
> or a better connection pool such as the one mentioned in [1])
>
> Currently, I've been trying to make the following upgrades:
> * 3.6.9 to 4.0.1
> * 4.0.1 to 4.3.11
> * 4.3.11 to 5.0.12
>
> The goal is to arrive at version 5.4.0, which is at this date the
> latest stable version.
> I chose to make the upgrade step by step to avoid having to much
> issues to solve at once.
>
> So far, I've made a pull request ([2]) that you can check for the 4.0.1 
> upgrade.
> Here are some of the issues that I've encounter during the upgrades:
> 3.6.9 to 4.0.1:
> * Conflicting dependencies: I had to exclude some dependencies in the pom 
> file.
> * The org.hibernate.Session#connection method removal [3]: I'm either
> using the Session#doWork method or the Session#createSQLQuery one.
> * The org.hibernate.connection.ConnectionProvider interface has
> changed: I had to adapt the DBCPConnectionProvider class that we have,
> mostly to keep backward compatibility, using C3P0ConnectionProvider as
> a model.
> * The Session#getSession(EntityMode) method has been removed [4]: I
> have no idea how to replace that so we need to test it properly.
> * Some attributes in org.hibernate.cfg.Configuration have been
> removed: This has mostly an impact on the custom mapping injection
> which we need to check.
>
> 4.0.1 to 4.3.11:
> * A change in the hibernate schema update generation makes the update
> fail [5]: I had to add a property in the hibernate file but I don't
> think this is the best solution.
>
> 4.3.11 to 5.0.12:
> * The org.hibernate.cfg.Configuration has changed again removing many
> methods that we were using
>
> There are some other issues that I've not mentioned or discovered yet.
>
> So for me the biggest issues are:
> * The schema update: I think we should start using the hibernate one
> instead of our own (except for migration made with liquibase).
> * The custom mapping injection: We will need to rewrite it a bit if we
> want to upgrade to 5.x.
>
> The goal for now is to make the 4.0.1 upgrade work.
>
> Please let me know what you think or if you have any questions.
>
> Thanks,
> Adel
>
> [1] 
> https://jira.xwiki.org/browse/XWIKI-8286?focusedCommentId=96486l#comment-96486
> [2] https://github.com/xwiki/xwiki-platform/pull/1012
> [3] https://hibernate.atlassian.net/browse/HHH-2603
> [4] https://hibernate.atlassian.net/browse/HHH-6330
> [5] https://hibernate.atlassian.net/browse/HHH-8162


signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] [UX] Simpler Upgrades

[Paul Libbrecht]

This should include the classical settings such as shortURLs and root web app. 
Can it?
(at least shortURLs seems doable to me)

paul

On 22 Sep 2018, at 9:44, Vincent Massol wrote:

> One more point on this investigation:
>
> 5) Remove the need to merge configuration files and make sure the user 
> shouldn’t need to edit anything in the WAR itself. See 
> https://forum.xwiki.org/t/managing-configuration-changes-when-upgrading-xwiki-using-docker/3631/16
>  and https://markmail.org/message/6cvm5hocvtbqtgp6 (there’s a more recent 
> discussion thread, need to find it).
>
> This point is important and a pain when you upgrade. This would be a good 
> candidate IMO to improve xwiki’s upgradability and we could implement it 
> sooner than later (knowing that we’ve been wanting to have that fore years 
> now ;)).
>
> Thanks
> -Vincent
>
>
>> On 21 Sep 2018, at 16:19, Vincent Massol  wrote:
>>
>> Thanks Caty.
>>
>> See below
>>
>>> On 21 Sep 2018, at 15:56, Ecaterina Moraru (Valica)  
>>> wrote:
>>>
>>> Hi devs,
>>>
>>> I've heard that the upgrade process is a complicated process and relies on
>>> a lot of manual operations. I haven't investigated the technical solutions
>>> we have at our disposal, but I tried to image the desired UI an
>>> Administrator would want when upgrading:
>>>
>>> * be notified that a new version is available:
>>> https://design.xwiki.org/xwiki/bin/download/Proposal/Upgrade/SimplerUpgrade/WebHome/notifications.png
>>>
>>> * have an upgrade section in Administration where Distribution and
>>> Extensions can be checked for new versions and upgraded / backed:
>>> https://design.xwiki.org/xwiki/bin/download/Proposal/Upgrade/SimplerUpgrade/WebHome/state1.png
>>>
>>> https://design.xwiki.org/xwiki/bin/download/Proposal/Upgrade/SimplerUpgrade/WebHome/state2.png
>>>
>>> A more detailed proposal at
>>> https://design.xwiki.org/xwiki/bin/view/Proposal/Upgrade/SimplerUpgrade/
>>>
>>> So, what are your thoughts on this?
>>
>> Some thoughts:
>>
>> 1) Automatic distribution upgrade would be very nice but it’s hard to do for 
>> all packagings. We already do it for the debian one (apt-get upgrade) and we 
>> could do it better for some others (docker, standalone). However for the 
>> manual WAR install it’s harder and I don’t even know if it’s possible (at 
>> least for all supported servlet containers). One idea would be to implement 
>> it for Tomcat only for example and have a way to control the tomcat manager 
>> (manager app) to perform the upgrade of the webapp.
>>
>> 1a) Would be nice to have a a distribution upgrade UI too for merging the 
>> various configuration files (could be a separate webapp for ex - haven’t 
>> really thought about this).
>> 1b) For the docker upgrade we can look at the discourse upgrade process, to 
>> see if there are some good ideas to reuse
>>
>> 2) We have comments about the DW being hard to understand/complex. You 
>> haven’t addressed this. Is it because you didn’t find anything to improve?
>>
>> 3) We regularly see users having problems to upgrade (cf forum, irc, mailing 
>> lists) and we’d need to list the common issues they have. Their problems may 
>> not be related to the UI but to bugs/limitations we currently have.
>>
>> 4) A typical known issue is when the user skips/clicks “never” on the DW. He 
>> cannot get it to appear afterwards. We will need to fix this usability issue 
>> for ex.
>>
>> Thanks
>> -Vincent
>>
>>
>>>
>>> Thanks,
>>> Caty


signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] [Contrib] New repo and JIRA for an OpenStreetMap macro

[Paul Libbrecht]

Stéphane,

One of the very interesting derivative of OpenStreetMap is umap 
http://umap.openstreetmap.fr
That’d be yet another provider, right?

paul

On 26 Jun 2018, at 20:44, Vincent Massol wrote:

> Hi Stephane,
>
>> On 26 Jun 2018, at 20:37, Stéphane Laurière  wrote:
>>
>> Hi devs,
>>
>> We have a MapMacro already [1], for displaying Google Maps. I'd like to 
>> create a distinct one for creating maps based on OpenStreetMap. Another 
>> option would be to enhance the existing MapMacro for supporting the display 
>> of OSM maps in addition, but this would make the code more complex, and in 
>> general an administrator willing to use maps in his wiki is likely to opt 
>> for one map type, probably not both, what do you think?
>
> Since this is not a large “component”, I think my preferences goes to a 
> single {{map}} macro, with a “provider” parameter (provider=“google”, 
> “openstreetmap”, “apple”, etc) and possibly aliases such as {{googlemap}} 
> {{openstreetmap}} which would simply be shortcuts for {{map 
> provider=“google”}} and {{map provider=“openstreetmap”}}.
>
> I think it would make it simpler from a user POV. I’d prefer to have one 
> recommended map macro that we try to support instead of a myriad of smaller 
> map macros that would not be recommended and at various levels of support.
>
> WDYT?
>
> Thanks
> -Vincent
>
>> If you agree, the proposed repo name and JIRA would be:
>>
>> - Repo: macro-openstreetmap
>> - JIRA project: OSM
>>
>> [1] https://extensions.xwiki.org/xwiki/bin/view/Extension/Map%20Macro
>>
>> Thank you,
>>
>> Stéphane
>>
>>
>> -- 
>> Stéphane Laurière
>> XWiki www.xwiki.com
>> @slauriere
>>
>>


signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] [Question for the xwiki security feature] Hi xwiki security members

[Paul Libbrecht]

On 18 May 2018, at 9:35, Thomas Mortagne wrote:

> On Thu, May 17, 2018 at 10:10 PM, Kwan Kim  wrote:
>> 2. No controls for Account Creation
>> The  vulnerability test team think it is too easy to create new account
>> Is there any way that new account need to get approval from admin user ?
> Its possible to disable registration and let admins create accounts
> but I don't think there is any support for admin validation of self
> registered users (but it's possible I missed it).

I think that breaking the activation mail reaches that (e.g. prevent mails, 
remove the link from the validation mail content) and let admins act after they 
are requested by email.

paul

signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] XWiki GSoC Blockly Editor

[Paul Libbrecht]

Hello Vivek,

this is probably too far but it’s always good to have further plans. Here are 
two possible extension avenues which would be useful for the blockly world, I 
believe:

- create a workflow that allows custom-blocks to be included in the toolbox 
using a similar experience as the xwiki extension manager (there was a GSoC on 
bringing more repositories for this manager last year)
- employ the real-time editing extension or parts of it (e.g. chainpad-listmap) 
so that a blockly page can be edited in synchronicity between teachers and 
students (where used can be _edited_ or even _run_). CodePen seems to allow 
such features.

thanks

paul


On 4 May 2018, at 22:28, Vivek Iyer wrote:

> Sir,
> I've made the changes in the design page as requested!
>
> I think you covered most of the use cases, I tried thinking of more but I
> couldn't come up with any relevant ones. Like the basic use cases are the
> conversion of blocks to code and vice versa, and CRUD operations on blocks
> and those have been covered. I think I should focus on implementing these
> use cases and getting the basics right, and then maybe if time permits, I
> can add support for other programming languages too!
>
> Regards,
> Vivek Iyer
>
> On Fri, May 4, 2018 at 2:23 PM, Vincent Massol  wrote:
>
>>
>>
>>> On 4 May 2018, at 10:52, Vincent Massol  wrote:
>>>
>>> Hi Vivek,
>>>
 On 4 May 2018, at 10:15, Vivek Iyer 
>> wrote:

 Hello all!
 My name is Vivek Iyer (github and Riot handle: Remorax) and I'm so
>> grateful
 for being selected as part of GSoC and I'm honestly looking forward to
 contributing here!
>>>
>>> Welcome aboard :)
>>>

 My project for the summer is the Google Blockly Editor and to integrate
>> it
 with the current wiki and WYSIWYG editors. I plan to do this in four
 stages:
 - Firstly develop a small extension as test, so that I can build up on
>> it.
 - The second stage would be actually integrating a basic Blockly editor
>> in
 XWiki.
 - The third stage would be adding custom blocks which generate the code
>> for
 functions which are most commonly used
 - The fourth and the last stage would be making these blocks output
 Velocity (or alternatively JS) code which would substitute the contents
>> of
 the div which would normally contain the manually written code.

 Ideally, I plan on finishing stages 1 and 2 before the first evaluation,
 stage 3 before the second evaluation and stage 4 before the final
 evaluation.

 As mentioned in my proposal, I'll be on vacation from 10th to 20th May
>> and
 won't have internet access so I'll be unable to contribute during that
 period, but I'll surely make up for the lost time later on and get the
>> work
 done on schedule!

 I've also kept buffer slots in between in case I run behind schedule.

 I have also made a design on design.xwiki.org here:
 http://design.xwiki.org/xwiki/bin/view/Google-Blockly-Editor/
 Do check it out and let me know your opinions!
>>>
>>> I’ve had a quick look and it would be nice if you could reformulate the
>> use cases in term of features that the extensions needs to support.
>>>
>>> For example instead of saying:
>>>
>>> - The user enters his credentials.
>>> - If authenticated, he is redirected to the dashboard.
>>> - If the user is unable to authentinicate, the user is shown an error
>> message saying invalid credentials
>>>
>>> You should simply say:
>>>
>>> * Allow users to enter Google credentials in the Admin UI.
>>>
>>> Question: is this needed? Why do we need to enter credentials? AFAICS
>> there’s no need to provide any credentials except if we wanted the optional
>> cloud storage (which is not something we want IMO since the storage is
>> going to be in wiki pages).
>>>
>>> Also you say:
>>>
>>> - The user navigates to the page he wishes to edit.
>>> - He selects the edit option and if he's an advanced user, he sees the
>> Blockly editor and selects it
>>>
>>> You should simply say:
>>>
>>> * Add a page editor to the list of available editors (Wiki, WYSIWYG,
>> etc) so that users can edit a page using the Blockly editor
>>>
>>> You’re also missing this:
>>>
>>> * Ability to define the Blockly editor as the default editor in the
>> Admin and in the use’s profile
>>>
>>> Also you say:
>>>
>>> - The Blockly editor contains various blocks for performing common XWiki
>> scripting actions
>>> - The user selects the appropriate blocks which show up as code on the
>> side div
>>> - Once the user is done with the scripting, he clicks on the save and
>> continue button
>>> - He is then redirected and is able to view his changes.
>>>
>>> This is not needed as it’s pretty obvious ;) This is just describing the
>> usage of the extension, not the requirements for the integration. You can
>> put it in a usage section if you want though.
>>>
>>> Also you 

Re: [xwiki-devs] Add a REST API to XWiki Notifications

[Paul Libbrecht]

This project is cool.
Could it bring us RocketChat and RiotIM notifications for every server? Or even 
SMS?
Should there be both push and pull models of the API? (has there been something 
since X? Can you call Y when something happens?).

paul

On 27 Mar 2018, at 16:28, nikos delis wrote:

> i have read this articles  :Notifications API
> 
> and this : Notifications Applications
> 
> So you have an API that is not REST and want to make REST from scratch
> along with new additions?
>
> Thanks
>
> 2018-03-27 17:18 GMT+03:00 Vincent Massol :
>
>> Hi Nikos,
>>
>>> On 27 Mar 2018, at 16:14, nikos delis  wrote:
>>>
>>> Yes sure Mr Vincent Massol
>>> here is the link : Add a REST API to XWiki Notifications
>>> > AddaRESTAPItoXWikiNotifications>
>>
>> ok cool, I’ve just read it now :)
>>
>> see below
>>
>>> 2018-03-27 17:11 GMT+03:00 Vincent Massol :
>>>
 Hi Nikos,

 Is this related to a GSOC project? If so, could you provide the link to
 this GSOC project so that we can understand the context?

 This mailing list is for the dev of the XWiki project and not everyone
 know by heart about the various GSOC projects.

> On 27 Mar 2018, at 16:09, nikos delis  wrote:
>
> Hi all,
> I am new on this mailist and thanks for the invite.I have do proposal
>> for
> Add a Rest API to XWiki Notifications.
> mr Clément Aubin came into contact with me with some helpful links to
> understand how notifications is impliment on Xwiki platform and how
> notifications works.I see that you have a complete Notificaton API that
> works perfect for Xwiki platform therefore you want to make a  REST API
 to
> take notifications from other platforms to Xwiki platform?
>>
>> Correct, the idea is to be able to access notifications information from
>> outside of XWiki using this new REST API for notifications.
>>
> I understood
> this from the speech .Second REST API will be created from scratch? or
 will
> build up on the existing?
>>
>> From scratch since I don’t think there’s any existing Notifications REST
>> API.
>>
>> But it should use JAXRS and the fwk we already use. See:
>> * http://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/
>> XWikiRESTfulAPI
>> * https://github.com/xwiki/xwiki-platform/tree/master/
>> xwiki-platform-core/xwiki-platform-rest
>>
>> Thanks!
>> -Vincent
>>
> Thanks for reading
>
> Nikos.

 Thanks
 -Vincent



>>
>>


signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] replacing XSL-FO

[Paul Libbrecht]

Hello all,
Hello Mohamed,

There has been two tools suggested in this thread: flyingsaucer and weasyprint.
Can you find more tools?
Can you try to see how an architecture would look like with these two tools and 
incorporate that in your proposal?

flyingsaucer should be quite easy to integrate since it’s in java. So it’d be 
probably a pom.xml change or an extension with the relevant pom.xml…

paul


On 26 Mar 2018, at 9:55, Vincent Massol wrote:

> Hi Ludo,
>
>> On 26 Mar 2018, at 09:16, Ludovic Dubost <ludo...@xwiki.com> wrote:
>>
>> On Sat, Mar 24, 2018 at 10:06 PM, Vincent Massol <vinc...@massol.net> wrote:
>>
>>>
>>>
>>>> On 24 Mar 2018, at 21:58, Paul Libbrecht <p...@hoplahup.net> wrote:
>>>>
>>>> Hello Mohammed,
>>>>
>>>> have you googled for paged-media html to css converters?
>>>>
>>>> Surely an option is to let it be done by the browser but there must also
>>> be engines.
>>>
>>> We have evaluated this in the past and there are lots of limitations, see
>>> https://markmail.org/message/ztcwibiuoqfjcnjo
>>>
>>>> E.g. I think that phantomJS of weasyprint can do that. However, I
>>> haven’t found yet in java (which would simplify things).
>>>
>>> Note that phantomjs is dead now:
>>> https://www.puzzle.ch/blog/articles/2018/02/12/phantomjs-
>>> is-dead-long-live-headless-browsers
>>>
>>>> As Vincent says, print with LaTeX in the middle is a way to get
>>> high-quality but there are many losses too: it is really hard to get CSS
>>> rules to be all implemented in TeX.
>>>
>>> Yes indeed, that’s very hard. CSS shouldn’t be used as a way to style the
>>> LaTeX output. The LaTeX exporter itself should provide its own way of
>>> controlling the style of the output. This is what I do in the LaTeX
>>> exporter. Basically I provide some default styles (sometimes with some
>>> config options) and the user has the ability to control exactly the styles
>>> he/she wants applied if the default style is not enough. It’s not trivial
>>> though and will take a bit of time if you need a heavily styled document.
>>>
>>
>> This is a major limitation of a latex based export for XWiki. This makes it
>> very hard to export any macros that would produce HTML + CSS and any HTML
>> that the user would create in XWiki.
>
> Yes this is what I was mentioning re CSS. On the HTML side, it’s not exactly 
> true since we can parse the HTML with the XWiki HTML parser which generates 
> and XDOM and then render that XDOM. It won’t be perfect though. For example 
> there are HTML elements that are not supported by our HTML parser (ex:  
> elements).
>
>> The current XML-FO based export supports a limited set of HTML + CSS. Also
>> latex does not provide us with a java pdf export.
>
> One thing has to be clear: I’m absolutely not pushing for having the LaTeX 
> export as a replacement of our XSL-FO approach. For some reason you seem to 
> be hinting at that which is not my opinion for several reasons. I mentioned 
> LaTeX here because it’s important to know all the technologies that exist to 
> produce a PDF and that’s one we have, that’s all.
>
> It’ll be interesting at some point to draw a Pro/Cons table on xwiki.org to 
> compare the various export options with their limits.
>
>> The CSS paged media standard has this advantage of bringing to the table
>> HTML + CSS support and support of CSS for the general document output
>> (header, footer, etc..). Now of course we need to find the right libraries
>> for that. It would be nice to have an experiment based on this to see how
>> far we can go with css pages media.
>
> Definitely. That’s actually the purpose of this GSOC Ludo! :)
>
> TBH I was the one pushing for this experiment initially when I found about 
> the nice result of flyingsaucer… So I’m as eager as you to see what we can 
> get with paged CSS.
>
>> It's important to consider the full needs if we want to compare
>> technologies. The latex export makes nice high quality output but currently
>> only for the basic syntax elements that we validate for that output.
>
> Regarding the quality of the output, yes it’ll be fun to compare what we get 
> with various inputs when using the 3 technologies:
> * XSL-FO
> * LaTeX
> * Paged CSS (see https://print-css.rocks/intro.html#what-is-css-paged-media)
>
> Thanks
> -Vincent
>
>>
>> Ludovic
>>
>>
>>
>>>
>>> Thanks
>>> -Vincent
>>>
>>>>
>>>> I’m wonde

Re: [xwiki-devs] replacing XSL-FO

[Paul Libbrecht]

Hello Mohammed,

have you googled for paged-media html to css converters?

Surely an option is to let it be done by the browser but there must also be 
engines.
E.g. I think that phantomJS of weasyprint can do that. However, I haven’t found 
yet in java (which would simplify things).
As Vincent says, print with LaTeX in the middle is a way to get high-quality 
but there are many losses too: it is really hard to get CSS rules to be all 
implemented in TeX.

I’m wondering if CSSbox could do the job.

paul

On 24 Mar 2018, at 20:51, Mohamed Ashraf wrote:

> Yes this is part of GSOC project
>
> Sent from my iPhone
>
>> On Mar 24, 2018, at 9:29 PM, Vincent Massol  wrote:
>>
>> Hi Mohamed,
>>
>>> On 24 Mar 2018, at 19:12, Mohamed Ashraf  wrote:
>>>
>>> Currently, the PDF export of XWiki is implemented based on XSL-FO and
>>> transformation of XHTML to FO. This poses a couple of problems, mainly
>>> related to the current level of support of FO from libraries implementing
>>> FO to PDF transformation, as well as the limitations of automatized
>>> transformation of XHTML to FO. The problems are mainly related to styling
>>> limitations, auto-layouting, etc.
>>>
>>> The idea is to try to replace this with a pure XHTML & CSS (paged CSS)
>>> export, using an open source library for producing PDFs out of this
>>> ,
>>
>> Sure, but which one?
>>
>> The only alternative I know is flying saucer (which is dead: 
>> https://github.com/flyingsaucerproject/flyingsaucer). Is that what you mean?
>>
>> Do you know a maintained fork of it? One that I know is used by a competing 
>> wiki: https://bitbucket.org/atlassian/xhtmlrenderer-atlassian
>>
>> Are you doing this as part of this GSOC project: 
>> http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/ImplementPDFexportwithXHTMLpagedCSS
>>  ?
>>
>> Thanks
>> -Vincent
>>
>>> and I will see LaTeX ,
>>> thanks
>>>
>>> 2018-03-24 19:52 GMT+02:00 Vincent Massol :
>>>
 Hi Mohamed,

> On 24 Mar 2018, at 18:44, Mohamed Ashraf  wrote:
>
> If we should replacing the XSL-FO which we use to export PDF file out of
> XML,
> with XML and CSS only with open-source library ,
>
> and I think  * ”CSS Paged Media “ *
>
> is this good enough to do that ,
> or there are any suggestion

 Sorry but I don’t understand your question. Why would you want toi replace
 XSL-FO in your XWiki install?

 If you’d like to contribute to XWiki dev, then could you provide more
 context and explain why you want to replace XSL-FO and by what.

 You may also be interested by the LaTeX exporter which can be used to
 generate PDFs: http://extensions.xwiki.org/xwiki/bin/view/Extension/LaTeX/

 Thanks
 -Vincent



>>


signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] Regarding working on ideas of GSOC, 2018

[Paul Libbrecht]

Hello Aaditya,
(if I may)

In complement to what Thomas suggested, could I suggest that you comment on the 
projects’ ideas that you see presented?

Each of them requires a good vision on what the product can look like at the 
end…
I can see a challenge for each of them:

>> a)   Idea 1 -Google Blockly Editor
Would you be able to make it happen as a simple package that any wiki can 
install without any dependency on cloud-based services (as privacy is important 
in learning environments)?

>> b)   Idea 2 -  Idea : Translation in context
This idea promises super-power to translators… but there can be dangers. Can 
you spot these dangers and suggest display methods to avoid the dangers?

>> c)Idea 3 - .idea :   XWiki-StaticSiteGen
The value of this project lies in its applicability to multiple contexts. What 
XWiki content source would you take as example and how would you imagine the 
workflow of people developing content? (editing, preview, and publish cycles, 
communication with links to the static pages…)

paul



On 12 Mar 2018, at 10:35, Thomas Mortagne wrote:

> Hi and welcome !
>
> You should take a look at
> http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HIncreasingyourchancesofbeingacceptedasastudent.
>
> The best is to select issues related to the areas you would like to
> work on (html export, translations). You might also want to take a
> look at http://l10n.xwiki.org.
>
> On Sun, Mar 11, 2018 at 11:30 AM, AADITYA KUMARRAI IET Lucknow Student
> <1605210...@ietlucknow.ac.in> wrote:
>>  Hello Sir,
>>
>>  This is Aaditya Kumar Rai,pursuing Computer Science Engineering (currently
>> in Second Year ) at one of Premier Government college in India.
>>  I have good hand on working over open source projects based on Programming
>> & Full Stack Development in Web and Applications, as I have already
>> developed :
>> a) Library management System(using Python)
>> b)Retrieving Processing and Visualizing data with Python(Under guidnace of
>> Prof.Charles Severance ,University Of Michigan)
>>
>> Currently working on :
>> a) A dynamic website development that will work on Availability of all
>> resources to college students (using HTML ,CSS, Javascript,AngularJS  for
>> back-end NodeJS)
>>
>> As I have extreme interest to explore open source arena more deeper to
>> enhance my knowledge further so that i can gain industrial experience too.
>> Sir, i am applying for GSOC first time and due to unavailability of
>> Guidance ,i have lost much of time in preparation for GSOC,18.
>>
>> I am helpless ,please guide and help me and I am pretty much sure that
>> within such short of time , i will put my all efforts and skills to fix
>> bugs and Patch it additional to submission of Proposals and will prove
>> Myself best for those given Projects.
>>
>> I have good deal of experience with development in,C HTML5, CSS3 ,Advanced
>> Python , Javascript & PHP, I find myself able to work on following ideas:-
>> a)   Idea 1 -Google Blockly Editor
>> b)   Idea 2 -  Idea : Translation in context
>> c)Idea 3 - .idea :   XWiki-StaticSiteGen
>> Brief description:
>> I am little bit confused on how to start? How can i show my worth to you or
>> should i directly focus on proposal or any bug patches first or discuss my
>> solution first?
>> Please guide me from here on how to proceed further.
>> Thanking You!
>>
>> Regards..
>> Aaditya Kumar Rai
>>
>> --
>>
>> --
>> *Institute of Engineering & Technology,* 
>> Sitapur Road,Lucknow
>> Uttar Pradesh,India
>> PIN : 226021
>
>
>
> -- 
> Thomas Mortagne


signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] [Usability] Mail Server Configuration Profiles

[Paul Libbrecht]

I find this cool but this is another maintenance point.
You might want to include 3-4 other providers and hide the values that are 
predefined by the choice. Actually, in order to go for a “tuned case”, you can 
easily select Gmail then select custom, the values should be then copied.

It would be nice that the sender address is explained (and profilled) as a 
qualified sender with a full name (copied from the wiki name?).

paul

On 7 Mar 2018, at 15:05, Ecaterina Moraru (Valica) wrote:

> Hi devs,
>
> What do you think about the idea of providing Mail configuration profiles
> that the user can select from? It would contain predefined values for the
> configuration. The most easy to test / accessible config is the Gmail one.
>
> See http://design.xwiki.org/xwiki/bin/view/Proposal/IdeaMailProfiles
>
> Thanks,
> Caty


signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] [Usability] Create a dedicated Logo section in Administration

[Paul Libbrecht]

On 21 Feb 2018, at 18:03, Guillaume Delhumeau wrote:

> Do we know a single person that have different logos in the different
> spaces of the same wiki?

A colleague of mine asked me such on our wiki.
It is not very common though (so it’d be ok if it’s a programming task).

paul

> I've never met any, but I don't know all users.
>
> To me, it just creates confusion for 99% of users, for the sake of helping
> 1% of them (supposing they know how to do it).
>
> That would be ok if that 1% were contributors to XWiki, but it does not
> seem to be the situation.
>
> My proposal is to have a single input, for the logo of the current wiki
> (subwikis can fallback to the main one), et trash all the other options.
>
> My 2 cents,
>
> Guillaume


signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] [Brainstorming] LaTeX Renderer - Styling

[Paul Libbrecht]

You certainly need hooks for a preamble where all macros, variables, and 
environments are defined.

Bringing Velocity to write LaTeX is probably enjoyable since you can be very 
free to input text source, I am wondering if there are no escaping issues. 
Maybe with the $ sign which is used for math formulæ? (and $$ for “centered 
math”). All #-signs should be gone by the time LaTeX runs… this is still used 
in rare times (for special layouts). At least these escaping mechanisms should 
be explained close to the TeX-related documentation.

paul

On 15 Feb 2018, at 20:47, Vincent Massol wrote:

> Ok I’ve now realized that the 2 approaches mentioned so far are not going to 
> work:
> * The first one mixes content and styling and is complex for the user to use
> * The second one is actually very limited and doesn’t allow full control of 
> the LaTeX markup used
>
> So I’ve been thinking about a new approach that would both separate the 
> content from the styling and at the same time allow full control of the 
> produced LaTeX for perfect typesetting.
>
> The idea is:
> * Don’t provide a Listener for LaTeX in XWiki and instead only provide a 
> BlockRenderer (i.e. no streaming generation of content). That’s the 
> limitation.
> * For each XWiki Block object, provide a default LaTeX template that is 
> called to generate the LaTeX content.
> * Allow Velocity in the LaTeX template and provide velocity tools + bind the 
> passed Block to the $block variable.
> * For example for TableBlock:
>
>  start here 
> ## Compute the number of columns
> #set ($firstRowBlock = $blocks.getChildren().get(0))
> #set ($columnSize = $firstRowBlock.getChildren().size())
> #set ($tableSpec = "${stringtool.repeat("l|", $columnSize - 1)}l"
> \begin{tabular}{${tableSpec}}
> ## For all rows
> #foreach ($rowBlock in $blocks.getChildren())
>   ## for all cells
>   #foreach ($cellBlock in $rowBlock.getChildren())
> #processTemplates($cellBlock.getChildren()) &
> ## TODO: if last cell then output ""\\"
>   #end
>   ## TODO: if last row then don't output \hline
>   \hline
> #end
> \end{tabular}
>  end here -
>
> * Users will be able to override the default templates for each Block
> * If the user wants to use a special template for a specific Block, define it 
> using a “tex-template” parameter. For example:
>
> (% tex-template=‘customTemplateForThisTable’ %)
> |=A|=B
> |a|b
>
> * A template can set any variable in the VelocityContext so that templates 
> downstream can access them.
>
> There are still details to iron out ofc.
>
> WDYT?
>
> Thanks
> -Vincent
>
>> On 14 Feb 2018, at 21:01, Vincent Massol  wrote:
>>
>> Hi devs,
>>
>> I’m currently working on improving our TeX renderer (which is really a POC 
>> ATM), in an effort to see if it could be used to generate nice PDF exports 
>> (you generate LaTeX and then you convert to PDF).
>>
>> The main issue is that LaTeX doesn’t have any technology for applying style 
>> to it (like CSS has for HTML). In addition I wasn’t able to find any good 
>> HTML+CSS to TeX converter (as we have for PDFs with XSLT+FOP).
>>
>> So right now my idea is to implement some default behavior in the Tex 
>> Renderer (that could be configured globally in xwiki.properties and/or in 
>> the Admin UI) and give the ability to override specifically in the content.
>>
>> For example, imagine that you need to decide how to position table column 
>> content (left, centered, right) or whether the rows and/or columns of your 
>> table have vertical and horizontal lines (or other configs, autowrap, etc).
>>
>> The idea is that the Tex Renderer would support some custom tex-specific 
>> parameters. For example:
>>
>> (% tex-table-spec=“c | c | c" tex-table-floating="true" 
>> tex-table-caption="caption" %)
>> |=A|=B
>> (% tex-table-row-ending="\hline" %)|a|b
>>
>> (by default the table spec would be left aligned with vertical lines, and 
>> rows would be separated by horizontal lines).
>>
>> If you have some comments or ideas, please let me know.
>>
>> Inventing a CSS-like mechanism would just be too hard to implement IMO.
>>
>> Thanks
>> -Vincent
>>
>> PS: If you want to see table options in LaTeX, see 
>> https://en.wikibooks.org/wiki/LaTeX/Tables
>>


signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] [Brainstorming] LaTeX Renderer - Styling

[Paul Libbrecht]

Hello Vincent,

On 15 Feb 2018, at 7:25, Vincent Massol wrote:
having some experience with TeX I would implement CSS with 
macro-definitions… Every element start would be a call to a macro 
that would check for rules that would apply to its element, including 
passing parameters of their ancestry.


Could you give an example of what you mean by macro-definitions? Is 
this something that exist in TeX?


Definitely. The complete TeX is based on macros.
Basic macros are created using the \def macro.
See e.g. http://www.tex.ac.uk/FAQ-whatmacros.html

Closer to the HTML world, there are the LaTeX environments. They are 
nestable and extensible:  see http://www.tex.ac.uk/FAQ-whatenv.html


This would be the way to create styles I think.
Paths are not transported, as far as I know (would they be called maybe 
environment stack?). That would need to be carried as an extra parameter 
produced by the renderer. I would also think that recognising complex 
rules with such as classes would need an amount of coding before the 
LaTeX is processed.


However, I guess that your solution seems probably more ad hoc and 
more practical.


Is there any reason that you don’t use the XSL-FO renderer that use 
LaTeX? I thought there were several of them.


Do you have a pointer? As I said in my original mail I tried to search 
for an XHTML to LaTeX converter/XSLT but couldn’t. If you know of 
one, I’ll gladly have a look.


The world is thinner than I thought.
The closest I could find are the TEI renderers:
http://www.tei-c.org/release/doc/tei-xsl/
https://www.tug.org/TUGboat/tb27-0/rahtz.pdf
or DocBookLaTeX
https://sourceforge.net/projects/dblatex/

paul



On 14 Feb 2018, at 21:01, Vincent Massol wrote:


Hi devs,

I’m currently working on improving our TeX renderer (which is 
really a POC ATM), in an effort to see if it could be used to 
generate nice PDF exports (you generate LaTeX and then you convert 
to PDF).


The main issue is that LaTeX doesn’t have any technology for 
applying style to it (like CSS has for HTML). In addition I wasn’t 
able to find any good HTML+CSS to TeX converter (as we have for PDFs 
with XSLT+FOP).


So right now my idea is to implement some default behavior in the 
Tex Renderer (that could be configured globally in xwiki.properties 
and/or in the Admin UI) and give the ability to override 
specifically in the content.


For example, imagine that you need to decide how to position table 
column content (left, centered, right) or whether the rows and/or 
columns of your table have vertical and horizontal lines (or other 
configs, autowrap, etc).


The idea is that the Tex Renderer would support some custom 
tex-specific parameters. For example:


(% tex-table-spec=“c | c | c" tex-table-floating="true" 
tex-table-caption="caption" %)

|=A|=B
(% tex-table-row-ending="\hline" %)|a|b

(by default the table spec would be left aligned with vertical 
lines, and rows would be separated by horizontal lines).


If you have some comments or ideas, please let me know.

Inventing a CSS-like mechanism would just be too hard to implement 
IMO.


Thanks
-Vincent

PS: If you want to see table options in LaTeX, see 
https://en.wikibooks.org/wiki/LaTeX/Tables

Re: [xwiki-devs] [Brainstorming] LaTeX Renderer - Styling

[Paul Libbrecht]

Hello Vincent,

having some experience with TeX I would implement CSS with macro-definitions… 
Every element start would be a call to a macro that would check for rules that 
would apply to its element, including passing parameters of their ancestry.

However, I guess that your solution seems probably more ad hoc and more 
practical.

Is there any reason that you don’t use the XSL-FO renderer that use LaTeX? I 
thought there were several of them.

paul

On 14 Feb 2018, at 21:01, Vincent Massol wrote:

> Hi devs,
>
> I’m currently working on improving our TeX renderer (which is really a POC 
> ATM), in an effort to see if it could be used to generate nice PDF exports 
> (you generate LaTeX and then you convert to PDF).
>
> The main issue is that LaTeX doesn’t have any technology for applying style 
> to it (like CSS has for HTML). In addition I wasn’t able to find any good 
> HTML+CSS to TeX converter (as we have for PDFs with XSLT+FOP).
>
> So right now my idea is to implement some default behavior in the Tex 
> Renderer (that could be configured globally in xwiki.properties and/or in the 
> Admin UI) and give the ability to override specifically in the content.
>
> For example, imagine that you need to decide how to position table column 
> content (left, centered, right) or whether the rows and/or columns of your 
> table have vertical and horizontal lines (or other configs, autowrap, etc).
>
> The idea is that the Tex Renderer would support some custom tex-specific 
> parameters. For example:
>
> (% tex-table-spec=“c | c | c" tex-table-floating="true" 
> tex-table-caption="caption" %)
> |=A|=B
> (% tex-table-row-ending="\hline" %)|a|b
>
> (by default the table spec would be left aligned with vertical lines, and 
> rows would be separated by horizontal lines).
>
> If you have some comments or ideas, please let me know.
>
> Inventing a CSS-like mechanism would just be too hard to implement IMO.
>
> Thanks
> -Vincent
>
> PS: If you want to see table options in LaTeX, see 
> https://en.wikibooks.org/wiki/LaTeX/Tables


signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] [Idea] Look at Thymeleaf as an optional templating language?

[Paul Libbrecht]

Well, HTML is what people understand.
XSL-FO would not be very widespread.
What other language do you want the tempting language to orient itself on?

paul

On 4 Jan 2018, at 11:24, Eduard Moraru wrote:

> On Wed, Jan 3, 2018 at 11:01 AM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
>> From the home page it looks very HTML oriented, which is not good for us. I
>> think we need a general purpose templating language that can be used to
>> generate anything (JSON, XML, CSV, etc.) not just HTML.
>>
>
> Yeah, my first impression was that it looks very similar to JSF, maybe a
> bit simplified and less configuration needy.
>
> Thanks,
> Eduard
>
>>
>> On Tue, Jan 2, 2018 at 11:48 PM, Vincent Massol 
>> wrote:
>>
>>> See http://www.thymeleaf.org/
>>>
>>> With this, users could combine HTML and scripting which could be a nice
>>> option when using the {{html}} macro for example.
>>>
>>> {{html}}
>>> {{thymeleaf}}
>>> …
>>> {{/thymeleaf}}
>>> {{/html}}
>>>
>>> Related:
>>> * https://dzone.com/articles/template-engines-review-after-
>>> deprecated-velocity
>>>
>>> Thanks
>>> -Vincent
>>>
>>>
>>


signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] [Idea] Look at Thymeleaf as an optional templating language?

[Paul Libbrecht]

Pug has a java implementation:
https://github.com/pugjs/pug => java => 
https://github.com/neuland/jade4j
paul

On 3 Jan 2018, at 9:47, Vincent Massol wrote:

> Just important to avoid jumping from one sinking ship to another ;)
>
>
> Definitely. Note that my idea here was more of suggesting exploring some 
> other templating languages that would be initially added as a contrib 
> project, rather than replacing Velocity. But you’re perfectly right, if 
> someone is willing to work on this, we might as well pick the right one.
>
> However note that pug is not a candidate since it’s not java-based and is for 
> Node.js.


signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] [Proposal] Login button for desktop

[Paul Libbrecht]

I think the problem with this image is the icon.

https://material.io/icons/#ic_power_settings_new or any other power button 
would be cool.

paul

On 12 Dec 2017, at 16:58, Guillaume Delhumeau wrote:

> I've proposed
> https://jira.xwiki.org/secure/attachment/34732/Proposition4.png, but Thomas
> already said that it's clearly not obvious.
>
> I've voluntary broken the consistency to highlight this action. It's the
> most important one if you are not logged.
>
> Thanks
>
> 2017-12-12 16:41 GMT+01:00 Vincent Massol :
>
>> I’d also prefer an icon and not text if we can find an icon that’s clear
>> enough. The other icons don’t have text so it would be nicer to continue
>> with this for consistency.
>>
>> Thanks
>> -Vincent
>>
>>> On 12 Dec 2017, at 16:40, Vincent Massol  wrote:
>>>
>>> Hi,
>>>
>>> I have 2 points:
>>>
>>> 1) We need to have this configurable somehow but that should be easy
>> since both buttons (inside and outside of the drawer are UIX). I still
>> think there are use cases for having it inside the drawer.
>>> 2) I’d put the Login on the right, just left of the Hamburger icon (ie
>> right of the search).
>>>
>>> Thanks
>>> -Vincent
>>>
 On 12 Dec 2017, at 16:04, Guillaume Delhumeau <
>> guillaume.delhum...@xwiki.com> wrote:

 Hi Devs,

 Currently, the login button is inside the drawer menu, which is quite
 standard on mobile phones. However, on desktop, a lot of people are
 confused and cannot find how to login/register.

 I propose to add a login button in the top menu, like this:
 https://jira.xwiki.org/secure/attachment/34731/Proposition3.png

 Related JIRA: https://jira.xwiki.org/browse/XWIKI-14881#

 That could be nice to have it in addition to the current links, for
>> 9.11.

 Note: we also need to put a "register" link in the login form, so that
 people can register from there without the need to also add a register
 button on the top menu (that would be too much IMO).

 WDYT?

 Thanks,

 --
 Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
 Research & Development Engineer at XWiki SAS
 Committer on the XWiki.org project
>>>
>>
>>
>
>
> -- 
> Guillaume Delhumeau (guillaume.delhum...@xwiki.com)
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project


signature.asc
Description: OpenPGP digital signature

Re: [xwiki-devs] [GSoC] Extension Repository Connector - NPM released!

[Paul Libbrecht]

Hey Krysiek,

this looks really really really cool!
And the mathjs example is cute.
Do you think that there would be a way to remove the version number from the 
require?

thank you very much for this.

Paul

> On 24 Aug 2017, at 13:18, Krzysiek Płachno  wrote:
> 
> Hello XWiki team!
> 
> I just write to brag a bit about *Extension Repository Connector - NPM*
> that I created in 3rd phase of GSoC ;)
> You can read about it here:
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Extension%20Repository%20Connector%20-%20NPM/
> and
> test it if you wish (there's an example to follow).
> 
> As before - any feedback highly appreciated :)
> 
> Have a nice day!
> Best,
> Krzysztof



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [xwiki-devs] [Proposal] Replace OpenJS Keyboard JS with Keypress JS for handling keyboard shoirtcuts

[Paul Libbrecht]

Really a good idea to address this!
So my +1.

However, I think it would get more +1 if “see sequence combos for example” is 
made clear to me.
My problem with the current keybinding is that it conflicts with things which I 
expect to work in each web-page. In particular cmd-G which I expect to be “find 
next” and which works on all websites I regularly use except XWikis.

thanks in advance.

Paul


> On 26 Jul 2017, at 22:50, Vincent Massol  wrote:
> 
> Hi devs,
> 
> We’re currently using 
> http://www.openjs.com/scripts/events/keyboard_shortcuts/ but it has some 
> limitations. Clement and I tried to find some unused combinations of keys 
> that works on Mac and Unix and we couldn’t find any that worked with it. It 
> also doesn’t support having combinations with several letters for example.
> 
> For example we could imagine having H+H+H for turning on/off hidden documents 
> (as a developer key sequence since it’s not a user use case).
> 
> I’d like to propose using https://dmauro.github.io/Keypress/ which is under 
> the Apache 2 license and that seems to work well on Mac and Unix and it’s 
> very powerful.
> 
> See sequence combos for example.
> 
> The API look simple and nice and I don’t think it would be hard to continue 
> support our data structure inside the “shortcuts” variable to make it work 
> with it.
> 
> WDYT?
> 
> Thanks
> -Vincent
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [xwiki-devs] Xwiki Development Question

[Paul Libbrecht]

> On 26 May 2017, at 19:27, Stefan Platon  wrote:
> 
> Hello. Could you tell me how can I take some values from an html form and set 
> them to a xwiki class' attributes? Thank you.


Hello Stefan,

I’ve learned a lot of XWIki internals when following this tutorial (well, an 
earlier version of it):

http://platform.xwiki.org/xwiki/bin/view/DevGuide/FAQTutorial/FAQTutorialManual
There you can see how a form can be made (using velocity) and let it update 
values on an XWiki object and its attributes defined by the class.

Hope it helps.

paul


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [xwiki-devs] [Introduction][GSoC]

[Paul Libbrecht]

Hello Sarthak,

so what’s your next steps?

It was recommended to endorse an issue. That could be one way to start.

But maybe before that, you could create one or two own applications beyond 
simple tutorials that would empower you with the tricks of page rendering?

paul

> On 15 May 2017, at 20:45, Sarthak Gupta <sarthakgupta...@gmail.com> wrote:
> 
> Hi Vincent,
> I am done with the FAQ tutorial. I now have the basic idea that how a page
> in XWiki is created. Though I am facing some difficulty with the syntax,
> but I know it will come with time. :)
> As far as I have understood there are generally two ways to create an
> application in xwiki. The first one is by simply using AWM and another one
> is by declaring data xobject(classes), following procedures afterward and
> writing codes which certainly add more to the application.
> 
> I saw some slides by Guillaume Delhumeau about using velocity in XWiki.
> Those have helped me a lot(Thanks, Guillaume!!).
> 
> I went through the following things
> 
>  - Continuous Integration doc. I understood the technique of Binary
>  Dependency builds.
>  - Coding styles on each of the languages that are used.
>  - Back-end Development Practices:
> - Component module documentation.(I have to understand it more
> clearly, maybe later).
>  - Front-end Dev Practices.
>  - Building XWiki from sources.(Looked it in Application period too).
>  - Basic Idea how testing is done. In a nutshell, each and everything is
>  tested at each subsequent stage.
> 
> I have already asked most of my small doubts on IRC(some of them were silly
> :P).
> New IRC Handle: sarthakg
> 
> Thanks
> 
> Sarthak Gupta
> 
> On Tue, May 9, 2017 at 10:11 PM, Vincent Massol <vinc...@massol.net> wrote:
> 
>> Hi Sarthak,
>> 
>>> On 9 May 2017, at 12:56, Sarthak Gupta <sarthakgupta...@gmail.com>
>> wrote:
>>> 
>>> Thanks Everyone,
>>> 
>>> I will try to update about my progress every week(Every Monday). I am
>>> spending this week mainly learning about basics of Velocity and some more
>>> on Java. Meanwhile I am also going through developers guide and looking
>> for
>>> issues that I can start with. Also I think I would have to think(and
>>> research) about, what would be the requirements that I would need in the
>>> initial stage of development of the "Glossary Application”.
>> 
>> Welcome aboard! :)
>> 
>> To start with, I’d recommend that you follow the FAQ tutorial at
>> http://platform.xwiki.org/xwiki/bin/view/DevGuide/
>> FAQTutorial/FAQTutorialManual
>> 
>> Have you done it already?
>> 
>> Also you should read a bit on how the xwiki project develops code. All the
>> info is on the dev subwiki at http://dev.xwiki.org
>> 
>> Especially:
>> - http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices
>> - http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle
>> - http://dev.xwiki.org/xwiki/bin/view/Community/Testing
>> 
>> Let us know when you’ve done all that. You should also pick and try to fix
>> some simple jira issues:
>> https://jira.xwiki.org/issues/?jql=Difficulty%20%3D%20Easy%
>> 20and%20resolution%20%3D%20Unresolved
>> 
>> Let us know on IRC or on this list if you need some help. Please consider
>> using martrix for IRC since it saves history and we can have a conversation
>> even when you’re not connected, see:
>> http://dev.xwiki.org/xwiki/bin/view/Community/Chat
>> 
>> Thanks
>> -Vincent
>> 
>>> 
>>> Thanks :)
>>> 
>>> On Mon, May 8, 2017 at 8:21 PM, Marius Dumitru Florea <
>>> mariusdumitru.flo...@xwiki.com> wrote:
>>> 
>>>> Welcome Sarthak!
>>>> 
>>>> Thanks,
>>>> Marius
>>>> 
>>>> On Sun, May 7, 2017 at 8:51 AM, Sarthak Gupta <
>> sarthakgupta...@gmail.com>
>>>> wrote:
>>>> 
>>>>> Hi Everyone,
>>>>> I am Sarthak Gupta from India. First of all I want to thank XWiki
>>>> community
>>>>> for selecting me for GSoC-17 and giving me a priceless opportunity to
>>>>> contribute to this organisation and improve my present skills. I also
>>>> want
>>>>> to thank all the XWikiers who helped me during the application period
>> for
>>>>> understanding the project as well as the organisation. :)
>>>>> 
>>>>> I have been selected for for the project "*Glossary Application*" under
>>>> the
>>>>> mentorsh

Re: [xwiki-devs] [PROPOSAL] What name for the minimum XWiki flavor

[Paul Libbrecht]

How about Skeleton?

paul

> On 03 Apr 2017, at 16:18, Thomas Mortagne  wrote:
> 
> Hi devs,
> 
> Since 8.0 we have in xwiki-platform a flavor simply called "XWiki
> Flavor" which contains more or less the strict minimum to have
> something you can call an XWiki instance (Administration, Extension
> Manager, a home page, etc.).
> 
> Since we want to promote the new Knowledge Base flavor have a
> concurrent called "XWiki" is not really making it a favor so we should
> probably find another name for it.
> 
> Here are some ideas:
> 
> 1) "XWiki" Flavor, it's Ok after all
> 2) "Default" Flavor
> 3) "Base" Flavor
> 4) "Lite" Flavor
> 5) "Mini" Flavor
> 6) "Minimum" Flavor
> 7) "Pico" Flavor
> 8)  Flavor
> 
> I don't think keeping "XWiki" is such a great idea. Default is even worst.
> 
> I like "Lite" but might sound too much like "the very limited free
> version, you are going to have advertisement in a month" theses days.
> 
> If I had to vote for only one it would be "Mini" but I'm fine with any
> of the following proposals.
> 
> Thanks,
> --
> Thomas Mortagne



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [xwiki-devs] [GSoC] More extension repositories

[Paul Libbrecht]

Krszysiek,

considering fashion, I think it would be a good idea to not avoid NPM.

paul


> On 01 Apr 2017, at 10:40, Krzysiek Płachno  wrote:
> 
> I've went through the repositories suggestions and I think the most
> interesting ones (at least for me) are: Nexus, Pypi and Ivy. (The next in
> the row would we Artifactory).
> Since it's always better to do less but completely and well, I would go for
> these three in my proposal, especially taking into consideration that
> integrating Pypi will require some Python-Java integration.
> Is it ok?
> 
> Best,
> Krzysztof
> 
> 2017-03-29 18:13 GMT+02:00 Thomas Mortagne :
> 
>> Also it's possible you have other ideas of repositories from other worlds.
>> 
>> I just added NPM to the list which is interesting too (that would
>> probably means automatically package npm packages as webjars or
>> something like this).
>> 
>> On Wed, Mar 29, 2017 at 6:07 PM, Thomas Mortagne
>>  wrote:
>>> Note that some of the ideas on
>>> http://design.xwiki.org/xwiki/bin/view/Design/
>> ExtensionManagerRepositories
>>> are quite wild, supporting a Debian repository for example is probably
>>> totally useless in practice.
>>> 
>>> On Wed, Mar 29, 2017 at 6:06 PM, Thomas Mortagne
>>>  wrote:
 Those lists are just ideas.
 
 The number of repositories to put in your proposal is what you feel
 you can do during the GSOC. Some repositories being more complex than
 others (for example Pypi implying supporting registering Python
 packages) but are also more interesting ;)
 
 On Wed, Mar 29, 2017 at 5:33 PM, Krzysiek Płachno
  wrote:
> Hi,
> 
> I'm about to prepare a plan and timeline with milestones for the task
>> "More
> extension repositories ". The page with design details (
> http://design.xwiki.org/xwiki/bin/view/Design/
>> ExtensionManagerRepositories)
> gives 10 examples of repositories to set an integration with, whilst
>> the
> description of task on XWiki GSoC information sub page refers only to
>> 3:
> Nexus , Bintray , Pypi (
> http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/
>> Moreextensionrepositories2017)
> .
> 
> So the task for GSoC work includes integration with all those 10, or
>> just
> those 3? I need to know it to plan well the milestones.
> 
> Best,
> Krzysztof
 
 
 
 --
 Thomas Mortagne
>>> 
>>> 
>>> 
>>> --
>>> Thomas Mortagne
>> 
>> 
>> 
>> --
>> Thomas Mortagne
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [xwiki-devs] [GSOC] XWiki has been selected as a Google Summer of Code 2017 mentor organization !

[Paul Libbrecht]

Hello XWiki community,

It would be interesting to get cool projects’ students for this GSoC.

The list is quite big already and I have just added two more projects.
To motivate everyone, here’s the current list.
Finish and improve Android XWiki authenticator and contact synchronization 

DokuWiki importer 

Translation in context 

More extension repositories 

Improve l10n.xwiki.org 

Glossary Application 

RedPen Integration 

ePub Creator 

Search calibrator 

Please jump by!

Paul

> On 28 Feb 2017, at 19:58, Thomas Mortagne  wrote:
> 
> Hi XWikiers,
> 
> Good news, this year again XWiki has been selected as mentor organization !
> 
> The next step is for mentors to register to
> https://summerofcode.withgoogle.com/ as ask to be mentor for XWiki
> project (admins can also send invitations). Also don't hesitate to add
> more proposals on
> http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/ (there is only
> proposals from two mentors right now), more details or co-mentor
> existing proposals.
> 
> Some students already started to communicate with the community which
> is great so continue and read
> http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines to
> have a better idea of how to get more chance to be selected by XWiki
> mentors.
> 
> Good GSOC 2017 !
> --
> Thomas Mortagne



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [xwiki-devs] Improve l10n.xwiki.org GSoC Project

[Paul Libbrecht]

Hello Abishek,

On 12 Mar 2017, at 10:27, Thomas Mortagne  wrote:
> Curriki is not a very good example since it's pretty much dead.

Just to make it a tick clearer: Curriki powered by XWiki using the “XCLAMS” 
application (xclams.xwiki.org) is dead on curriki.org which has chosen another 
way.
It is alive on http://planete.sankore.org/xwiki/bin/view/Search/WebHome and on 
http://i2geo.net.
Both use fairly old versions of XWiki (to say the least) and are not in very 
active development.

For such big applications, an internal translation workflow was chosen which 
complements the default XWiki translations.
An example of it can be seen http://translators.i2geo.net/  where translators 
translate complete “properties” pages and tools to support the migration are 
described.


The method for current XWiki platforms is generally that of Thomas described 
below.

Paul

> The main one is "XWiki Platform" (but often takes a long time to
> load), then you have to choose the translation resource you want to
> translate (the biggest one is "XWiki Core Resources") by cliking on
> "view" in the "Actions" column, then you can choose your language in
> the list.
> 
> The alternative is to use the search on the left when you want to fix
> a specific translation for example.
> 
> On Sat, Mar 11, 2017 at 5:13 PM, Abhishek Sharma
>  wrote:
>> Hi Thomas ,
>> 
>> 
>> Sorry to bother you again..
>> 
>> As suggested by you, I created an account on l10n.xwiki.org and was looking 
>> around how the stuff works, but I was completely lost.  There is a side bar 
>> showing the list of available applications, but when I open one of them say 
>> Curriki. I could not find how to provide translations in my preferred 
>> language.
>> 
>> 
>> Can you please help me out in figuring out how the stuff works so that I can 
>> create a proper user flow for the redesign (roadmap of which I'll eventually 
>> submit in my GSoC proposal)
>> 
>> 
>> I have already subscribed to the mailing list as you suggested.
>> 
>> 
>> I really look forward to work on the redesign of this project since this is 
>> an interesting project of XWiki.
>> 
>> 
>> Kindly spare some time from your schedule to help me, as it shall help in my 
>> GSoC proposal
>> 
>> 
>> Thanks and regards
>> 
>> Abhishek
>> 
>> 
>> From: Thomas Mortagne 
>> Sent: Friday, March 10, 2017 2:24:08 PM
>> To: Abhishek Sharma; XWiki.org
>> Subject: Re: Improve l10n.xwiki.org GSoC Project
>> 
>> Hi Abhishek,
>> 
>> I just saw your message on IRC (I guess it was you). Most of XWiki
>> committers are GMT+1 or +2 so you sent your message not long before
>> people start arriving probably.
>> 
>> It's great to see someone interested in improving that old thing :)
>> It's a very important part of the XWiki project but it's hard to find
>> devs interested in working on it.
>> 
>> The first thing to do usually is look at http://gsoc.xwiki.org/. In
>> case of http://l10n.xwiki.org you should also probably create an
>> account there and look at how it works (maybe try translating a few
>> things in some not complete language you master for example) to better
>> understand the (many) things that could be improved.
>> 
>> Also you should use the mailing list instead of sending me mails
>> directly, see http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists.
>> 
>> Welcome in XWiki community :)
>> 
>> On Fri, Mar 10, 2017 at 8:43 AM, Abhishek Sharma
>>  wrote:
>>> Hello Thomas,
>>> 
>>> 
>>> I am a student from India, and a budding UX Designer.
>>> 
>>> I found the Improve l10n.xwiki.org GSoC project quite interesting and wish
>>> to work on it, Can you please let me know, how to get started? Is there
>>> anything I can do to increase my chances of selection other than working on
>>> my proposal?
>>> 
>>> 
>>> Thank you for your time
>>> 
>>> 
>>> Regards
>>> 
>>> Abhishek
>> 
>> 
>> 
>> --
>> Thomas
> 
> 
> 
> --
> Thomas Mortagne



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [xwiki-devs] [VOTE] Move from our mailing lists and use Discourse instead

[Paul Libbrecht]

It looks really interesting and I trust our community governance to take an 
amount of advantages of it.
My +1 too.

paul

> On 01 Mar 2017, at 10:18, Marius Dumitru Florea 
>  wrote:
> 
> +1 to try it out.
> 
> Thanks,
> Marius
> 
> On Fri, Feb 24, 2017 at 1:18 PM, Vincent Massol  wrote:
> 
>> Hi devs,
>> 
>> I’m proposing to vote for moving away from our users and devs mailing list
>> and instead to use the Discourse open source tool:
>> 
>> * Home page: http://www.discourse.org/
>> * License: GPL v2
>> * FAQ: http://www.discourse.org/faq/
>> * Awesome feature list: http://www.discourse.org/about/
>> 
>> What is especially interesting for us:
>> * It works with mailing lists (you can receive mails and send mails to the
>> forum).
>> * Works as a forum. BTW if you want to see a real life instance, check the
>> gradle instance at https://discuss.gradle.org/
>> 
>> Nice things:
>> * Works on mobile
>> * Comprehensive API (would allow us to integrate it with xwiki.org)
>> * Badges/user metrics
>> 
>> So here’s my +1 to try it out and ask XWiki SAS if they could host an
>> instance.
>> 
>> WDYT? Do you see any negative point (I don’t ATM)? :)
>> 
>> Please cast your votes!
>> 
>> Thanks
>> -Vincent
>> 
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [xwiki-devs] [Proposal] Entry point for Extensions

[Paul Libbrecht]

On 14 Oct 2016, at 19:03, Thomas Mortagne  wrote:
> For me this is already the job of the uix we use for application panel
> so I don't really see the point of adding something else.

Well, that would be a job for extensions.xwiki.org:
- prioritise entry-points in search results
- display appropriately that some extensions are of a given type (entry-point, 
dependency, … macro?)

paul


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Having the docextra tabs in edit mode.

[Paul Libbrecht]

Guillaume,

would you not rather be in favour of an attachments’ tab display (it could be 
iframed) as pop-up for the wiki editor?
And the let JS modify the action on link-click to be a selection, and then make 
selection insert something useful depending on the type of the selected item 
and, possibly later, on the wiki-text around the cursor.

paul

> On 12 Oct 2016, at 18:47, Guillaume Delhumeau  
> wrote:
> 
> Just some remarks before I go:
> * As a developer, I always use the Wiki editor, and even for me it's a pain
> to go to view mode to upload a file (for example, an image in the release
> notes).
> * I never use drag in whatever application I have. I have never liked
> it because it requires to open a file explorer specially for that and it's
> always a pain because I use applications in full size mode. I'm sure I'm
> not the only one so I'm not fond of having it as the only way to upload
> attachments.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] New Best Practice for closing issues as Duplicate

[Paul Libbrecht]

Manuel Smeria wrote:
> So, what I propose is that we don't close original issues as Duplicate
> unless it falls into the category previously described or some other
> exceptions that I can't think of now and might occur.
To me it makes a lot of sense to close the bug together with its
manifestations.

Even better for the quality: once the developer issue is closed, the
manifestation creators are asked to revalidate their manifestation and
close it themselves.

I agree this breaks the issue-counts...

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [PROPOSAL] Make {{html}} default behavior be clean=false

[Paul Libbrecht]

Marius Dumitru Florea wrote:
>> TBH I don't remember exactly why we introduced the HTML Cleaner but we
>> > probably had issues at some point. Anyone remembers?
> The main reason for me is because we don't want simple users to break the
> XWiki page layout when they copy & paste HTML from the web: "I pasted this
> content, saved and now the edit button doesn't work anymore..". As Vincent
> said, the HTML macro is not intended only for developers. So I'm -0, close
> to -1.
Can such a breakage really happen?
Doesn't the editor's "back-from-html" already do the cleaning anyways?
Users that input html using the html macro in the menu or using the wiki
editor appear to be a responsible category of users.

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Designing the perfect FS representation of a wiki

[Paul Libbrecht]

Hello,
>> > The drawback is that you cannot have it when you export the page (no 
>> > bijection).
> Yes I didn’t mention this option because for me it’s not an option and it”s 
> not going to work:
> * As you say there’s no bijection, that’s the main issue
Well, my suggestion of yesterday night, comment-like-markers inside the
source stored inside the XARs' XMLs and Wiki content, can make it possible.
> * won’t fully work in some cases. Imagine a Velocity macro wrapping an HTML 
> macro. You can edit with a velocity editor but then you loose the HTML 
> edition or you can edit in an HTML editor but then you loose the velocity 
> syntax.
That is left to the developer to decide with the concept of an include:
if the developer decides that this part is better written as markdown,
properties, groovy, velocity, svg, or html, it's all left to him or her.
This kind of freedom is what makes a source project a valuable asset to
have as opposed to a running programme.
> My feeling is that using a specific editor doesn’t bring that much value 
> compared to editing directly in XWiki (using the syntax hilighiting and 
> autocompletion extensions). For example I also use IntelliJ IDEA to edit the 
> XWiki .vm files (velocity content) and I’ve never felt that it was providing 
> a much greater experience.
Here, I think that you need to take in account people who are really
unused to the XWiki API.

If you use such a comment in velocity files, for example:
#* @vtlvariable name="escapetool"
type="org.apache.velocity.tools.generic.EscapeTool" *# ##
you obtain autocompletion in IntelliJ on the escapetool's function which
I was never able to properly remember.
Surely, there are more experienced XWiki developers out there... But
there are also less experienced ones...

Indeed, however, the HTML that might be generated, as opposed to a wiki
syntax, is never going to be completely decidable within an IDE and I
think that everyone can live with that.

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Designing the perfect FS representation of a wiki

[Paul Libbrecht]

I think that we are converging to agree that includes and bijection are,
in the current situation, not reconcilable.

Would there not be a possibility to mark the content with something
similar to "comments" (aka "ignorable content") so that the included
parts have a defined filename and a defined extent?

Paul

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Designing the perfect FS representation of a wiki

[Paul Libbrecht]

Vincent Massol wrote:
>> > http://nexus.xwiki.org/nexus/service/local/repositories/public/archive/org/xwiki/platform/xwiki-platform-oldcore/7.4.2/xwiki-platform-oldcore-7.4.2-javadoc.jar/!/com/xpn/xwiki/api/XWiki.html#parseGroovyFromPage(java.lang.String)
> This is mostly deprecated. The new canonical way to have groovy in a page is 
> now to use the {{groovy}} macro, and you can {{include}} a page that’s using 
> {{groovy}} if you need to bring it to another page.
You do not reach such an impact doing that. Far from it!
(e.g. if you want search cursors that fetch from some other data
sources; sure you can do it in Java but the Groovy way is much faster
developed).
> Note that in the xwiki core dev we don’t use groovy at all since this 
> requires PR and makes it very fragile and a pain for our users.
Does this mean that apps don't use it?
Or that you wish the FS representation to not support it in a way that
makes the file source-files?
>> > and it seems widely used from searching the repositories.
>> > (e.g.
>> > https://github.com/xwiki-contrib/application-l10n/blob/master/src/main/resources/L10NCode/CompareTranslationFile.xml
>> > which calls it on
>> > https://github.com/xwiki-contrib/application-l10n/blob/master/src/main/resources/L10NCode/L10NGroovy.xml)
> Which is a xwiki/1.0 syntax page btw. IMO it should have been plain/1.0 
> instead.
I don't see the point saying that this is a wiki 1.0 syntax (or
plain-text) except for rendering. This page is a "groovy page" meant to
be used by parseGroovyFromPage; it has no value displaying it thus the
syntax can be whatever you want...

If I follow your logic, it should be, within a
file-system-representation, a file with such a name as "content.txt".
Then again... since you have no flexibility of names, you have to hack
things around to make an IDE edit this file and recognize it as a groovy
file.

>velocity ... and is often embedded in macros.

>
> Not sure what you mean by vm files embedded in macros. 
Did I say vm files? I said vm fragements.
> What type of macros are you thinking about 
the velocity macro.
> and what’s the relationship with wiki pages?
Generally, as far as I know, this is used to generate content.

Here is one of first tutorials...
  http://platform.xwiki.org/xwiki/bin/view/DevGuide/WikiMacroTutorial
The velocity suggested there can be very much bigger and being able to
split it out within a .vm file for you to edit with an IDE (and enjoy
auto-completion, method-analysis, and syntax-coloring) is, I believe, an
essential function of an FS representation.

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Designing the perfect FS representation of a wiki

[Paul Libbrecht]

>>> >> So I guess what I’m saying is that for me what would help the most the 
>>> >> current workflow used by the xwiki core dev team is:
>>> >> * the introduction of the xar:fetch and xar:deploy mojos
>>> >> * the validation (to help prevent mistakes)
>>> >> * the extraction of the attachments as standard files on the file system 
>>> >> so that they can be replaced easily
>> > Plus at least extract the JS-extensions and CSS-extensions as JS and CSS
>> > files at least or?
> Yes those are content for me (what I meant by content is doc content + all 
> xproperties of type textarea).
ok, so that's deterministic at least (but sometimes too much?)
Also, how do you determine the extension ? (seems like the object nature
would dictate that...).
>> > And the same holds for velocity and groovy code or?
>> > But here, I cannot find a way that would make it clear that a given
>> > object property or page content is in velocity, groovy, or .
>> > Is there a way?
> They’re not in groovy or velocity, they’re in some markup syntax (e.g. XWiki 
> Syntax 2.1).
Mmh, here I am really not convinced.
I've seen many pages be only designed to be used using
parseGroovyFromPage. Is this something that is deprecated now?
I've also seen velocity-based content to be the core of the UI of most
applications and be contained in the content of pages.

>From the description you make, the files would not be .vm or .groovy
(actually, there would be none, right?) but using some
wiki-syntax-extension. Right?

To me, it seems like having .vm and .grv or .groovy files is essential.
I would be alone?

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Designing the perfect FS representation of a wiki

[Paul Libbrecht]

Vincent Massol wrote:
> So I guess what I’m saying is that for me what would help the most the 
> current workflow used by the xwiki core dev team is:
> * the introduction of the xar:fetch and xar:deploy mojos
> * the validation (to help prevent mistakes)
> * the extraction of the attachments as standard files on the file system so 
> that they can be replaced easily
Plus at least extract the JS-extensions and CSS-extensions as JS and CSS
files at least or?

And the same holds for velocity and groovy code or?
But here, I cannot find a way that would make it clear that a given
object property or page content is in velocity, groovy, or .
Is there a way?

Paul

PS: while it seems like there's been rules set so that one shouldn't
fiddle the XML to break XAR parsing, I am really surprised that there's
not been rules defined to avoid gross JS, CSS, velocity, or groovy
errors. Is that true?
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Legal notice for xwiki.org

[Paul Libbrecht]

>> Note that each country has a different requirement for this kind of page.
>> Maybe this is a place to asllocate for all wikis?
> Not sure I understand what you mean. This site is hosted in France.
And I was talking about extending to other countries but probably I
should have started another thread.
>> PS: in the http://www.xwiki.org/xwiki/bin/view/Main/LegalNotice/ I see
>> that you're talking of a cookie, which is probably EU-required. However,
>> the text doesn't say that we set cookies from the start on; are we not
>> doing that?
>
> Are we? 
Yes, we are. I just tried with an almost virgin firefox. It had no
xwiki.org cookies.
> I thought the cookie was only created when you’re checking the “remember me” 
> option.
After I visited xwiki.org's home page I have cookies for:
- xwiki.org:
  - _cfduid (cloudflare loves tracking so as to protect against attackers)
  - JSESSIONID
  - _ga, _gat: Google analytics which we are using (not a very good
example for the others!)
  - mf_user and some mf_xxx (maybe cloudflare?)

So in addition to saying that we set cookies for any visit, we should
also that we let third-party service delivery companies also set cookies
(Cloudflare Inc, Google Inc, and XX).

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Legal notice for xwiki.org

[Paul Libbrecht]

Note that each country has a different requirement for this kind of page.
Maybe this is a place to asllocate for all wikis?
For a site hosted in Germany, that page is called an "Impressum" and
beyond the terms of use, it also has the duty to indicate a full name
and address of the owner of the website. That'd be a person that a
lawyer should reach to, if a blatant copyright issue would be detected.
I would be in favour of extending this page to any XWiki entreprise.

paul

PS: in the http://www.xwiki.org/xwiki/bin/view/Main/LegalNotice/ I see
that you're talking of a cookie, which is probably EU-required. However,
the text doesn't say that we set cookies from the start on; are we not
doing that?

Ecaterina Moraru (Valica) wrote:
> The best place would be the "About" section.
>
> What will be the name? "Legal"?

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Designing the perfect FS representation of a wiki

[Paul Libbrecht]

Hello Guillaume,

> Guillaume Delhumeau 
> 29 August 2016 at 11:03
> Paul, your comment makes me think about https://xkcd.com/927/ :)
Good point!
Let's drive this quietly indeed.
>
> Now, as far as I can see, all the previous attempts where made by
> individuals. Nothing have been really discussed and designed by the whole
> team. Which is why I believe this new attempt could be the good one.
Agree.
> Moreover, Vincent is not starting form scratch but on the Fabio's project.
On a language that I find largely inferior to the previous one since
it's whitespace dependent as Python is which all developers I met find
very doubtful. But well... that's personal.
> We only need to make some improvements on it.
>
> About my expectations:
>
> * I need a format that gives the same result when I export my content
> after
> having imported it (bijection).
Please clarify here: do you need that for all projects of everyone of
just for the projects you intend to work with?
(that relates to the claim that we can have "source and push" projects
to be different form "source bijection wiki")
> * I would prefer having it respecting the Nested Page hierarchy (ie: no
> space concept).
> * Easy to edit with whatever text editor. Maybe using a correct suffix to
> enable the syntax highlighting easily: for example I usually edit my
> content inside a file holding the ".vm" extension so my editor knows I
> will
> write some Velocity code in it.
+1
I also claim that freedom in the extensions is better.
> I never write code from scratch in my file system. But if I had to, I
> suppose the hierarchy that Vincent suggests would be too complex. It might
> be a problem for the developers who have written XFF and the NodeJs tools
> which have code to be imported in XWiki, but does not have output filter
> now.
So you want freedom in the directory layout?
This might make sense to join to other build systems btw... (e.g. the
package task that includes a JS compilation or some documentation
generation).

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Crafting method to add a plugin to the CKEditor?

[Paul Libbrecht]

Hello Marius,

(for the hook, well, I found a polling solution which worked. But surely
something else would be better. No urgency)


Now, I am still fighting trying to inject the appropriate reformulation
from an image or a math element (which the Wiris plugin for the CKEditor
converts to) to a Macro.

As suggested I use CKEditor.editor's toHtml and toDataFormat events.
I've managed to catch the parsing stage and replace the MathML macros by
math elements which then get converted by the Wiris plugin to their
image (including listeners for them to edit when double clicked) by
hooking into the level 6 of parsing.

How can I know which level I can hook to to reformulate the content just
before it is sent to the conversion server?
I've tried levels from 5 to 15 of the event toDataFormat and 15 seems to
be the best idea... Unfortunately the changes are not sent, an earlier
version is sent...
Can it be that there's been a copy of the data before that?
Where should I look?

thanks in advance.

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Use cases for an alternative filesystem format (alternative to XAR)

[Paul Libbrecht]

Vincent Massol wrote:
>> My only point is that we need to support both use cases:
>> > - round trip strategy (i.e. write in wiki, test, export, save)
>> > - source tree changes strategy (i.e. write in source, push, test, fetch, 
>> > save)
>
> To be more precise:
> - round trip strategy (i.e. write in wiki, [test, make changes]*, export, 
> save)
> - source tree changes strategy (i.e. write in sources, [push, test in wiki, 
> make changes locally]*, save)
I agree we need to support both.
The more fundamental question is: do we need to support both with the
same sources?

My claim is that this is close to impossible, especially if one wants to
leave a lot of freedom to the developers to layout the source the way
they want.

If the sources do not need to be equal (i.e. a source project does not
need round-tripping equality) then I think we're safe.

Paul


___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

Vincent Massol wrote:
>> * Modify XWiki’s export to use CDATA instead of xml-encoding the contents. 
>> This allows to more easily and manually copy content into separate files.
>
> BTW on a related note, I was wondering if XInclude allows including non-XML 
> encoded content. I’ve found 
> https://msdn.microsoft.com/en-us/library/aa302291.aspx#xinc_topic4 which 
> seems to indicate it’s supported (with parse=text and by using the encoding 
> attribute too).
Sure it does and this is unit-tested! See the xincludeTTest.xml in here
 
http://direct.hoplahup.net/tmp/xwiki-commons-tool-xar-plugin/src/test/resources/org/xwiki/tool/xar/
it is tested to match xincludeTProof.xml.
However, it does not do base64 conversion... Hence I've introduced two
elements textInclude (does the same, just no namespace fuss) and
binaryInclude) includes the attachment converted to base64.

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Use cases for an alternative filesystem format (alternative to XAR)

[Paul Libbrecht]

Vincent,

I think we disagree on two major aspects which are kind of related:

- writing document structure and metadata should be doable by hand
editing as opposed to writing into the wiki alone:
  - I believe this is a fundamental aspect of source editing and should
be supported (hence the wish to a validatable widespread syntax)
  - you seem to indicate that the current process you've agreed upon has
discouraged it (but, at the same time, you indicate you wish to do it
for YAML)

- writing XML can be done by hand and is easy:
  - I am a strong defender of this: all editors I've worked with
(IntelliJ IDEA, jEdit, BBEdit, XCode, maybe not vim) support XML very
well so that it's just careless to commit a && (not to mention that mvn
would not validate it, and would not build it if with my patch, simply
because it parses). Clearly, editing in a textbox can get you there,
same with MS Word!
  - you seem to say that bad things happen with such commits as not even
valid XML documents and seem to motivate that to move to another format
(I feel YAML a zillion less predictable than XML because of whitespace
handling btw).


Paul

PS: when I say editing XML is for sane people, I don't mean everything
should be XML, which is why I proposed the XAR extension to include
XInclude, textinclude and binaryInclude.

PPS: another, maybe deeper, disagreement might be the need to round-trip
(server, source) vs the need to source-edit: hand-tuning the format of a
file (e.g. in XML or in JSON) is easily in contradiction with a server
generation from a structured source. Maybe this is the hard bone.




> Vincent Massol <mailto:vinc...@massol.net>
> 27 August 2016 at 17:50
>> On 27 Aug 2016, at 16:46, Vincent Massol <vinc...@massol.net> wrote:
>>
>>> On 27 Aug 2016, at 15:44, Paul Libbrecht <p...@hoplahup.net> wrote:
>>>
>>> Thanks for having this extra thread.
>>> I think this thread is much more important than starting to design
>>> something already.
>>>> Issues with the XAR format
>>>> ==
>>>>
>>>> * XML is not an easy to edit format and doesn’t allow use a specific
>>>> editor to edit content
>>>> * XML also requires content to be XML-encoded and thus is really not
>>>> easy to make modification (there’s a risk of breaking the XML easily)
>>> I completely disagree with these two statements.
>> I probably didn’t use the right words because that’s the reason why I think 
>> that's you started the xinclude proposal :)
>>
>> AFAIK you started the xinclude proposal because you wanted to be able to 
>> edit content with specific editor (js, css, etc)… which is exactly what the 
>> second part of the first point is about.
>>
>> Let me rephrase the first sentence:
>>
>> * XML is not an easy to edit format for human beings (it’s very verbose and 
>> easy to make mistakes: missing encoding, etc). It’s also very hard to edit 
>> with a plain text editor.
>>
>> As for the 2nd sentence, I don’t see how you can disagree since it’s a 
>> fact...
>>
>>> XML is easy to edit and is supported by very very many editors and IDEs.
>>> It can also be validated.
>> What you’re saying is very theoretical. The practice (that we’ve had for 10 
>> years of using the XAR format) is that our XML format that is hard to edit 
>> and can break easily (as was proven numerous times by our committers and 
>> contributors). It’s actually so dangerous that we’ve had to develop a 
>> process which goes like this:
>> * Never edit the xml directly
>> * Always import it into a running XWiki instance, make the modifications 
>> there and export from the wiki into XAR
>> * Then unpack the XAR into the source directory and run mvn xar:format to go 
>> back to the original format.
>>
>> Nobody is using a pure XML editor with validation. We are all using Java 
>> IDEA (IntelliJ IDEA, Eclipse, etc) and they all allow you to edit XML as 
>> plain text and that’s what we’re doing. No developer I know of is using an 
>> XML editor in a structured way (just too painful and complex to navigate the 
>> structure).
>
> To be more specific, the main issue we’ve had is contributors/committers who 
> committed unencoded content, such as && instead of  or > instead of 
> 
>
> Now, to be accurate, if you remove the problem with the encoding (which can 
> be removed IMO with CDATA) then we never touch much of the rest of the 
> metadata.
>
> In practice it would be nice if most of it could be generated by the maven 
> plugin. In practice we don’t need much specific data (for a pure doc, it’s a 
> bit more for xclass/xobjects): titl

Re: [xwiki-devs] [Brainstorming] Use cases for an alternative filesystem format (alternative to XAR)

[Paul Libbrecht]

Thanks for having this extra thread.
I think this thread is much more important than starting to design
something already.
> Issues with the XAR format
> ==
>
> * XML is not an easy to edit format and doesn’t allow use a specific
> editor to edit content
> * XML also requires content to be XML-encoded and thus is really not
> easy to make modification (there’s a risk of breaking the XML easily)
I completely disagree with these two statements.
XML is easy to edit and is supported by very very many editors and IDEs.
It can also be validated.
XML can be written in a very elegant and readable fashion if you care
for it.
Generally however, XML is produced form other structured information in
a way that does not help readability.
> Can you see more issues?
The problem is how we put *everything* into XML.
(you get the same horror if you use Caleb's tools xardump and do not
tune anything: the resulting javascript is horrible.)
> Use cases for an alternative filesystem format
> ===
>
> (some UC taken from
> http://design.xwiki.org/xwiki/bin/view/Design/DirectoryStructureforXWikiApplications)
>
> * UC1: the structure should be (as) easy (as possible) to navigate in
> an IDE style view
> * UC2: it should be easy to add content (a new script or attachment on
> an existing structure). It should allow using specific editors for
> different content types, e.g. if a page content is in markdown, it
> should be editable with a MD editor, js and css should be editable
> with web editors, etc.
UC2.1: Attachments should also be present as standalone files.
> * UC3: It should be possible to build a packaged version of the
> sources with Maven
> * UC4: It should be possible to import the packaged version into a
> running XWiki instance
> * UC5: It should be possible to export a portion of a running XWiki
> instance in this format
> * UC6: This format should be able to fully replace the XAR format .
> The new format should support at least all features supported by the
> XAR format (versioned, etc). Note: XE will need to be refactor a bit
> so that the XAR format can be swapped out by introducing extension
> points/APIs. The idea would be to deprecate the XAR format and
> introduce this new format instead, and the 2 formats should be avle to
> cohabit next to each other in XWiki.
> * UC7: When importing in a wiki and exporting again (without making
> any change in the wiki), it should generate an identical structure and
> content, with no difference.
I do believe that UC7 is not doable in full generality.

Any more?

UC8: the core representation should be using a syntax that is widely
spread and completely specified (i.e. we should not invent another
syntax for this)

UC9: the system should make an archival process a widespread practice,
in the form of zipped files probably.

UC10: developers should have the discretion to decide when a component
needs to be in a separate file or not. That is, small text fragments and
even small attachments should be includable within bigger files

UC11: there should be the possibility to share content of a file between
several files or components (e.g. creator elements)

UC12: (transformation) simple search and replace operation should be
supported by the build mechanism, especially when dependencies are followed.

UC13: it would be good that the format can be specified by a grammer
against which one can validate (e.g. RelaxNG)

Paul

(FYI UC10, UC11, and UC12 follow the architecture recommendation to be
composable vs contextual so as to give us greater flexibility)
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Brainstorming] Designing the perfect FS representation of a wiki

[Paul Libbrecht]

Vincent Massol wrote:
> I think a first step is agreeing on the best representation and one we would 
> agree on.
Allow me a process comment: I think that this is the right way to start
yet another representation project, it would be the fifth project. Here,
we want to find something more conclusive, or?

I find it more important that people express their:
- experience
- expectations
- disappointments
...of the current representations of XWiki content and code stores.

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

>> Now we still wouldn’t be able to use it in the xwiki dev team because we 
>> need a round-trip solution (we need to be able to convert a wiki page into 
>> that structure). This is what Guillaume was mentioning.
>> >
>> > So we need to solve that first or it won’t have much of a future (and it 
>> > could be argued that there’s little rationale for putting this code in 
>> > commons if it’s not used).
> Is the warning proposal made to Guillaume sufficient?
And... which team do you mean?
The product team? All employees? All developers? The client team?

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

Vincent Massol wrote:
> Now we still wouldn’t be able to use it in the xwiki dev team because we need 
> a round-trip solution (we need to be able to convert a wiki page into that 
> structure). This is what Guillaume was mentioning.
>
> So we need to solve that first or it won’t have much of a future (and it 
> could be argued that there’s little rationale for putting this code in 
> commons if it’s not used).
Is the warning proposal made to Guillaume sufficient?

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

Vincent Massol wrote:
> Can I test it somewhere so that I can fully understand your technical 
> solution?
http://extensions.xwiki.org/xwiki/bin/view/Extension/DownloadAttachments/
is an example source with it.
This can also be browsed at:
   
http://direct.hoplahup.net/tmp/DownloadAttachments/src/main/resources/Macros/
where DownloadAttachments.xml includes DownloadAttachments_content.groovy.

I guess that the way to test it is to build and install the project I
have (which would be 8.3-SNAPHOT):

http://direct.hoplahup.net/tmp/xwiki-commons-tool-xar-plugin-8.3-SNAPSHOT-polx.zip
(which you'd obtain by applying the patch I've put in the jira).
> What I fail to understand is why you don’t want to commit your code in
> contrib. XWiki is a platform with extensions. You don’t need to be in
> the core to be able to contribute an extension to XWiki (XAR plugin is
> core).
I'd like to avoid forking. This creates niches.
My laptop is full of such attempts. Creating a github fork, a maven
polxar or something like this is fairly equivalent.

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

Hello VIncent,
> So for me the important part is for you to develop your solution in a 
> separate module in xwiki-contrib as a demonstator and possibly start using it 
> on some contrib project to validate it. The alternative is to work on XFF and 
> finish it.
Well. That brings the question back: how many are using it?
Obviously, I see almost no-one.
As long as:
- it is not complete
- it is not used by developers big time
... it will not be considered useful.
So... requesting to "go away" is very close to what you're asking, I feel.

In the contrary, I believe that changing the XAR plugin in a fully
conservative way is the way to go if one wants incremental progress.

Can it be that you did not notice, it is fully backwards compatible?
> Personally I’m not a big fan at all of modifying the existing XAR plugin for 
> various reasons:
> * We don’t know yet what solution we’ll choose in the future. At this point 
> in time I even have a preference for XFF. So it wouldn’t be fair and nice to 
> modify the existing XAR plugin with your solution and then have to remove the 
> code if we don’ want it in the future.
But obviously the time has not been invested about it.
All issues are closed for XFF.
> * It will be much simpler for you to develop your own project in 
> xwiki-contrib since you’ll have commit access (which you won’t have in 
> xwiki-commons).
That's a moot criterion.
My code is really not a big change and also not very high risk.

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

Guillaume,

The risk of dead code is always present at a developer.
But the addition of inclusions seems to make this risk higher for you.

Obviously we develop on very different wikis.
Mine tends to be having several development traces, often parallel,
sometimes not, and I will only reinstall if I really need it.
When developing xars, you seem to be trusting that yours contain just a few.

Because mine is crowdy, I will not trust a XAR export and will only pick
the necessary files and/or elements form a xar export, if at all, or
undergo a deep cleaning (which is typical at start).

Because yours (I assume) is somewhat clean, you trust a xar export and
commit it the eyes shut.
Thus introducing an include that would be forgotten makes it probable
for you and not for me, which is what you state.

What I can offer is to add to my ready available code that the validate
Mojo to check that no file that is not included in in the source tree.
Useful?
Offering a diff is tempting but it's a lot more complex I feel (e.g.
it's better if it's three way which developers rarely all have on a
single disk, one or two of them being on a versioning server).

Paul


Guillaume Delhumeau wrote:
> I would be very concerned if we have wiki pages with dead code in some
> repository.
>
> I am very skeptical, because if we cannot rely on the standard exporter to
> generate the source correctly, who will use these source files? When you
> develop an application, do you write it in the XML page in your repository
> or directly in your wiki?
>
> I am a bit conservative here and I don't want to block you, but I really
> wonder if the advantages you mention worth the pain of being sure we don't
> have dead code, and manually cutting/pasting some bit of the code from a
> file to an other everytime you commit a page (and I do it often).

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

Guillaume,

sure, this is *doable* but it can also be done at discretion.
E.g. you'd only copy from the exploded xar the other files you copied
but not the source.
Also, if you replace the XML files with those of the XARs, you'll just
ignore the sources, since you've removed the includes.

So, I really think that this is a progress.
I agree an XFF to XAR converter would be more interesting but my patch
is ready to be applied. A XAR generator is not yet.

paul

> Guillaume Delhumeau <mailto:guillaume.delhum...@xwiki.com>
> 23 August 2016 at 13:19
> Of course, we could still change our workflow and copy/paste source
> contents manually. Not sure it's gonna be more effective. So I prefer the
> XFF approach (except that I would love having a Nested Document
> terminology
> instead of the current Space/Document one).
>
> 2016-08-23 13:11 GMT+02:00 Guillaume Delhumeau <
>
>
>
> Guillaume Delhumeau <mailto:guillaume.delhum...@xwiki.com>
> 23 August 2016 at 13:11
> 2016-08-23 12:36 GMT+02:00 Paul Libbrecht <p...@hoplahup.net>:
>
>> Thomas Mortagne wrote:
>>> It takes the following IMO:
>>> * it works
>>> * it does not break any retro compatibility
>> both are claimed.
>> There are unit tests.
>> The only danger of breaking anything is if dom4j does not faithfully
>> restore the XML source. I believe this can be ignored just as it has
>> been ignored by the implementation of transformations.
>>> (probably not enabled by default for example)
>> No, it is enabled by default.
>> I could replace the dom4j output by a file copy if no relevant elements
>> are found.
>>
>> Note however, that it operates on elements that were never allowed before.
>>> Now Guillaume has a point. The issue you will quickly have as soon as
>>> you start using this is that you HAVE to modify your XAR trough
>>> filesystem because you can't edit it in XWiki and export it anymore.
>>> That is if you don't provide any tool to export this kind of XAR
>>> extension.
>> I believe this is best practice to insure that the wiki does not insert
>> you surprise elements such as the author name or the edit comment.
>
>
> In practice, this is the only manual step. I do a diff of the modifications
> I have made and I revert all changes that are meaningless. But it's quick &
> easy using my IDE (IntelliJ). I know some developers here do the same. The
> only issue is when the XAR format have changed: some fields are not ordered
> in the same way, and it makes harder to compute the real diff.
>
>
>
>> Is
>> this practice not corresponding at all what others are doing?
>>
>> Using an XML-diff might be answering Guillaume's point... That's not
>> completely trivial.
>>
>> Paul
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> Paul Libbrecht <mailto:p...@hoplahup.net>
> 23 August 2016 at 12:36
> Thomas Mortagne wrote:
>> It takes the following IMO:
>> * it works
>> * it does not break any retro compatibility 
> both are claimed.
> There are unit tests.
> The only danger of breaking anything is if dom4j does not faithfully
> restore the XML source. I believe this can be ignored just as it has
> been ignored by the implementation of transformations.
>> (probably not enabled by default for example)
> No, it is enabled by default.
> I could replace the dom4j output by a file copy if no relevant elements
> are found.
>
> Note however, that it operates on elements that were never allowed before.
>> Now Guillaume has a point. The issue you will quickly have as soon as
>> you start using this is that you HAVE to modify your XAR trough
>> filesystem because you can't edit it in XWiki and export it anymore.
>> That is if you don't provide any tool to export this kind of XAR
>> extension.
> I believe this is best practice to insure that the wiki does not insert
> you surprise elements such as the author name or the edit comment. Is
> this practice not corresponding at all what others are doing?
>
> Using an XML-diff might be answering Guillaume's point... That's not
> completely trivial.
>
> Paul
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> Thomas Mortagne <mailto:thomas.morta...@xwiki.com>
> 23 August 2016 at 12:28
> On Tue, Aug 23, 2016 at 12:26 PM, Thomas Mortagne
> <thomas.morta...@xwiki.com> wrote:
>> On Tue, Aug 23, 2016 at 12:17 PM, Paul Libbrecht <p...@hoplahup.net> wrote

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

Thomas Mortagne wrote:
> It takes the following IMO:
> * it works
> * it does not break any retro compatibility 
both are claimed.
There are unit tests.
The only danger of breaking anything is if dom4j does not faithfully
restore the XML source. I believe this can be ignored just as it has
been ignored by the implementation of transformations.
> (probably not enabled by default for example)
No, it is enabled by default.
I could replace the dom4j output by a file copy if no relevant elements
are found.

Note however, that it operates on elements that were never allowed before.
> Now Guillaume has a point. The issue you will quickly have as soon as
> you start using this is that you HAVE to modify your XAR trough
> filesystem because you can't edit it in XWiki and export it anymore.
> That is if you don't provide any tool to export this kind of XAR
> extension.
I believe this is best practice to insure that the wiki does not insert
you surprise elements such as the author name or the edit comment. Is
this practice not corresponding at all what others are doing?

Using an XML-diff might be answering Guillaume's point... That's not
completely trivial.

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

>> What I obtain after mvn package is a file my-application.xff.
>> > I can't seem to import that. Should I be able to?
> Not trough XAR tools no, it's completely different format.
So what needs to be done here is a converter which is a lot bigger than
a packager.
We'll see what Jean says.



In the meantime, do I understand at least that an enrichment to the
xar-mojo is a more conservative approach that might have a better chance
of uptake?
What does it take for me to get the patch accepted?

thanks

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

I've just tried it.
   http://direct.hoplahup.net/tmp/xffAttempt-first.zip
After having checked-out https://github.com/xwiki-contrib/api-xff and
run mvn -Denforcer.skip=true install.
What I obtain after mvn package is a file my-application.xff.
I can't seem to import that. Should I be able to?

thanks
Paul

> Vincent Massol <mailto:vinc...@massol.net>
> 23 August 2016 at 11:35
>> On 23 Aug 2016, at 11:15, Vincent Massol <vinc...@massol.net> wrote:
>>
>>
>>> On 23 Aug 2016, at 11:13, Paul Libbrecht <p...@hoplahup.net> wrote:
>>>
>>> Let's ask things differently: what's missing XFF for others to use?
>> I think it’s just missing a maven plugin to use it. All the other parts are 
>> ready.
>
> Actually just noticed that Jean has started one:
> https://github.com/xwiki-contrib/api-xff/tree/master/xff-maven
>
> I don’t know its status though.
>
> So what needs to be done is try the full chain and see what works/what 
> doesn’t.
>
> Unless jean could tell us what’s the status? (I’ll ping him on skype).
>
> Thanks
> -Vincent
>
>> Thanks
>> -Vincent
>>
>>> paul
>>>> Vincent Massol <mailto:vinc...@massol.net>
>>>> 23 August 2016 at 11:01
>>>> The format seems to be defined here:
>>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/XFF+filter#HFormat
>
> _______
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> Vincent Massol <mailto:vinc...@massol.net>
> 23 August 2016 at 11:15
>> On 23 Aug 2016, at 11:13, Paul Libbrecht <p...@hoplahup.net> wrote:
>>
>> Let's ask things differently: what's missing XFF for others to use?
>
> I think it’s just missing a maven plugin to use it. All the other parts are 
> ready.
>
> Thanks
> -Vincent
>
>> paul
>>> Vincent Massol <mailto:vinc...@massol.net>
>>> 23 August 2016 at 11:01
>>> The format seems to be defined here:
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/XFF+filter#HFormat
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> Paul Libbrecht <mailto:p...@hoplahup.net>
> 23 August 2016 at 11:13
> Let's ask things differently: what's missing XFF for others to use?
>
> paul
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> Vincent Massol <mailto:vinc...@massol.net>
> 23 August 2016 at 11:01
> The format seems to be defined here:
> http://extensions.xwiki.org/xwiki/bin/view/Extension/XFF+filter#HFormat
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> Thomas Mortagne <mailto:thomas.morta...@xwiki.com>
> 23 August 2016 at 11:00
> I can't give you much details on the XFF format, I just know the
> general goal. I only helped Jean on the "how to use Filter API" side.
>
>
>

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

Let's ask things differently: what's missing XFF for others to use?

paul
> Vincent Massol 
> 23 August 2016 at 11:01
> The format seems to be defined here:
> http://extensions.xwiki.org/xwiki/bin/view/Extension/XFF+filter#HFormat

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

Maybe what we need is a xar diff function ??
(compare my xar's source repo to the content of a wiki and say what
needs to be changed)

paul

> Guillaume Delhumeau 
> 23 August 2016 at 10:51
> To be extra-clear, let me explain my workflow when I design an application
> in XWiki.
>
> - First, I write my code directly in an instance of XWiki.
> - When it's ready, I export all the pages related to my application in a
> XAR.
> - Then, I uncompress my XAR inside my repository.
> - I clean the XML files using mvn xar:format.
> - I commit.
>
> And when I fix something, I do it directly in the wiki, then export the
> page in a XAR, uncompress it in my repository, clean the xml files
> manually
> (reverting the changed dates, etc...).
>
> What I don't want is to be forced to manually remove the source code from
> the XML to put it in the other file every time.
>
> Thanks,

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

Thomas,

I had seen this approach yesterday only.
I think my attempt is a tick more conservative.
But indeed, it seems to be the objective of the XFF filter.

Also, what I could not tell fully from the XFF attempt is whether the
optionality was there: are there property values or even complete
objects that I can leave gouped in some page XML? It seems to me that
itreally does not make sense to include them all in a file each. (e.g.
objects of the XWiki.TranslationDocumentClass).

paul





Thomas Mortagne wrote:
> Note that an alternative is to add a mojo in the XAR plugin (or write a
> new Maven plugin) based on Filter module to produce a XAR package from
> http://extensions.xwiki.org/xwiki/bin/view/Extension/XFF+filter which
> already been designed for what you want: provide a format that can be
> edited from filesystem easily. In theory all it takes is to put XFF
> filter in input and XAR filter in output and run.

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] XAR source projects should allow source files

[Paul Libbrecht]

> But do you also consider the opposite use-case: editing some code in the
> wiki, and then export a XAR containing the metadata in an XML and the
> content in a plain text file?
> Otherwise, it makes it harder to fix some code in the wiki directly before
> committing it in the repository.
No. Not for this case.
I guess it could be implemented by detecting which things are outside
and which are inside but it's not really trivial.

As far as I know, fetching the xar form the wiki really is a first step
which you do not do on a regular basis, you then push adjustments to the
wiki which you have edited in the source directory (e.g. using copy and
paste or attachments' uploader), then do an upload as a xar to make sure
it is clean.

The problem with fetching from the wiki is that it always inserts more
information than wanted.
E.g. a creator name, comments, ...
Whereas creating the xar from source can be tailored to not contain any
of this information (and part of that is checked by the xar mojo).
Am I wrong?

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Crafting method to add a plugin to the CKEditor?

[Paul Libbrecht]

Hello Marius,
> CKEditor provides
> http://docs.ckeditor.com/#!/api/CKEDITOR.editor-event-toHtml and
> http://docs.ckeditor.com/#!/api/CKEDITOR.editor-event-toDataFormat . 
Can you give an example on how to hook it?
At least hooking it in the instanceCreated (calling then
  ckeditor.on( 'toDataFormat', function( evt) {
console.log("toDataFormat"); }, null, null, 3 );
did not seem to call it.

Should it be called later?

One of the alternative possibilities I have is to let the islands be
directly converted to a macro-call right after they got edited. This is
better for a predictable wysiwyg effect. However how could I let the
macro-islands be edited using the wiris plugin instead of the default
macro-editor when they are double clicked??

> You could also write a
> https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-server/src/main/java/org/xwiki/wysiwyg/server/internal/cleaner/HTMLFilter.java
> that is called on the server side before the HTML is converted to wiki
> syntax.
I fear this is not pluggeable.

thanks

paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Crafting method to add a plugin to the CKEditor?

[Paul Libbrecht]

Cool, thanks Marius,

I was able to add something that adds a button to the CKEditor by using
approximately the following snippet:

require(['jquery'], function($) {$(document).ready(function() {
if(XWiki.contextaction=='edit') {
require(['deferred!ckeditor'], function(ckeditorPromise) {
  ckeditorPromise.done(function(ckeditor) {
ckeditor.on('instanceCreated', function(event) {
  event.editor.once('configLoaded', function(event) {
ckeditor.tools.extend(event.editor.config, {
  plugins: 'ckeditor_wiris',
}, true);
  });
  ckeditor.plugins.addExternal('ckeditor_wiris', 
'/wiriseditorapp/ckeditor_wiris/plugin.js');
});
  });
});
}})});

within CKEditor.EditSheet2 which loads everywhere (I hope syntax-colored
html doesn't bother people's reading, it's a present of IntelliJ IDEA).
I am sure there are less verbose ways to do it!
One thing, however, where this is incomplete is that this only evaluates
if XWiki.contextaction=='edit' instead of checking for something more
realistic such as the availability of one or several CKeditors. It
doesn't trigger errors so it's not too bad (it is because of the
promise?). With comments on optimization, I think we should start a
snippet page or something such.

Now, the content that is created with this plugin (MathML elements) is
being killed by the rendering framework.
I guess I can either:
- let it be wrapped as a macro
- adjust the rendering framework to respect that bit
I think the second is impossible though. Or?

thanks

Paul
>> is there some hint to add a plugin (with a button) to the CKEditor?
> Yes, but you can also do it without touching CKEditor.EditSheet (if
> you want to write an extension for instance). See
> http://jira.xwiki.org/browse/CKEDITOR-46?focusedCommentId=90672=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-90672
> .
>> I tried adding the extraConfigs variable within the configuration but it
>> seems like this cannot load my plugin.
> I don't know what you mean by "extraConfigs" but you can checkout
> https://github.com/xwiki-contrib/application-ckeditor/blob/application-ckeditor-1.0/ui/src/main/resources/CKEditor/EditSheet.xml#L154
> to see how to use an external plugin (in the first version of the CKEditor
> integration the Source plugin was defined in a wiki page as a proof of
> concept).
>
> It would be cool to have an extension mechanism for that.
>
> See http://jira.xwiki.org/browse/CKEDITOR-16 .
I voted.

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] Crafting method to add a plugin to the CKEditor?

[Paul Libbrecht]

Hello fellow developers,

is there some hint to add a plugin (with a button) to the CKEditor?

I've met /xwiki/bin/edit/CKEditor/EditSheet?editor=object which is 
probably the place to start with.
I tried adding the extraConfigs variable within the configuration but it 
seems like this cannot load my plugin.


It would be cool to have an extension mechanism for that.

thanks in advance.

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Saving page name with accented character?

[Paul Libbrecht]

Julio,

the two are equivalent as per the URL spec, I believe.

paul   

> Julio Brum 
> 24 June 2016 at 00:38
> I am using the XWiki version 7.4.1 with UTF-8 in Xwiki, tomcat8 and
> Postgres, but every time than I save a page with accent in the name, XWiki
> change the name. For example, I try to save a page with the name "é" and
> XWiki save "%25C3%25A9" Please, why this happens?
>
>
>
> *My settings in windows:*
>
> *tomcat\conf\server.xml:*
>
>  URIEncoding="UTF-8"
>
> *xwiki.cfg:*
>
> xwiki.encoding=UTF-8
>
> *PostgreSQL:*
>
> CREATE DATABASE wiki
> WITH OWNER = postgres
> ENCODING = 'UTF8'
> TABLESPACE = pg_default
> LC_COLLATE = 'Portuguese_Brazil.1252'
> LC_CTYPE = 'Portuguese_Brazil.1252'
> CONNECTION LIMIT = -1;
>
> Thanks,
> Julio
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Question about User Query with Solr

[Paul Libbrecht]

Fitz Lee wrote:
> It's clear to me now. I can use the HQL query to fast get the users for my
> android app :)
Beware of HQL, it translates to SQL pretty easily but then... there are
easy situations where you create too big queries which can hog big
platforms (as any write will be locked while the query is still being
executed).

paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Question about User Query with Solr

[Paul Libbrecht]

I only see joins here, so... HQL or XWQL or something such.
They're not really there in SOLR (it's coming in some later versions
apparently).

paul

> Fitz Lee <mailto:leef...@gmail.com>
> 14 June 2016 at 16:23
> Thanks for your reply.
>
> On Tue, Jun 14, 2016 at 9:38 PM, Paul Libbrecht <p...@hoplahup.net> wrote:
>
>> Are you not after solr's? Something such as
>> [NOW-1MONTH TO *] ?
>>
>
> Yeah, I know. But I want to find the users which should be within a certain
> group like XWikiAdminGroup and should be last modified after the date
> like [2016-01-14T15:44:02Z
> TO *].If finding all the users in the xwiki (not care about the group),
> I can use the date range queries, just like "wiki:xwiki and
> object:XWiki.XWikiUsers and date:[2016-01-14T15:44:02Z TO *]".
> http://www.xwiki.org/xwiki/rest/wikis/query?q=wiki:xwiki%20and%20object:XWiki.XWikiUsers%20and%20date:[2016-02-02T15:44:02Z%20%20TO%20*]=1
>
>
> Are there any other ideas ?
>
>
>
>> paul
>>
>>
>> fitz wrote:
>>> But I don't know how to query fast the group's users(last modified after
>> the
>>> date).  Could some one help me?
>> ___
>> devs mailing list
>> devs@xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> Paul Libbrecht <mailto:p...@hoplahup.net>
> 14 June 2016 at 15:38
> Are you not after solr's date range queries? Something such as
> [NOW-1MONTH TO *] ?
>
> paul
>
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> fitz <mailto:leef...@gmail.com>
> 14 June 2016 at 14:56
> Hi devs,
>
> Is there a better way with solr query to fast get all the users (last
> modified after the date "2016-01-14T15:44:02Z") of the group
> XWikiAdminGroup
> ?
> For this group,
> http://www.xwiki.org/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/XWikiAdminGroup
>
>
> now I just query with the following method, it's too slow.
>
> 1. get all user ids from the group
> http://www.xwiki.org/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/XWikiAdminGroup/objects/XWiki.XWikiGroups
> 
> 
> XWiki.LudovicDubost -> (id = XWiki.LudovicDubost)
> 
> ...
> ...
> 
>
> 2. one by one check the user's modified time, if after the date, then add
> the id "XWiki.LudovicDubost" to the array list.
> For example:
> http://www.xwiki.org/xwiki/rest/wikis/xwiki/spaces/XWiki/pages/LudovicDubost
> 2014-07-28T03:04:44+02:00
> but it takes up lots of time for checking the modified date one by one.
>
> 3. from the list above getting from the step2, we just get all the
> ids, but
> no detail information, we also should request server again to get the
> user's
> detail properties one by one! it also costs much time.
>
> If the group has 1000 users, step1 needs 1 times http request, step3 needs
> 1000 times http requests, step3 needs <=1000 times, all steps need
> 1001-2001
> times requests and xml parse. Maybe the step2 is not necessary so that we
> can reduce half of the time.
>
> Therefore, is there a better way to query the last modified users?
>
>
> By the way, now I query all the users modified after the date
> "2016-01-14T15:44:02Z" in the wikis/xwiki. like this:
>
> wiki:xwiki and object:XWiki.XWikiUsers and date:[2016-01-14T15:44:02Z
> TO *]
> & number=1
> Query Example:
> http://www.xwiki.org/xwiki/rest/wikis/query?q=wiki:xwiki%20and%20object:XWiki.XWikiUsers%20and%20date:[2016-02-02T15:44:02Z%20%20TO%20*]=1
> <http://www.xwiki.org/xwiki/rest/wikis/query?q=wiki:xwiki%20and%20object:XWiki.XWikiUsers%20and%20date:[2016-02-02T15:44:02Z%20%20TO%20*]=1>
>
>
> But I don't know how to query fast the group's users(last modified
> after the
> date). Could some one help me?
>
>
> Thanks,
> Fitz
>
>
>
> --
> View this message in context:
> http://xwiki.475771.n2.nabble.com/Question-about-User-Query-with-Solr-tp7599964.html
> Sent from the XWiki- Dev mailing list archive at Nabble.com.
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Question about User Query with Solr

[Paul Libbrecht]

Are you not after solr's date range queries? Something such as
[NOW-1MONTH TO *] ?

paul
   

fitz wrote:
> But I don't know how to query fast the group's users(last modified after the
> date).  Could some one help me? 

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] HTML

[Paul Libbrecht]

Vincent Massol wrote:
>> as long as there is no possibility to "see through" that an extension is
>> > probably installed on my wiki, the problem will remain.
>
> WDYM by “see through”? If you go to the admin you see installed extensions 
> already.
Probably five clicks thus far
>
>> > At least as long as there's a single flavour out there, the "default"
>> > nature of an extension being installed needs to be made more visible I
>> > feel. This I can open as an issue if you wish but I think we are missing
>> > a way to display this.
>
> I don’t understand your point with the “default” flavor. Showing bundled 
> extensions  surely becomes even more important as the number of flavors 
> increase.
Does it? Isn't the default xwiki-entreprise still the most common one?
How would you take in account the other flavours then? By listing them?
> Re “visibility", I’ve already suggested an idea in my reply.
Yes, indeed, listing the flavours.
I've opend this one:
http://jira.xwiki.org/browse/XWIKI-13430 not all extensions should
be perceived as installable
But I feel that something more could be done. Maybe a way to check if an
extension is installed in one's wiki (input your wiki name there and
keep it in a cookie, click a link or even produce an iframe)
What do others feel?

Also, the fact that it's called "extensions.xwiki.org" remains a hint
towards a wiki to be extended.

Marius Dumitru Florea wrote:
> And if you try to search for it using Administration > Add Extensions
> you'll see that it's already installed.
Does this not sound like... I'll add an extension I would like to
manage extensions.


Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] HTML

[Paul Libbrecht]

Vincent,

as long as there is no possibility to "see through" that an extension is
probably installed on my wiki, the problem will remain.
At least as long as there's a single flavour out there, the "default"
nature of an extension being installed needs to be made more visible I
feel. This I can open as an issue if you wish but I think we are missing
a way to display this.

Paul



Vincent Massol wrote:
>> Would it make sense to have a "macros.xwiki.org" or "bundled.xwiki.org"
>> > or "included.xwiki.org" (or xcs.xwiki.org) ?
>> > It would be just a copy, vhost or proxy but would fold away the
>> > installation information; search there would default to bundled ones.
>
> 
> No, that’s way too complex IMO, and raises so many other questions 
> (installation.xwiki.org, howdoieditapage.xwiki.org, 
> howtolickwithmymouse.xwiki.org) not mentioning the one of knowing that this 
> subwiki exists… maybe a findwhichsubwikiexist.xwiki.org? :)
> 

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] HTML

[Paul Libbrecht]

Marius Dumitru Florea wrote:
> There's an information pane on the right saying:
> "Bundled With: XWiki Enterprise, XWiki Enterprise Manager"
Obviously I missed it.
It's also smaller than the installation instructions... So that these
take precedence and let you believe it needs to be installed.
> And if you try to search for it using Administration > Add Extensions
> you'll see that it's already installed.
> What improvement do you have in mind?
My reaction came while reading the URL actually.

Would it make sense to have a "macros.xwiki.org" or "bundled.xwiki.org"
or "included.xwiki.org" (or xcs.xwiki.org) ?
It would be just a copy, vhost or proxy but would fold away the
installation information; search there would default to bundled ones.

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] [Proposal] Comparing XWiki to MediaWiki and Confluence on xwiki.org

[Paul Libbrecht]

Any way to make it look better?
Why are the features with a name before in each column?
Also, the "Source: Wikimatrix" statement is not clearly attached to the
section above it or below it.

If there are extra softwares to aim at, would it make sense to add
SharePoint, Office365 and Google Apps?

Paul
>
> It would be great to know if you agree with the listed content and if you
> find other similarities or distinctions between the above solutions.
>

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Turn on filesystem attachment store by default in XWiki 8.1

[Paul Libbrecht]

My big big +1 !
Paul

> Vincent Massol 
> 24 March 2016 at 11:35
> Hi devs,
>
> It’s been a very long time that Caleb has implemented fileystem
> storage and we still see people regularly stuggling to attach largish
> attachments to their wiki. I think it’s time that we make it the
> default even if the implementation is still not perfect.
>
> Namely here are the opened issue related to filesystem store:
> https://jira.xwiki.org/issues/?jql=component%20%3D%20%22Storage%20-%20File%20System%20Attachment%22%20AND%20project%20%3D%20XWIKI%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
>
> Tha main 2 issues are:
> - XWiki.DeletedAttachments shows nothing when filesystem attachments
> are enabled.
> - FS Attachments does not delete files when a subwiki has been removed
>
> I’m proposing for the moment to add a warning to the deleted
> attachments tab on AllDocs when fs attachment is on.
>
> I think the pros outbalances the cons. WDYT?
>
> Here’s my +1
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Idea] LESS compilation speed up idea with checksum

[Paul Libbrecht]

Guillaume Delhumeau wrote:
> Note also that a LESS resource can contains Velocity code, so some parts
> can be dynamic (ex: a color which depends on the wiki id).
I've met this claim on a steady basis since quite some time, e.g. using
the /skin/ URLs, and dare say that this is ruining normal caching based
optimization (e.g. on Apache or CloudFront).

If there's something dynamic in the CSS or JS it should really be
requested separately from the mass (and probably not need LESS).

paul

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Move all pages specific to xwiki.org customisations in a XWikiOrg space

[Paul Libbrecht]

This would be interesting, definitely.
My +1.

paul

PS: Who's taking charge of it?
> Marius Dumitru Florea 
> 11 March 2016 at 10:18
> +1
>
> Thanks,
> Marius
>
> On Thu, Mar 10, 2016 at 7:39 PM, vinc...@massol.net 
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> vinc...@massol.net 
> 10 March 2016 at 18:39
> Hi devs,
>
> I’d like that we agree on a rule, which is to put all our xwiki.org
> customizations inside a XWikiOrg space (for the main wiki and all
> subwikis). I’m not talking about apps but about pages to customize the
> UI such as skin, color themes, panels, UIX, etc.
>
> I need to create some UIX for the quick search on subwikis so I’m
> going to start this now.
>
> Let me know what you think.
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Should we move to XML 1.1 in XAR ?

[Paul Libbrecht]

export the character "0x1" ???
This seems like a character for the old 7-bit-modem-based terminals.

I believe this one should just be prohibited at the entrance level.
I do not know of any valid meaning for this character.
Do you have such?

Paul


> Thomas Mortagne 
> 22 February 2016 at 12:06
> As recommended by W3C we are manipulating XML 1.0 in XAR format but
> what I did not know is that XML 1.0 does not support all possible
> characters (I tough at worst it would simply be encoded as a UTF8
> entity but seems not) and we just got a report of Woodstox failing
> because of some character it cannot write in XML 1.0 (""Invalid white
> space character (0x1) in text to output (in xml 1.1, could output as a
> character entity)").
>
> So I'm wondering if we should move to XML 1.1. It's critical IMO that
> we are able to export anything that can be stored in XWikiDocument and
> in the database and it's the case here.
>
> In theory this is most probably a breakage for people using a XML 1.0
> parser but not sure how breaking it is in practice.
>
> WDYT ?
>
> I'm +1 for this but I won't apply it until I get more point of view
> (ideally from people having more experience that me on XML 1.0 vs
> 1.1).
>

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [GSoC] [Poll] Should XWiki apply to GSoC 2016?

[Paul Libbrecht]

Eduard Moraru wrote:
> So please let me know ASAP, since the deadline for the org application is
> in 10 days (19th of February) and we would need to move quickly.
count me in.

paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [VOTE] Move to Java 8 as minimal version for XWiki 8.0+

[Paul Libbrecht]

Vincent,

can you state which minimum MacOSX, Ubuntu, and Windows version this means?
I know 10.6 is out and I've been challenged for this since XWiki moved
to Java7 already but that's past (my solution was, then, to not upgrade
my wiki).
It'd be interesting to know the coming limitations.
paul

> vinc...@massol.net 
> 9 February 2016 at 16:11
> Hi devs,
>
> I’d like to propose that we move to Java 8 as the minimal Java version
> supported for XWiki 8.0+.
>
> The rationale is:
>
> * Java 7 is end of life since April 2015.
> * It brings [Default
> Methods|https://docs.oracle.com/javase/tutorial/java/IandI/defaultmethods.html]
> which would make retro compatibility a lot easier for us (it's very
> hard to add new features to existing API right now).
> * Required for:
> ** Infinispan 8
> ** JGroups 4
> ** Jetty 9.3+ seems to require Java 8 (or maybe it's just optimized
> for it, http://download.eclipse.org/jetty/ is not crystal clear about
> what "Java 8+" means exactly)
>
> Nice to have
> * Lambda Expressions
> * Repeating Annotations which would probably allow us to use several
> times \@Named instead of \@Component(hints=\{"hint1", "hint2"\}) for
> example
> * New date/time APIs (pretty much what is in Joda Time). We should
> refactor our $datetool velocity tool to make the java.time api
> available from velocity
> * more…
>
> See http://jira.xwiki.org/browse/XCOMMONS-878
>
> Here’s my +1 and my +1 to start requiring Java 8 for 8.0M2.
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [xwiki-users] [VOTE] Move to Java 8 as minimal version for XWiki 8.0+

[Paul Libbrecht]

vinc...@massol.net wrote:
>> Just found this: http://java.com/en/download/help/sysreq.xml
>
> This is for Oracle’s JVM but all you need is to find a Java 8 JVM that works 
> for your OS. I don’t know the requirements for OpenJDK or other JVMs.
cool. Sounds rather acceptable to me.
+1.
(non-binding I think)

paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

[Paul Libbrecht]

Vincent,

is there not a need to version the legacy?
I know of no installation that does not have the legacy jars and I
wonder if this could not be better controlled so that installers can
actively get rid of the legacy.

paul

> vinc...@massol.net 
> 18 January 2016 at 11:03
> Hi devs,
>
> After a lot of thinking and experimentation (see the thread’s
> details), I have found that this first proposal is not a good idea.
> I’m thus proposing to replace it with the following best practice:
>
> * Let our script services generate exceptions
> * If the velocity scripts with to handle the exceptions, then they
> should use the #try() directive. If they don’t want to, they don’t
> have to do anything since the MacroTransformation or the template
> (contentvars.vm for example) will catch it and display it to the user.
>
> More precisely I’m proposing that:
>
> * Existing Script APIs in Java should not be modified as that would
> break backward compatibility. New signatures can be added and old one
> deprecated and moved to the legacy modules. After new signatures have
> been introduced, existing velocity scripts can be updated to use the
> new signatures and to use the #try directive if needed.
> * New Script APIs must use the new best practices (if agreed :)), i.e.
> throw Exceptions, and new velocity scripts must use the #try()
> directive if they need to handle exceptions.
>
> WDYT?
>
> Thanks
> -Vincent
>
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> vinc...@massol.net 
> 14 January 2016 at 17:51
> Hi devs,
>
> Right now our strategy is for script services and script APIs in
> general to catch exceptions, store them and offer a getLastError()
> method to get them (see
> http://extensions.xwiki.org/xwiki/bin/view/Extension/Script+Module#HBestPractices)
>
> However it would be much nicer to:
> * Let our script services generate exceptions
> * Offer a velocity script service to get the last exception raised by
> a java call from velocity
> * Implement this uberspector to catch the exceptions and to set them
> in the execution context
>
> That should be quite easy to implement IMO.
>
> WDYT?
>
> Thanks
> -Vincent
>
> PS: This is http://jira.xwiki.org/browse/XWIKI-2374
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] Versioning Legacy (was Re: [Proposal] Change our Script API best practice regarding exception handling (Take 2))

[Paul Libbrecht]

vinc...@massol.net wrote:
>> wonder if this could not be better controlled so that installers can
>> > actively get rid of the legacy.
>
> Our current strategy has been to keep legacy forever, see:
> http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackwardCompatibility
>
> Our idea was to start not bundling legacy jars by default but we need the EM 
> to support legacy jars first as otherwise users will see breakages when they 
> install extensions requiring legacy APIs.
>
> Do you have a different idea?
Yes, I meant that legacy jars should give the feeling that one should
get rid of them.
Marking them with "legacy of version 5.3" (which would mean something
such as "abandadonned at 5.3" would let the installers be aware that the
software they run still needs legacy that is maybe 2 years old.

paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Idea] Make Markdown syntax available as an optional subset of the XWiki 2.1 syntax

[Paul Libbrecht]

Hello all,

Caleb thus wrote:
> I would say generally speaking the longer we wait to align our syntax
> with markdown the more non-standard and irrelvant our syntax will become.
This is pretty harsh. Do you know if others are doing such a slow
convergence?
I think Markdown is great for elementary tasks such as a readme but I've
seen it fail for bigger (and long term) things.
> If we were building XWiki from scratch today, we would be royal fools not
> to adhere to what is essentially a universal standard for syntax.
Erm... provided it would do all we wish it to do.

E.g. I've never seen "macros" in markdown be put to use in widespread
infrastructures whereas many wiki syntaxes have some (GitHub has none as
far as I can tell).

Addressing that point might answer Guillaume's original intent, which
seems to answer a fairly precise desire. In particular, I'd be quite
fine if we enriched our MarkDown processor with some forms of macros but
nothing more of the xwiki syntax.

I've always seen markdown as "when it's simple I use it" otherwise, just
don't bother and use html.
Guillaume, should that be broken? I'd understand yes, but please confirm.
Also, how would you have recognition? E.g. how should the table syntax
be recognized?

paul

> But even though we're not building it today, many people are trying it
> today and for someone who doesn't know or care about the bad old days
> before markup was standardized, we're just another incompatible format
> with no significant market share.
>
> Same story is true for Bootstrap. 5 years ago there was no coherent
> standard, now there is.
>
> tl;dr it sucks but we have to.
>
> Thanks,
> Caleb
>
>
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> Guillaume Lerouge 
> 25 novembre 2015 09:05
> Hi Devs,
>
> as you probably noticed it, Markdown has recently become somewhat of a
> reference syntax for many developer tools, most notably GitHub. I have
> recently discussed with teams using XWiki who are also using GitHub and
> Slack and who are interested in being able to use Markdown syntax inside
> XWiki.
>
> Although it is already possible to use Markdown syntax in XWiki in a
> limited way , I
> don't think that a wiki could really work with only Markdown, due to the
> following limitations:
>
> 1. We have invested a lot in the XWiki rendering and the XWiki 2.1
> syntax in order to make them address a lot of use cases and work
> seamlessly
> with the WYSIWYG editor
> 2. Conversely, Markdown syntax is very limited by design
>  and does not
> support many of the important features of XWiki syntax, forcing users to
> rely on HTML for a lot of use cases
>
> What's interesting however is that Markdown syntax is very close to XWiki
> syntax in a number of regards, notably line breaks, bold and lists. Some
> notable differences include the syntax for links, images and code blocks.
>
> My line of thinking is the following: what if we made it possible as an
> option for users of XWiki 2.1 syntax to have XWiki interpret the main
> elements of Markdown syntax? In practice, this would mean adding a set of
> 5-10 additional rules to the rendering engine.
>
> The obvious benefit would be to improve adoption of XWiki by dev teams who
> are already familiar with Markdown. I don't see any obvious drawbacks
> (besides the need to code and maintain the feature of course), but I
> clearly don't master all the subtleties of the XWiki rendering engine.
>
> Thanks,
>
> Guillaume
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Idea] Make Markdown syntax available as an optional subset of the XWiki 2.1 syntax

[Paul Libbrecht]

Cool.

Would it be possible to join the fashion claim by adding compatibility
statements?
E.g., does that make it compatible with some markdown variant? Is
GitHub's MarkDown somewhere close?

paul

vinc...@massol.net wrote:
> > Addressing that point might answer Guillaume's original intent, which
> > seems to answer a fairly precise desire. In particular, I'd be quite
> > fine if we enriched our MarkDown processor with some forms of macros but
> > nothing more of the xwiki syntax.
>
> See http://rendering.xwiki.org/xwiki/bin/view/Main/Markdown11 :)
>

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Idea] Rewrite Activity Stream + Stats using Elastic Search

[Paul Libbrecht]

Hello Vincent,

While I strongly believe that a NoSQL-type of storage is a fundamentally
good idea to store activity streams, I believe you may be attracted by
applying ElasticSearch mostly on a superficial basis compared to Solr.

Most analytics systems base indeed on noSQL storages, ElasticSearch and
Solr are examples of such. Many bigger systems are used in other
analytics solutions such as CouchDB and MongoDB. Almost all will
optimize for the chosen views.

My impression is that many persons are excited by ElasticSearch because
it has fancy UIs, whereas Solr may be more optimized for its very
effective caching. In both cases, the creation of an analytics system
will involve designing a storage that architects for making effective
the queries that are expected by the views of the analytics system, e.g.
the row of page-view-counts along recent times. I would expect a Solr or
ElasticSearch based Stats module to have few differences.

One thing that is crucial when using a stats system (and, I believe,
even if trying to adjust the SQL-stored-activity-stream by doing less
writes) is that viewers should not expect a perfect real time updated
view. ElasticSearch and Solr have the same behaviour: real time is only
"near real time". Alternatively, the real-time aspect (as done by Google
analytics for example) should be a completely separated view which
probably bases on in-memory values.

paul

PS: did you consider using hsqlDB for a part of this?
  This is in memory and locks are certainly way less hurting.
Persistence should be somewhat decoupled...

PPS: schema evolution is never painless, even in a noSQL system. If a
field needs to be merged or split, there is a price to it, whatever the
storage system.


> vinc...@massol.net 
> 21 novembre 2015 12:01
> Hi devs,
>
> I think that for data that are both not critical and high volume we
> should use ElasticSearch instead of saving them in our RDBMS.
>
> So the idea would be to have an embedded ES in XWiki by default (using
> the permanent directory to store its data) and admins could configure
> XWiki to use a separate ES instance (very similar to what we do with
> SOLR).
>
> Whenever a user modifies/creates/deletes/does operations on
> XObjects/etc, this is sent to ES.
>
> The AS UI queries ES to display the data.
>
> The Stats UI does the same.
>
> Pros:
> - scalability
> - performance
> - extensibility. It’s easy to evolve the schema in ES, and we can
> easily have several formats (as was proven by the Active Installs code)
>
> I’d like to start a POC in my “free” time.
>
> WDYT?
>
> Thanks
> -Vincent
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Idea] Page Administration

[Paul Libbrecht]

Is the problem of understanding inheritance of rights not a problem of
displaying this to the user?
The rights UI has always gotten me suspicious with the back-brain
telling me "careful, there might be something above telling xwiki
something else than the rights you are editing". Should this be solved
by displaying the inherited rights when editing the rights of a page
(but not allowing to edit them).

I guess this is complementary to an inheritance check-box.

Paul

> Guillaume "Louis-Marie" Delhumeau 
> 12 novembre 2015 11:34
> Hello, and thanks Edy for your detailed answer.
>
> I'm OK with the idea to put the preferences (XWiki.XWikiPreferences) in the
> page itself, just as we do for rights.
>
> However, I'm not sure that adding a switch "administrate this page /
> administrate this page and its children" is a user-friendly solution. I
> will quote Vincent, who has written a comment on the JIRA issue recently:
>
> Related to this, we also need to merge "Rights" and "Page Rights" under a
>> single "Rights" UI screen with a checkbox to decide whether children are
>> affected or not. This would avoid users picking the wrong UI *(just saw
>> it happening in front of my eyes ).*
>>
>
> It shows that users are already confused with the Rights UI, currently
> split like you propose.
>
> I really think that, even if it's more complicated to implement (in
> particular at the end of this cycle), it's more intuitive for the users to
> have a checkbox-based solution.
>
> Do everybody think like Edy? What do you think?
>
> Thanks,
>
> Guillaume
>
>
> 2015-11-05 16:09 GMT+01:00 Eduard Moraru :
>
>> Hi,
>>
>> Here's my input on this...
>>
>> TL;DR: Don`t rewrite anything and don`t put "affect children" checkboxes
>> under each option. Simply use a select to redirect from page admin (/admin/
>> action and XWiki.AdminSheet on the current page) to space admin
>> (XWiki.AdminSheet on the WebPreferences page, like it is now) and yes,
>> store the preferences object in the page, like we do with rights as well.
>> ATM, "edit" right is king in XWiki and I don`t think we are planning to
>> change that very soon.
>>
>> Longer version:
>>
>> I am not sure what your aim is with this. My initial idea over this was
>> that:
>>
>> 1) we would have a link/action in view mode that takes you to "Page
>> Administration" (does not matter if it's a terminal or non-terminal
>> document)
>>
>> 2) the user would be taken to the admin mode of the current page (i.e.
>> /admin/Space/Page)
>>
>> 3) to access that mode, for page administration (WebHome or terminal
>> document, so != WebPreferences), the user would need only "edit" rights
>> (also due to our rights system's implementation of rights storage in wiki
>> pages)
>>
>> 4) once there, the user sees the regular space administration sheet
>> (XWiki.AdminSheet), but applied to the current page (!= WebPreferences).
>> Thinking about it, I guess all the preferences for a space (at least the
>> ones we have now), could be made available for individual pages as well. We
>> could probably filter the sections displayed for the administration of a
>> page (again, != WebPreferences), either statically, in the code, or
>> dynamically, through some extension points... but we could leave that
>> discussion for later (what we want to add/remove, if we want to do that,
>> etc.). This means that yes, any configuration object
>> (XWiki.XWikiPreferences or other) is stored in the actual page, just like
>> we do for rights objects, document binding sheet objects, etc.
>>
>> 5) above the vertical sections menu, on the left, of the administration UI
>> [1], we would have a select-like input showing the user that he is
>> currently on the Page Administration of document X (again, !=
>> WebPreferences) and where he can switch to go to the Page Administration of
>> document X and its children (i.e. space administration, i.e.
>> SpaceOfX.WebPreferences). Of course, if X is a terminal document (i.e. !=
>> WebHome), we either don`t show this select at all, or instead of a select
>> we show a label informing the user that he is in the page administration of
>> document X (but not showing options) OR, the lazier solution is to still
>> show a select, but with only the 1 option (i.e. no option to administer
>> page + children, since it's a terminal document). Yet another idea here for
>> terminal documents would be to offer the 2nd option as administering the
>> *parent* document and its children.
>>
>> 6) using the select-like control to switch to the page + children option
>> would redirect to /admin/SpaceOfX/WebPreferences and from there we can
>> switch back to page only and come back to /admin/SpaceOfX/WebHome. This
>> switching back and forwards could be managed based on convention, but for
>> terminal documents, if we go with the "parent + children" option
>> (previously mentioned at point 5.), we would probably need a request
>> parameter to be able to go 

Re: [xwiki-devs] License for wiki pages?

[Paul Libbrecht]

Thomas Mortagne wrote:
> You can always put this kind of message in some public wiki you run
> but having this message by default for anyone that use XWiki does not
> make any sense. It's not out job to decide what license will be used
> for user content.
This message is not imposed on anyone to keep.
That you want to make it easier switch-offable, I sure respect though.

I know that almost all wiki-administrators delay the question of
choosing a license till very very long after the wiki has been started.
Choosing a default license in the case of content repositories is an
excellent way to make them think of it.

I know a zillion of fellow mathematicians which love putting things on
the web, basically implying that it is widely available, but never do a
decision on the license, just because they do not have the rights
competence to decide on that (or the time to acquire it). A few years
ago, I even had a very prolific author to whom we asked the license of
his set of GeoGebra constructions and he answered "I don't know, doesn't
the GPL of GeoGebra mean my files are under GPL?".

Such a misunderstanding is well avoided by this footer. It sets the stage.

Paul


___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] License for wiki pages?

[Paul Libbrecht]

I disagree, this clause is one of the best encouragements to produce
open-content material and this should be imperatively kept.

I would suggest to dual license the pieces of code which could be
"understood" as content (such as changeable translations). I do not
think dual licensing is an issue with existing code or?

Paul

> Thomas Mortagne 
> 10 novembre 2015 13:44
> Yes I think we should just forget about any other license than LGPL.
> Everything XWiki Dev Team produce should be LGPL whatever it is which
> is exactly what we do right now in practice from sources and Maven
> point of view. We just need to completely remove all reference to
> CC-BY (and completely get rid of this absurd runtime message in XE
> preferences).
>
>
>
> vinc...@massol.net 
> 10 novembre 2015 12:57
> This seems overly complex to me to say that portions of wiki pages
> that are content is CC-BY and the portions that are scripts are under
> LGPL. Also I don’t think it helps at all to people who want to make
> distributions (since if they copy existing wiki pages it’s almost sure
> they’ll copy scripts and thus LGPL code).
>
> IMO either we say that wiki pages + VMs are fully CC-BY or we say they
> are LGPL and live with the consequences (i.e. modifications +
> redistribution have to be under LGPL or compatible license). If you
> distribution your own content then the license is the one you wish for
> your content and untouched existing content is under LGPL.
>
> Thanks
> -Vincent
>
> On 10 Nov 2015 at 12:17:36, Eduard Moraru (enygma2...@gmail.com) wrote:
>
> +1 for LGPL on code as well. 90+% of the standard XAR contains raw
> code, as
> Marius and Thomas already mentioned.
>
> IMO, the CC license string in the header could be modified from "This wiki
> is licensed under a Creative Commons 2.0
>  license" to something like
> "This wiki's content is licensed under a Creative Commons 2.0
>  license"... i.e. to
> emphasize
> that it is a statement for the runtime; for content pages that are created
> by the users and that there are other pages that contain code and that are
> part of the XWiki product itself (which has its own LGPL license).
>
> IMO, we can not simply say that wiki pages have license X, because a wiki
> page is just a container (just like a file in a filesystem). What you
> choose to put in that page (i.e. file) determines what type of license you
> apply to it.
>
> On this note, do you think we would be interested in adding a new
> "license"
> field to a wiki page's model? This would also allow us to set the license
> of our standard XAR code pages in that field, since right now, any license
> header we have in our XML pages on git gets lost at runtime, since XML
> comments are not imported into the wiki in any way... so our licensing
> information is lost at runtime.
>
> Conclusion: Code is LGPL, content is CC, regardless of where it is
> physically located or packaged.
>
> Thanks,
> Eduard
>
> On Tue, Nov 10, 2015 at 12:12 PM, Marius Dumitru Florea <
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
> Eduard Moraru 
> 10 novembre 2015 12:17
> +1 for LGPL on code as well. 90+% of the standard XAR contains raw
> code, as
> Marius and Thomas already mentioned.
>
> IMO, the CC license string in the header could be modified from "This wiki
> is licensed under a Creative Commons 2.0
>  license" to something like
> "This wiki's content is licensed under a Creative Commons 2.0
>  license"... i.e. to
> emphasize
> that it is a statement for the runtime; for content pages that are created
> by the users and that there are other pages that contain code and that are
> part of the XWiki product itself (which has its own LGPL license).
>
> IMO, we can not simply say that wiki pages have license X, because a wiki
> page is just a container (just like a file in a filesystem). What you
> choose to put in that page (i.e. file) determines what type of license you
> apply to it.
>
> On this note, do you think we would be interested in adding a new
> "license"
> field to a wiki page's model? This would also allow us to set the license
> of our standard XAR code pages in that field, since right now, any license
> header we have in our XML pages on git gets lost at runtime, since XML
> comments are not imported into the wiki in any way... so our licensing
> information is lost at runtime.
>
> Conclusion: Code is LGPL, content is CC, regardless of where it is
> physically located or packaged.
>
> Thanks,
> Eduard
>
> On Tue, Nov 10, 2015 at 12:12 PM, Marius 

Re: [xwiki-devs] [ActiveInstalls][Brainstorming] Sending the number of users/wikis in the ping: a problem?

[Paul Libbrecht]

For what it's worth, several of the public xwikis I hosted have huge
spam issues and the number of users will be fed by that... Sometimes I
have rages and manage to fight against them, but for the platforms it
went over 500, I abandoned
Maybe counting the number of users who have create more than pages is a
lot more expressive?

I do not find it very convincing to state that access stats cost an
amount because they need to be written to the DB. Such analytics should
have a way to be streamlined into memory and only written to disk once
in a while (even... once every five minutes). Of course, this means
there may be some stats loss, but that is ok, crashes are not to be
entirely cared for.

Paul



> vinc...@massol.net 
> 9 novembre 2015 11:56
> Thanks for your feedbacks!
>
> If you check how all enterprise software out there do pricing, it’s
> almost always per user. So IMO counting users is a good approximation
> of the size of an xwiki instance (you don’t create users for nothing
> in general). It’s an easy figure to get (I can probably implement it
> in 1 hour), while counting activity is much more complex to do. Also
> note that it’s possible to regularly clean the AS and if you have a
> very large wiki you’ll probably want to do this regularly.
>
> Counting page views is also difficult from inside XWiki since you’d
> need to introduce a new table in the DB for it but more importantly
> it’s going to affect your performances when you save that number.
>
> I agree that number of documents could be interesting too but XE by
> default comes with over 700 and when users install extensions more are
> added without it being a good indicator of usage of the wiki. Still I
> think it’s interesting.
>
> So what I’m proposing to do right now is sending:
> * number of wikis
> * number of users
> * number of documents
> * number of AS events (count on the table)
>
> I’m not saying it’s enough but let’s talk incremental and we can
> always add new metrics later on as we learn how to get them.
>
> So WDYT about adding those for now? Do you see any privacy issues?
>
> Thanks
> -Vincent
>
> On 9 Nov 2015 at 11:29:17, Guillaume Louis-Marie Delhumeau
> (gdelhum...@xwiki.com) wrote:
>
> Why not the amount of Activity Stream events during the last month? It's
> still very anonymous (since we don't know what exactly are these events)
> and relevant.
>
> + the amount of pages view during the last month (a wiki could have a lot
> of pages view meanwhile it is not edited often)
>
> I think these 2 metrics could be good indicators.
>
> Thanks,
>
> Guillaume
>
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] ShortURLs on 7.2?

[Paul Libbrecht]

Hello XWiki community,

I moved to shortURLs. The tutorial has been nicely effective.
The home page serves well, the entry page of my wiki and my space all
work well.

However, almost all the pages that are there now break at view (with or
without the action /bin/view/ in the URL). Similarly, /download/ breaks
with 404. These are mostly pages in confluence syntax but moving them to
xwiki syntax doesn't change anything.  They display: 
   A problem occurred while trying to process your request.
   Please contact the webmaster if this happens again.
Their link is obtained in the index or tree views.
These pages work fine at /edit/, save, and /preview/.

With some debugging I seem to reach the error that:
"No row with the given identifier exists"
(at XWikiHibernateStore.loadXWikiDoc).

Could it be that the ReferenceSerializer is behaving differently with
ShortURLs? That seems bad.
Why would it be different in /edit/ action?
Is it changed on 7.3 candidates?

thanks in advance.

Paul



___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Removing comments, attachments, etc. tabs (#docextra) in default applications WebHome

[Paul Libbrecht]

Would it make sense, in this case, to make a checkbox that is displayed
to admins in case the docextra tab is hidden?
(maybe this would edit a webpreferences object?)

It seems to me that the desire to hide the docextra tab is for any page
that displays some kind of summary: you'd expect the docextra function
on "data pages" not on "summary pages"; i suppose this is likely to be
the case of many other pages.

Paul

> Ecaterina Moraru (Valica) 
> 14 octobre 2015 19:19
> Hi,
>
> #docextra tabs are particular important for content pages where users are
> encouraged to comment, attach, revise history, etc.
>
> But since XWiki is more than a wiki and the application usage has
> expanded,
> we removed the #docextra tab from many XWiki Contrib applications, like:
> File Manager, Forum, Calendar, etc.
>
> The logic behind was that the applications have as main purpose the
> management of applications entities, not commenting for example.
>
> Also with the Flamingo Skin, the shortcuts to Comments, Attachments, etc.
> can be found in the 'More actions' menu.
>
> So, my question to you is: What do you think about removing the #docextra
> also for default/bundled applications like:
> - Blog.WebHome
> - Dashboard.WebHome
> - Panels.WebHome
> - Scheduler.WebHome
> - Stats.WebHome
> - Main.WebHome?
>
> If we adopt this practice we could document it on:
> http://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HApplicationDesign or
> http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPractices
>
> Thanks,
> Caty
> ___
> devs mailing list
> devs@xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Contrib] XWebIDE Improvements

[Paul Libbrecht]

While I agree that this does not seem like the spontaneous thing one
would wish, I believe it is a trend that is useful to follow. I was at a
symposium on informatics education at school recently and the majority
of software tools were discussed with a focus on mobiles, mostly tablets.
Missing that wave in such a modern IDE sounds like a bad idea.
I guess that accepting that the width has a minimum would be ok.

Paul

Marius Dumitru Florea wrote:
> I'm not sure about "it needs to work on mobile". I don't see myself
> developing applications from a mobile phone, not even from a tablet.

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] FW: Display link on xwiki page

[Paul Libbrecht]

Abdulkadar,

can you describe whether you wish this link display to be persistant at
a given URL?
It's easy to have a parametrized link display, I think, and it's easy to
post a page that contains a link display but... do you want a page? Do
you assume your users will be xwiki logged?

I think you should try to describe things in terms of the XWiki side:
what "wiki document" or "wiki object" or "wiki function" would you expect?
Some of your description seems to be doable by any arbitrary server-side
code in about three lines but I am sure there's something I misunderstand.

Paul

> PATEL, ABDULKADAR 
> 21 septembre 2015 11:10
> Vincent, once again thanks for your reply.
>
> If I add link using JS code, then that link will be lost once the page is 
> refreshed.
> Thus I need to do something on server side. That's why I knowledge xwiki 
> rendering comes into picture.
> Here I see two ways of achieving this :
> 1. Using annotations
> 2. Using comments
>
> Basically the question is :
> How can I update a page with comment/annotation from js code?
>
>
>
> Thanks & Regards,
> Abdulkadar Patel
>
> -Original Message-
> From: Vincent Massol [mailto:vmas...@gmail.com] On Behalf Of 
> vinc...@massol.net
> Sent: Monday, September 21, 2015 1:51 PM
> To: XWiki Users
> Cc: PATEL, ABDULKADAR
> Subject: RE: [xwiki-devs] Display link on xwiki page
>
>  
>
>
>
>
> On 21 Sep 2015 at 10:16:00, PATEL, ABDULKADAR 
> (abdulkadar.pa...@capgemini.com(mailto:abdulkadar.pa...@capgemini.com)) wrote:
>
>>  
>> Hi Vincent,
>>  
>>  
>>  
>>  
>>  
>> Thanks for your response.
>>  
>>  
>> I know it might be very trivial issue but as I am working on xwiki 
>> first time,
>>  
>>  
>> I don’t know basic things and that’s why bugging all of you with my silly 
>> doubts.
>>  
>>  
>>  
>>  
>>  
>> To achieve this use case, I have followed below steps :
>>  
>>  
>>  
>>  
>>  
>> 1. Modified xwiki-min.js file to bind a javascript code which will 
>> display a popup dialog on click of ctrl+shift+N
>
> You shouldn’t do that. You should use a Javascript Extension instead, see 
> http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial
>
>> 2. This dialog fetches projects and issue types from jira server and 
>> displays as dropdown
>
> ok
>
>> 3. Once user clicks on submit, a jira issue is created
>
> ok
>
>> 4. Now I need to display a link near text selected by user in step 1 but 
>> don’t know how to do it.
>
> This is not really related to XWiki (unless you wish to reuse the Annotation 
> code but then I don’t now this code enough to know if you can do this or not).
>
> In any case you could check the Annotation code to understand how it’s done 
> there, basically how to find the location of some text in the content.
>
> I guess there are at least 2 ways:
> * Do that using JS and thus insert your link using JS
> * Do it on the server side using the Rendering engine (this is what 
> Annotation is doing I think) and add some specific HTML marker so that by 
> using JS you can easily insert the link.
>
> In any case what you wish to do is something complex and requires good 
> knowledge of JS (and possibly of XWiki’s Rendering if you choose this 
> solution).
>
> Thanks
> -Vincent
>
>> I have attached code I have added in xwiki-min.js
>>  
>>  
>>  
>>  
>>  
>> You can also suggest if this is a right approach and if I can follow some 
>> other approach.
>>  
>>  
>>  
>>  
>>  
>> Thanks & Regards,
>>  
>>  
>> Abdulkadar Patel
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>> P.S. I have not kept xwiki developers mail list since this mail becomes huge 
>> and will need approval from list moderator.
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>> From: Vincent Massol [mailto:vmas...@gmail.com] On Behalf Of 
>> vinc...@massol.net
>> Sent: Monday, September 21, 2015 12:52 PM
>> To: XWiki Developers
>> Cc: PATEL, ABDULKADAR
>> Subject: Re: [xwiki-devs] Display link on xwiki page
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>> Hi there,
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>> On 18 Sep 2015 at 15:25:44, PATEL, ABDULKADAR 
>> (abdulkadar.pa...@capgemini.com(mailto:abdulkadar.pa...@capgemini.com))(mailto:abdulkadar.pa...@capgemini.com(mailto:abdulkadar.pa...@capgemini.com)))
>>  wrote:
>>  
>>> Hi all,
>>>
>>> Sorry to bug all of you again and again with the same requirement.
>>> But I am also helpless till I get it done.
>>>
>>> I have ebelow use case :
>>>
>>> 1. User selects some text on an xwiki page and hits some keyboard 
>>> shortcut say Alt+ctrl+N
>>>
>>> 2. This opens a popup dialog like shown below :
>>>
>>> [file:///Users/vmassol/Library/Containers/it.bloop.airmail.beta11/Da
>>> ta/Library/Application
>>> Support/Airmail/General/Local/1442819908355112192/Attachments/image0
>>> 04.jpg@01D0F242.DD794520(mailto:Support/Airmail/General/Local/144281
>>> 9908355112192/Attachments/image004.jpg@01D0F242.DD794520)]
>>>
>>>
>>>
>>> 3. As you can see in the screenshot, it displays list of 

Re: [xwiki-devs] [Proposal] Do not use dom4j anymore and instead use JDOM2

[Paul Libbrecht]

That's because it is rather new and the xml flurry has been quite sleepy
(e.g. the general xml mailing list at apache.org is dead).
A better measure stab would be to estimate how central the role of XML
is in these projects. DOM and SAX is typically used when one has to
parse just a bit.

Paul

On 11/06/15 16:19, Sergiu Dumitriu wrote:
 A quick code search on openhub and github:

 * library | openhub | github
 * org.w3c.dom | 180k [1] | 1.1m [2]
 * jdom 1 | 35k [3] | 112k [4]
 * stax | 25k [5] | 127k [6]
 * jdom 2 | 2k [7] | | 20k [8]

 It seems that jdom2 is not that popular, at least not in the projects
 tracked by openhub or hosted on github.

 [1] http://code.openhub.net/search?s=%22import%20org.w3c.dom%22
 [2] https://github.com/search?q=import+org.w3c.domtype=Code
 [3] http://code.openhub.net/search?s=%22import%20org.jdom%22
 [4] https://github.com/search?q=%22import+org.jdom.%22type=Code
 [5] http://code.openhub.net/search?s=%22import%20javax.xml.stream%22
 [6] https://github.com/search?q=%22import+javax.xml.stream%22type=Code
 [7] http://code.openhub.net/search?s=%22import%20org.jdom2%22
 [8] https://github.com/search?q=%22import+org.jdom2%22type=Code

 On 06/10/2015 03:53 PM, Paul Libbrecht wrote:

 On 10/06/15 21:47, Sergiu Dumitriu wrote:
 +1 for removing DOM4J, it's been dead for 10 years.
 But why do we need a non w3c library at all? Why is JDOM better than DOM?
 The main reason is that it is supposedly easier to use for Java
 programmers, but is it that much easier to justify having different
 APIs? The standard DOM is part of the Java language.
 Well... my experience in the ActiveMath group with quite several
 developers is that JDOM is way easier at representing properly the fine
 details of XML in its completeness than DOM. Also, we ran experiment
 with the Xerces DOM implementation around 2005 or so, and basically got
 the following time factors
 - Xerces DOM: 4
 - Xerces SAX with JDOM: 2
 - Saxon SAX with JDOM: 1
 So we kept the latest. Note that Xerces is what's inside Oracle's JVM
 (or used to be).
 Memory was also considerably better using JDOM.

 The modern way would be to go for StAX but that is a huge programming
 change.

 paul







signature.asc
Description: OpenPGP digital signature
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Do not use dom4j anymore and instead use JDOM2

[Paul Libbrecht]

On 10/06/15 21:47, Sergiu Dumitriu wrote:
 +1 for removing DOM4J, it's been dead for 10 years.
 But why do we need a non w3c library at all? Why is JDOM better than DOM?
 The main reason is that it is supposedly easier to use for Java
 programmers, but is it that much easier to justify having different
 APIs? The standard DOM is part of the Java language.
Well... my experience in the ActiveMath group with quite several
developers is that JDOM is way easier at representing properly the fine
details of XML in its completeness than DOM. Also, we ran experiment
with the Xerces DOM implementation around 2005 or so, and basically got
the following time factors
- Xerces DOM: 4
- Xerces SAX with JDOM: 2
- Saxon SAX with JDOM: 1
So we kept the latest. Note that Xerces is what's inside Oracle's JVM
(or used to be).
Memory was also considerably better using JDOM.

The modern way would be to go for StAX but that is a huge programming
change.

paul



signature.asc
Description: OpenPGP digital signature
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Proposal] Do not use dom4j anymore and instead use JDOM2

[Paul Libbrecht]

I can testify that jdom2 is maintained and quite professionally.
It's not very live but it's nicely maintained. Today, on the list, for
example, a team submitted performance test results and Rolf (the main
maintainer currently) discussed it.

paul

On 10/06/15 17:07, vinc...@massol.net wrote:
 Hi devs,

 I’d like to propose that we agree about:
 * using JDOM2 when needing to parse/output XML files
 * moving away existing code gradually from DOM4J to JDOM2

 Rationale:
 * It would be nice to pick one fwk and have more consistency
 * DOM4J seems not maintained anymore: 
 https://sourceforge.net/projects/dom4j/files/
 * JDOM2 seems maintained: http://jdom.org/news/

 WDYT?

 Thanks
 -Vincent



 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs




signature.asc
Description: OpenPGP digital signature
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Solr] Word delimiter filter on English text

[Paul Libbrecht]

Avoid storing everything imperatively!
(this was done earlier in the Lucene plugin and has been the main cause
of the slowness).

My general rule of thumb is that an index is 10% of a text file.
I really would not be scared by indexing 5 different fields of the text.

paul

On 8/05/15 08:39, Sergiu Dumitriu wrote:
 Well, my usecase is not the same, since I'm indexing ontologies and the
 end purpose is to find the best matching terms. A few numbers though:

 - 4MB ontology with 11k terms ends up as 16M index (including
 spellcheck, and most fields are also stored), searches take ~40ms
 including the XWiki overhead, ~10ms just in Solr
 - 180MB ontology with 24k terms - 100M index, ~15ms Solr search time

 For smaller indexes, it does seem to use more disk space than the
 source, but Lucene is good at indexing larger data sets, and after a
 while the index grows slower than the data.

 For me it is worth the extra disk space, since every user is amazed by
 how good the search is at finding the relevant terms, overcoming typos,
 synonyms, and abbreviations, plus autocomplete while typing.

 In XWiki, not all fields should be indexed in all the ways, since it
 doesn't make sense to expect an exact match on a large textarea or the
 document content.

 On 05/07/2015 09:57 AM, Marius Dumitru Florea wrote:
 Hi Sergiu,

 Can you tell us the effect on the index size (and speed in the end) if
 each field (e.g. document title, a String or TextArea property) is
 indexed in 5 different ways (5 separate fields in the index)? It is
 worth having this configuration by default?

 Thanks,
 Marius

 On Tue, May 5, 2015 at 4:57 PM, Sergiu Dumitriu ser...@xwiki.org wrote:
 I agree with Paul.

 The way I usually do searches is:

 - each field gets indexed several times, including:
 -- exact matches ^5n (field == query)
 -- prefix matches ^1.5n (field ^= query)
 -- same spelling ^1.8n (query words in field)
 -- fuzzy matching ^n (aggressive tokenization and stemming)
 -- stub matching ^.5n (query tokens are prefixes of indexed tokens)
 -- and three catch-all fields where every other field gets copied, with
 spelling, fuzzy and stub variants
 - where n is a factor based on the field's importance: page title and
 name have the highest boost, a catch-all field has the lowest boost
 - search with edismax, pf with double the boost (2n) on
 exact,prefix,spelling,fuzzy and qf on spelling,fuzzy,stub





signature.asc
Description: OpenPGP digital signature
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] [Solr] Word delimiter filter on English text

[Paul Libbrecht]

Eddy,
We want both or?
Dies the query not use edismax? 
If yes, we should make it search the field text_en with higher weight than 
text_en_splitting by setting the boost parameter to
‎ text_en^2 text_eb_splitting^1
Or?
Paul


-- fat fingered on my z10 --
  Message d'origine  
De: Eduard Moraru
Envoyé: Dienstag, 5. Mai 2015 14:13
À: XWiki Developers
Répondre à: XWiki Developers
Objet: Re: [xwiki-devs] [Solr] Word delimiter filter on English text

Hi,

The question is about content fields (document contet, textarea content,
etc.) and not about the document's space name and document name fields,
which will still match in both approaches, right?

As far as I`ve understood it, text_en gets less matches than
text_en_splitting, but text_en has better support for cases where in
text_en_splitting you would have to use a phrase query to get the match
(e.g. Blog.News, xwiki.com, etc.).

IMO, text_en_splitting sounds more adapted to real life uses and to the
fuzziness of user queries. If we want explicit matches for xwiki.com or
Blog.News within a document's content, phrase queries can still be used,
right? (i.e. quoting the explicit string).

Thanks,
Eduard


On Tue, May 5, 2015 at 12:55 PM, Marius Dumitru Florea 
mariusdumitru.flo...@xwiki.com wrote:

 Hi guys,

 I just noticed (while updating the screen shots for the Solr Search UI
 documentation [1]) that searching for blog doesn't match Blog.News
 from the category of BlogIntroduction any more as indicated in [2].

 Debug mode view shows me that Blog.News is indexed as blog.new
 which means the text is not split in blog and news as I would have
 expected in this case.

 After checking the Solr schema configuration I understood that this is
 normal considering that we use the Standard Tokenizer [3] for English
 text which has this exception:

 Periods (dots) that are not followed by whitespace are kept as part
 of the token, including Internet domain names.

 Further investigation showed that before 6.0M1 we used the Word
 Delimiter Filter [4] for English text but I changed this with
 XWIKI-8911 when upgrading to Solr 4.7.0.

 I then noticed that the Solr schema has both text_en and
 text_en_splitting types, the later with this comment:

 A text field with defaults appropriate for English, plus aggressive
 word-splitting and autophrase features enabled. This field is just
 like text_en, except it adds WordDelimiterFilter to enable splitting
 and matching of words on case-change, alpha numeric boundaries, and
 non-alphanumeric chars. This means certain compound word cases will
 work, for example query wi fi will match document WiFi or wi-fi.

 So in case someone wants to use this type instead for English text he
 needs to change the type in:

 dynamicField name=*_en type=text_en indexed=true stored=true
 multiValued=true /

 The question is whether we should use this type by default or not. As
 explained in the comment above, there are downsides.

 Thanks,
 Marius

 [1]
 http://extensions.xwiki.org/xwiki/bin/view/Extension/Solr+Search+Application
 [2]
 http://extensions.xwiki.org/xwiki/bin/download/Extension/Solr+Search+Application/searchHighlighting.png
 [3]
 https://cwiki.apache.org/confluence/display/solr/Tokenizers#Tokenizers-StandardTokenizer
 [4]
 https://cwiki.apache.org/confluence/display/solr/Filter+Descriptions#FilterDescriptions-WordDelimiterFilter
 ___
 devs mailing list
 devs@xwiki.org
 http://lists.xwiki.org/mailman/listinfo/devs

___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] how to debug an empty stack in DefaultDocumentAccessBridge?

[Paul Libbrecht]

After quite a bit exploring, bringing a recompiled version into mine and
debugging.

It appears that:
- DefaultExcution.getContext is very commonly called with an empty stack
field... hence returns null
- the one that interests us, and where it breaks, happens in yet a more
difficult place than what you've been telling, I feel: the
ConversionFilter. From what I could see inside there, it calls to
XhtmlParser.parse that creates the exception. At this point calls to
CurrentEntityReferenceValueProvider seem to be without context.

Is this conversion done on the fly in a filter too in modern XWikis?
As this is called on the velocity page CreateResources/AssetDone, how
would the xhtml conversion filter perform any entity-resolution of
images if it does not know the page that the context would carry?
A parameter, pageName, would be available here. But is this the standard
that would be applied there?

I seem to understand that this is causing our bug, which only appears if
we have attached images whereas external images work fine.
If this is right, either there's a clean adjustment here, to inject the
page context properly for the conversion, or I'll use workaround with
code within my velocity page, after javascript has made these images
become external ones.

thanks

paul




On 29/03/15 11:28, Marius Dumitru Florea wrote:
 From the stack trace, the cause of the failure seems to be that there
 is no ExecutionContext set on the Execution component [1]. On which
 request is this stack trace logged? Is it a GWT-RPC request? In this
 case the Execution is initialized by XWikiContextInitializationFilter
 [2] which calls ServletContainerInitializer#initializeRequest() where
 a new ExecutionContext is put on the Execution [3]. Otherwise, for an
 action request (save, preview, etc.) the ExecutionContext is
 initialized in XWikiAction [4].

 If the ExecutionContext is properly initialized then it means some
 code removes it from the Execution afterwards. Putting some
 breakpoints in DefaultExecution [5] should catch this code.

 Hope this helps,
 Marius

 [1] 
 https://github.com/xwiki/xwiki-platform/blob/xwiki-platform-3.5.1/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/doc/DefaultDocumentAccessBridge.java#L85
 [2] 
 https://github.com/xwiki/xwiki-platform/blob/xwiki-platform-3.5.1/xwiki-platform-core/xwiki-platform-wysiwyg/xwiki-platform-wysiwyg-server/src/main/java/org/xwiki/wysiwyg/server/filter/XWikiContextInitializationFilter.java#L158
 [3] 
 https://github.com/xwiki/xwiki-platform/blob/xwiki-platform-3.5.1/xwiki-platform-core/xwiki-platform-containers/xwiki-platform-container-servlet/src/main/java/org/xwiki/container/servlet/internal/DefaultServletContainerInitializer.java#L103
 [4] 
 https://github.com/xwiki/xwiki-platform/blob/xwiki-platform-3.5.1/xwiki-platform-core/xwiki-platform-oldcore/src/main/java/com/xpn/xwiki/web/XWikiAction.java#L399
 [5] 
 https://github.com/xwiki/xwiki-commons/blob/xwiki-commons-3.5.1/xwiki-commons-core/xwiki-commons-context/src/main/java/org/xwiki/context/internal/DefaultExecution.java

 On Sat, Mar 28, 2015 at 2:37 AM, Paul Libbrecht p...@hoplahup.net wrote:
 Hello XWiki experts,

 in Curriki, we met a bug that seems related to the wysiwyg editor's
 ability to accept html.

 When it does so, and is input with an image, it fails the html
 conversion because of the exception below for the simple (cleaned) content:
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
 htmlhead/headbodypImage/pp!--startimage:false|-|attach|-|sunset-dark2.PNG--img
 alt=sunset-dark2.PNG
 src=http://node1.hoplahup.net/xwiki/bin/download/AssetTemp/dgW1kVv9l2mE9xqA/sunset-dark2.PNG?width=556;/img!--stopimage--/p/body/html

 Yielding the exception:
 Caused by: java.lang.NullPointerException: null
 at
 com.xpn.xwiki.doc.DefaultDocumentAccessBridge.getContext(DefaultDocumentAccessBridge.java:85)
 ~[xwiki-platform-legacy-oldcore-3.5.1.jar:na]
 at
 com.xpn.xwiki.doc.DefaultDocumentAccessBridge.getAttachmentURL(DefaultDocumentAccessBridge.java:847)
 ~[xwiki-platform-legacy-oldcore-3.5.1.jar:na]
 at
 org.xwiki.rendering.internal.wiki.XWikiWikiModel.getLinkURL(XWikiWikiModel.java:137)
 ~[xwiki-platform-rendering-xwiki-3.5.1.jar:na]
 at
 org.xwiki.rendering.internal.wiki.XWikiWikiModel.getImageURL(XWikiWikiModel.java:153)
 ~[xwiki-platform-rendering-xwiki-3.5.1.jar:na]
 at
 org.xwiki.rendering.internal.renderer.xhtml.image.DefaultXHTMLImageRenderer.onImage(DefaultXHTMLImageRenderer.java:120)
 ~[xwiki-rendering-syntax-xhtml-3.5.1.jar:na]
 at
 org.xwiki.rendering.internal.renderer.xhtml.XHTMLChainingRenderer.onImage(XHTMLChainingRenderer.java:545)
 ~[xwiki-rendering-syntax-xhtml-3.5.1.jar:na]
 at
 org.xwiki.rendering.listener.chaining.AbstractChainingListener.onImage(AbstractChainingListener.java:454)
 ~[xwiki-rendering-api-3.5.1.jar:na

[xwiki-devs] how to debug an empty stack in DefaultDocumentAccessBridge?

[Paul Libbrecht]

Hello XWiki experts,

in Curriki, we met a bug that seems related to the wysiwyg editor's
ability to accept html.

When it does so, and is input with an image, it fails the html
conversion because of the exception below for the simple (cleaned) content:
?xml version=1.0 encoding=UTF-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
htmlhead/headbodypImage/pp!--startimage:false|-|attach|-|sunset-dark2.PNG--img
alt=sunset-dark2.PNG
src=http://node1.hoplahup.net/xwiki/bin/download/AssetTemp/dgW1kVv9l2mE9xqA/sunset-dark2.PNG?width=556;/img!--stopimage--/p/body/html

Yielding the exception:
Caused by: java.lang.NullPointerException: null
at
com.xpn.xwiki.doc.DefaultDocumentAccessBridge.getContext(DefaultDocumentAccessBridge.java:85)
~[xwiki-platform-legacy-oldcore-3.5.1.jar:na]
at
com.xpn.xwiki.doc.DefaultDocumentAccessBridge.getAttachmentURL(DefaultDocumentAccessBridge.java:847)
~[xwiki-platform-legacy-oldcore-3.5.1.jar:na]
at
org.xwiki.rendering.internal.wiki.XWikiWikiModel.getLinkURL(XWikiWikiModel.java:137)
~[xwiki-platform-rendering-xwiki-3.5.1.jar:na]
at
org.xwiki.rendering.internal.wiki.XWikiWikiModel.getImageURL(XWikiWikiModel.java:153)
~[xwiki-platform-rendering-xwiki-3.5.1.jar:na]
at
org.xwiki.rendering.internal.renderer.xhtml.image.DefaultXHTMLImageRenderer.onImage(DefaultXHTMLImageRenderer.java:120)
~[xwiki-rendering-syntax-xhtml-3.5.1.jar:na]
at
org.xwiki.rendering.internal.renderer.xhtml.XHTMLChainingRenderer.onImage(XHTMLChainingRenderer.java:545)
~[xwiki-rendering-syntax-xhtml-3.5.1.jar:na]
at
org.xwiki.rendering.listener.chaining.AbstractChainingListener.onImage(AbstractChainingListener.java:454)
~[xwiki-rendering-api-3.5.1.jar:na]
at
org.xwiki.rendering.listener.chaining.AbstractChainingListener.onImage(AbstractChainingListener.java:454)
~[xwiki-rendering-api-3.5.1.jar:na]
at
org.xwiki.rendering.listener.chaining.EmptyBlockChainingListener.onImage(EmptyBlockChainingListener.java:600)
~[xwiki-rendering-api-3.5.1.jar:na]
at
org.xwiki.rendering.listener.chaining.AbstractChainingListener.onImage(AbstractChainingListener.java:454)
~[xwiki-rendering-api-3.5.1.jar:na]
at
org.xwiki.rendering.listener.chaining.BlockStateChainingListener.onImage(BlockStateChainingListener.java:796)
~[xwiki-rendering-api-3.5.1.jar:na]

I am not too sure how to debug that.
Clues would be welcome.

thanks in advance.

Paul



signature.asc
Description: OpenPGP digital signature
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

Re: [xwiki-devs] How to check if a document is publicly readable?

[Paul Libbrecht]

Thanks,
that was I needed.
paul


On 13/02/15 08:33, Djebloun Sidali wrote:

Hi Paul,

You can use this :
http://nexus.xwiki.org/nexus/service/local/repositories/releases/archive/org/xwiki/platform/xwiki-platform-oldcore/5.2/xwiki-platform-oldcore-5.2-javadoc.jar/!/com/xpn/xwiki/api/Document.html#hasAccessLevel(java.lang.String,
java.lang.String)

Or this since 6.1RC

http://extensions.xwiki.org/xwiki/bin/view/Extension/Security+Module#HScriptingAPI28since6.1RC129

Sidali

2015-02-13 7:51 GMT+01:00 Paul Libbrecht p...@hoplahup.net:


That's what I understand too and do not know how to make.
I see no ways to invoke checkAccess indicating a user.

paul


On 13/02/15 01:23, Eduard Moraru wrote:


Hi,

What do you mean by that?

What I understand is that you want to check view rights on the user
XWiki.XWikiGuest.

Thanks,
Eduard

On Fri, Feb 13, 2015 at 12:39 AM, Paul Libbrecht p...@hoplahup.net
wrote:

  Hello dear fellow XWikiers,

what can I do to check if a document is publicly readable?

thanks in advance.

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

  ___

devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs


___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs

[xwiki-devs] How to check if a document is publicly readable?

[Paul Libbrecht]

Hello dear fellow XWikiers,

what can I do to check if a document is publicly readable?

thanks in advance.

Paul
___
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs