Re: [xwiki-devs] [Proposal] Add NS support for Ratings space configuration

2016-03-31 Thread Marius Dumitru Florea 
On Thu, Mar 31, 2016 at 2:54 PM, Vincent Massol  wrote:

>
> > On 31 Mar 2016, at 13:02, Alexandru Cotiuga 
> wrote:
> >
> > Hi devs,
> >
> > As I was working on the Forum Application, which depends on Ratings
> > Application, I noticed that the rating configuration doesn't work as
> > expected on the Nested Spaces versions of XWiki.
> >
> > For example, having A.WebPreferences with a XWiki.RatingsConfigClass
> > object, the configuration does not apply to A.B.WebHome, because the
> > configuration is set at space level, without inheritance to the below
> > levels.
> >
>


> > As a solution for this I propose to create a new Api
> > (getConfigurationDocument()) in the Ratings module which will check,
> > starting the current document, and get the first ancestor that holds the
> > XWiki.RatingsConfigClass object and use that as configuration document,
> > keeping the fallback to the XWiki.RatingsConfig document.
>

What I don't like about this solution is the fact that once you add a
XWiki.RatingsConfigClass
object to A.B you completely overwrite the configuration from A, while you
may simply want to overwrite just one configuration property. Of course,
this raises the problem of knowing if a configuration property is set or
not. The empty string may have a meaning.

Also, note that this is a generic need. Other applications might want the
same configuration inheritance. As Vincent suggested, we could create a
generic configuration source for this.

Thanks,
Marius


> >
> > An issue has been created at http://jira.xwiki.org/browse/XWIKI-13274
> and a
> > first pull request at https://github.com/xwiki/xwiki-platform/pull/472,
> but
> > without having been discussed here before.
> >
> > WDYT?
>
> Sounds good to me. I gave several comments in the PR. One important one is
> to introduce a RatingsConfiguration component to hold the Ratings module’s
> configuration and have the various other Ratings components use it,
> including the ScriptService since right now there are at least 3 places
> getting the config.
>
> 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] [Proposal] Change our Script API best practice regarding exception handling (Take 2)

2016-03-31 Thread Thomas Mortagne 
+1 it certainly makes writing script services much easier (and harder
to ignore proper error handling on script side :))

On Thu, Mar 31, 2016 at 3:20 PM, Marius Dumitru Florea
 wrote:
> +1 for throwing exceptions in script services and using #try to catch them
> if we want.
>
> Thanks,
> Marius
>
> On Thu, Mar 31, 2016 at 3:17 PM, Vincent Massol  wrote:
>
>> Guys, I’d like that we progress on this.
>>
>> I didn’t get any agreement or disagreement to this proposal.
>>
>> Any take?
>>
>> Thanks
>> -Vincent
>>
>>
>> > On 18 Jan 2016, at 11:03, vinc...@massol.net wrote:
>> >
>> > 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
>> >
>> >
>> > On 14 Jan 2016 at 17:51:04, vinc...@massol.net (vinc...@massol.net
>> (mailto:vinc...@massol.net)) wrote:
>> >
>> > > 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



-- 
Thomas Mortagne
___
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)

2016-03-31 Thread Marius Dumitru Florea 
+1 for throwing exceptions in script services and using #try to catch them
if we want.

Thanks,
Marius

On Thu, Mar 31, 2016 at 3:17 PM, Vincent Massol  wrote:

> Guys, I’d like that we progress on this.
>
> I didn’t get any agreement or disagreement to this proposal.
>
> Any take?
>
> Thanks
> -Vincent
>
>
> > On 18 Jan 2016, at 11:03, vinc...@massol.net wrote:
> >
> > 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
> >
> >
> > On 14 Jan 2016 at 17:51:04, vinc...@massol.net (vinc...@massol.net
> (mailto:vinc...@massol.net)) wrote:
> >
> > > 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] Is there java API to list/create/update/delete objects on a wiki page?

2016-03-31 Thread Vincent Massol 
See also the scripting guide:
http://platform.xwiki.org/xwiki/bin/view/DevGuide/APIGuide#HAddobjectstoapage

Thanks
-Vincent

> On 31 Mar 2016, at 15:05, Eduard Moraru  wrote:
> 
> Hi,
> 
> Please have a look over the Dev Guide (
> http://platform.xwiki.org/xwiki/bin/view/DevGuide/ ) , specifically:
> http://platform.xwiki.org/xwiki/bin/view/DevGuide/API and implicitly
> http://nexus.xwiki.org/nexus/service/local/repositories/releases/archive/org/xwiki/platform/xwiki-platform-bridge/7.4.2/xwiki-platform-bridge-7.4.2-javadoc.jar/!/index.html
> 
> For oldcore, see:
> http://nexus.xwiki.org/nexus/service/local/repositories/releases/archive/org/xwiki/platform/xwiki-platform-oldcore/7.4.2/xwiki-platform-oldcore-7.4.2-javadoc.jar/!/index.html
> 
> Thanks,
> Eduard
> 
> On Thu, Mar 31, 2016 at 3:41 PM, abtv  wrote:
> 
>> I need something like
>> 
>> http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI#HCreatinganXWikiObject
>> but with java API. I use DocumentAccessBridge to access xwiki pages. I need
>> something like this to access objects programmatically.
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://xwiki.475771.n2.nabble.com/Is-there-java-API-to-list-create-update-delete-objects-on-a-wiki-page-tp7598758.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

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

Re: [xwiki-devs] [Proposal] Modification of URL format for the webjars type

2016-03-31 Thread Thomas Mortagne 
Yes we introduced a regression since the main issue that leaded to
move webjar support to its dedicated resource handler was relative
path.

On Thu, Mar 31, 2016 at 2:44 PM, Marius Dumitru Florea
 wrote:
> Unfortunately I didn't realize that putting the wiki in the query string
> prevents us from using relative paths in WebJar resource. For instance a
> CSS file cannot use an image located in the same WebJar using a relative
> path, if the CSS is loaded from a WebJar installed on a subwiki. We need to
> find a better solution.
>
> On Tue, Dec 8, 2015 at 8:19 PM, Marius Dumitru Florea <
> mariusdumitru.flo...@xwiki.com> wrote:
>
>> +1
>>
>> Thanks,
>> Marius
>>
>> On Tue, Dec 8, 2015 at 4:34 PM, vinc...@massol.net 
>> wrote:
>>
>>> Hi devs,
>>>
>>> Seems I forgot a use case when introducing the new webjars URL format in
>>> http://jira.xwiki.org/browse/XWIKI-10881 and we need to add the wiki
>>> somewhere in the URL to serve some webjar resource located in a different
>>> subwiki (this is http://jira.xwiki.org/browse/XWIKI-12884).
>>>
>>> I’m proposing this updated wrbjars URL format (updated from
>>> http://extensions.xwiki.org/xwiki/bin/view/Extension/WebJars+Integration#HURLFormat
>>> ):
>>>
>>> http:///>> path>/webjars/[?version==true|false=>> name>]
>>>
>>> Specifically I’ve added the optional wiki query string parameter. This
>>> means also updating the url() Script Service API to use that new parameter
>>> when the resource is not on the current wiki.
>>>
>>> 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



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

Re: [xwiki-devs] [Proposal] Modification of URL format for the webjars type

2016-03-31 Thread Marius Dumitru Florea 
Unfortunately I didn't realize that putting the wiki in the query string
prevents us from using relative paths in WebJar resource. For instance a
CSS file cannot use an image located in the same WebJar using a relative
path, if the CSS is loaded from a WebJar installed on a subwiki. We need to
find a better solution.

On Tue, Dec 8, 2015 at 8:19 PM, Marius Dumitru Florea <
mariusdumitru.flo...@xwiki.com> wrote:

> +1
>
> Thanks,
> Marius
>
> On Tue, Dec 8, 2015 at 4:34 PM, vinc...@massol.net 
> wrote:
>
>> Hi devs,
>>
>> Seems I forgot a use case when introducing the new webjars URL format in
>> http://jira.xwiki.org/browse/XWIKI-10881 and we need to add the wiki
>> somewhere in the URL to serve some webjar resource located in a different
>> subwiki (this is http://jira.xwiki.org/browse/XWIKI-12884).
>>
>> I’m proposing this updated wrbjars URL format (updated from
>> http://extensions.xwiki.org/xwiki/bin/view/Extension/WebJars+Integration#HURLFormat
>> ):
>>
>> http:///> path>/webjars/[?version==true|false=> name>]
>>
>> Specifically I’ve added the optional wiki query string parameter. This
>> means also updating the url() Script Service API to use that new parameter
>> when the resource is not on the current wiki.
>>
>> 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

[xwiki-devs] Is there java API to list/create/update/delete objects on a wiki page?

2016-03-31 Thread abtv 
I need something like
http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI#HCreatinganXWikiObject
but with java API. I use DocumentAccessBridge to access xwiki pages. I need
something like this to access objects programmatically.



--
View this message in context: 
http://xwiki.475771.n2.nabble.com/Is-there-java-API-to-list-create-update-delete-objects-on-a-wiki-page-tp7598758.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

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

2016-03-31 Thread Vincent Massol 
Guys, I’d like that we progress on this.

I didn’t get any agreement or disagreement to this proposal.

Any take?

Thanks
-Vincent


> On 18 Jan 2016, at 11:03, vinc...@massol.net wrote:
> 
> 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
> 
> 
> On 14 Jan 2016 at 17:51:04, vinc...@massol.net 
> (vinc...@massol.net(mailto:vinc...@massol.net)) wrote:
> 
> > 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

Re: [xwiki-devs] [Proposal] Add NS support for Ratings space configuration

2016-03-31 Thread Vincent Massol 

> On 31 Mar 2016, at 13:02, Alexandru Cotiuga  
> wrote:
> 
> Hi devs,
> 
> As I was working on the Forum Application, which depends on Ratings
> Application, I noticed that the rating configuration doesn't work as
> expected on the Nested Spaces versions of XWiki.
> 
> For example, having A.WebPreferences with a XWiki.RatingsConfigClass
> object, the configuration does not apply to A.B.WebHome, because the
> configuration is set at space level, without inheritance to the below
> levels.
> 
> As a solution for this I propose to create a new Api
> (getConfigurationDocument()) in the Ratings module which will check,
> starting the current document, and get the first ancestor that holds the
> XWiki.RatingsConfigClass object and use that as configuration document,
> keeping the fallback to the XWiki.RatingsConfig document.
> 
> An issue has been created at http://jira.xwiki.org/browse/XWIKI-13274 and a
> first pull request at https://github.com/xwiki/xwiki-platform/pull/472, but
> without having been discussed here before.
> 
> WDYT?

Sounds good to me. I gave several comments in the PR. One important one is to 
introduce a RatingsConfiguration component to hold the Ratings module’s 
configuration and have the various other Ratings components use it, including 
the ScriptService since right now there are at least 3 places getting the 
config.

Thanks
-Vincent

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

Re: [xwiki-devs] How to run RTWysiwyg extension not in demo mode?

2016-03-31 Thread Ludovic Dubost 
Hi,

A new version 1.10 was released this morning which should fix the issues
you saw in 1.9 an should be improved compared to 1.7. It should behave much
better when you make changes in 2 different editors.

Don't hesitate to report any issues you might have.  The next steps are to
improve the concurrency editing (you need to be 2 people to see the issues
there).

Note that CKEditor integration has also been updated yesterday to version
1.4 and that it's still new so it could have bugs. Don't hesitate to report
issues also that you find on CKEditor.

Ludovic

--
*Ludovic Dubost*
*Founder and CEO*
ludo...@xwiki.com
skype: ldubost
Blog: http://blog.ludovic.org

On Wed, Mar 30, 2016 at 7:05 PM, abtv  wrote:

> I'm working with 1.7 (it works in general) and from time to time I see the
> following in console:
> cursor.js?cb=1459354594606:239 [cursor.fixSelection] At least one of the
> cursor nodes did not exist, could not fix selection
>
>
>
> --
> View this message in context:
> http://xwiki.475771.n2.nabble.com/How-to-run-RTWysiwyg-extension-not-in-demo-mode-tp7598488p7598746.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

[xwiki-devs] [Proposal] Add NS support for Ratings space configuration

2016-03-31 Thread Alexandru Cotiuga 
Hi devs,

As I was working on the Forum Application, which depends on Ratings
Application, I noticed that the rating configuration doesn't work as
expected on the Nested Spaces versions of XWiki.

For example, having A.WebPreferences with a XWiki.RatingsConfigClass
object, the configuration does not apply to A.B.WebHome, because the
configuration is set at space level, without inheritance to the below
levels.

As a solution for this I propose to create a new Api
(getConfigurationDocument()) in the Ratings module which will check,
starting the current document, and get the first ancestor that holds the
XWiki.RatingsConfigClass object and use that as configuration document,
keeping the fallback to the XWiki.RatingsConfig document.

An issue has been created at http://jira.xwiki.org/browse/XWIKI-13274 and a
first pull request at https://github.com/xwiki/xwiki-platform/pull/472, but
without having been discussed here before.

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

[xwiki-devs] [XWiki Day] BFD#97

2016-03-31 Thread Eduard Moraru 
Hi devs,

Today is BFD#97:
http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays

Our current status for the 1 year period is 146 bugs behind. See:
http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=1#Created-vs-Resolved-Chart/10470

Here's the BFD#97 dashboard to follow the progress during the day:
http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13602

Thanks and enjoy your bug fixing day!

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

Re: [xwiki-devs] How to make CKEditor a default editor for XWiki?

2016-03-31 Thread Marius Dumitru Florea 
Have you checked the documentation for the CKEditor Integration extension?
http://extensions.xwiki.org/xwiki/bin/view/Extension/CKEditor+Integration#HReplacetheDefaultEditor

Hope this helps,
Marius

On Wed, Mar 30, 2016 at 9:58 PM, abtv  wrote:

> How to make CKEditor a default editor for XWiki? I need that user just
> press
> edit and open a page with CKEditor.
>
> It doesn't help:
>
> http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Configuration#HSettingthedefaulteditortouse28WikiorWYSIWYG29
>
> CKEditor is not on a list. Maybe it's still possible, I would prefer to do
> it with java code on start as i do for authenticate_view setting.
>
>
>
> --
> View this message in context:
> http://xwiki.475771.n2.nabble.com/How-to-make-CKEditor-a-default-editor-for-XWiki-tp7598749.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