[xwiki-devs] [VOTE] Retire old query plugin
Hi devs, Following the discussion on http://markmail.org/message/uck6w56gqus2mxsw I would like to extract the query plugin from xwiki-platform-legacy-oldcore and move it to retired repository. The good things is that we will get rid of 3 jars in standard XE by doing this. I plan to do it in 4.4M1. WDYT ? Here is my +1 -- Thomas Mortagne
+1 Best Regards, /Andreas 2012-11-16 11:32, Thomas Mortagne skrev:
Hi devs,
Following the discussion on http://markmail.org/message/uck6w56gqus2mxsw I would like to extract the query plugin from xwiki-platform-legacy-oldcore and move it to retired repository.
The good things is that we will get rid of 3 jars in standard XE by doing this.
I plan to do it in 4.4M1.
WDYT ?
Here is my +1
What is the old query plugin? I hope it is not $xwiki.query. On Fri, Nov 16, 2012 at 7:32 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
Following the discussion on http://markmail.org/message/uck6w56gqus2mxsw I would like to extract the query plugin from xwiki-platform-legacy-oldcore and move it to retired repository.
The good things is that we will get rid of 3 jars in standard XE by doing this.
I plan to do it in 4.4M1.
WDYT ?
Here is my +1 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
It is. This plugin is deprecated since a very long time. Look at http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Module for informations about the "new" one (which exists since 1.6). On Fri, Nov 16, 2012 at 12:57 PM, crocket <[email protected]> wrote:
What is the old query plugin? I hope it is not $xwiki.query.
On Fri, Nov 16, 2012 at 7:32 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
Following the discussion on http://markmail.org/message/uck6w56gqus2mxswI would like to extract the query plugin from xwiki-platform-legacy-oldcore and move it to retired repository.
The good things is that we will get rid of 3 jars in standard XE by doing this.
I plan to do it in 4.4M1.
WDYT ?
Here is my +1 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
+1 Thanks, Eduard On Fri, Nov 16, 2012 at 3:02 PM, Thomas Mortagne <[email protected]>wrote:
It is.
This plugin is deprecated since a very long time. Look at http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Module for informations about the "new" one (which exists since 1.6).
On Fri, Nov 16, 2012 at 12:57 PM, crocket <[email protected]> wrote:
What is the old query plugin? I hope it is not $xwiki.query.
On Fri, Nov 16, 2012 at 7:32 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
Following the discussion on http://markmail.org/message/uck6w56gqus2mxswI would like to extract the query plugin from xwiki-platform-legacy-oldcore and move it to retired repository.
The good things is that we will get rid of 3 jars in standard XE by doing this.
I plan to do it in 4.4M1.
WDYT ?
Here is my +1 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Can you point to the code of the old query plugin. I'm probably -1 because it contains some code that is usefull to generate Search UIs. This code should be moved to the new query component before the plugin is removed Ludovic 2012/11/16 Eduard Moraru <[email protected]>
+1
Thanks, Eduard
On Fri, Nov 16, 2012 at 3:02 PM, Thomas Mortagne <[email protected]>wrote:
It is.
This plugin is deprecated since a very long time. Look at http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Module for informations about the "new" one (which exists since 1.6).
On Fri, Nov 16, 2012 at 12:57 PM, crocket <[email protected]> wrote:
What is the old query plugin? I hope it is not $xwiki.query.
On Fri, Nov 16, 2012 at 7:32 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
Following the discussion on http://markmail.org/message/uck6w56gqus2mxswI would like to extract the query plugin from xwiki-platform-legacy-oldcore and move it to retired repository.
The good things is that we will get rid of 3 jars in standard XE by doing this.
I plan to do it in 4.4M1.
WDYT ?
Here is my +1 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Fri, Nov 16, 2012 at 3:28 PM, Ludovic Dubost <[email protected]> wrote:
Can you point to the code of the old query plugin. I'm probably -1 because it contains some code that is usefull to generate Search UIs. This code should be moved to the new query component before the plugin is removed
https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik... The whole point of moving something to legacy is that it's not used anymore and we provide alternative for it, if there is missing feature in the query module it should listed and added.
Ludovic
2012/11/16 Eduard Moraru <[email protected]>
+1
Thanks, Eduard
On Fri, Nov 16, 2012 at 3:02 PM, Thomas Mortagne <[email protected]>wrote:
It is.
This plugin is deprecated since a very long time. Look at http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Module for informations about the "new" one (which exists since 1.6).
On Fri, Nov 16, 2012 at 12:57 PM, crocket <[email protected]> wrote:
What is the old query plugin? I hope it is not $xwiki.query.
On Fri, Nov 16, 2012 at 7:32 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
Following the discussion on http://markmail.org/message/uck6w56gqus2mxswI would like to extract the query plugin from xwiki-platform-legacy-oldcore and move it to retired repository.
The good things is that we will get rid of 3 jars in standard XE by doing this.
I plan to do it in 4.4M1.
WDYT ?
Here is my +1 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi, The reality right now is that there is no alternative to this code that has been moved to legacy, at least for part of it. Let me explain a bit what some of this code is doing. - it allows to create a java object XWikiQuery which represents an XWiki Query in Java as a structured object per field. This object stores criterias - the XWiki Core itself provides a function to display a search field for each field of an XWiki class (displaySearch) and a function that allows to retrieve the content of search a search field into an XWikiQuery object, as well as a function to transform the part concerning the field in the XWikiQuery object into an XWQL statement portion - some functions in XWiki.java (moved to aspects in legacy) also allow to generate a field to choose the columns and the sort fields for a query - the query plugin allows to transform the XWikiQuery object into an XWQL statement including the sort fields - a function in XWiki.java allows in one call to read the data from $request, create the XWikiQuery object, transform it in XWQL, run the query and display the results as an HTML table - another function allows just to run the query and velocity code can present the results just the way you decide The end results is a system to build query interfaces dynamically. We haven't used this code because nobody has been trained on it. But still it's very powerful code, and I'd hate to see it go away without a replacement. Currently it's not that complex to keep it. Most of the code is in the XWiki fields anyway. The code in XWikiQuery and in QueryPlugin is not that complicated as it's just looping over the fields. On the long run this code has even more capabilities, like being able to run query aggregates in addition to just listing XWiki documents. This could allow to do counting and summing using a UI and even generate a graph out of the result using the Graph Plugin. Once you activate the QueryPlugin in xwiki.cfg this code still works. It would be great if somebody from the active committers looked at it and we could work together to see where this code should be headed. I'm available to help understand the code. Right now the key functions are: - the XWikiQuery class - QueryPlugin.makeQuery - XWiki.createQueryFromRequest - XWiki.displaySearch - XWiki.displaySearchColumns - XWiki.displaySearchOrder - and code in each XWiki Field class less important code is: - XWiki.search(XWikiQuery) - XWiki.searchAsTable(XWikiQuery) Ludovic 2012/11/16 Thomas Mortagne <[email protected]>
On Fri, Nov 16, 2012 at 3:28 PM, Ludovic Dubost <[email protected]> wrote:
Can you point to the code of the old query plugin. I'm probably -1 because it contains some code that is usefull to generate Search UIs. This code should be moved to the new query component before the plugin is removed
https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik...
The whole point of moving something to legacy is that it's not used anymore and we provide alternative for it, if there is missing feature in the query module it should listed and added.
Ludovic
2012/11/16 Eduard Moraru <[email protected]>
+1
Thanks, Eduard
On Fri, Nov 16, 2012 at 3:02 PM, Thomas Mortagne <[email protected]>wrote:
It is.
This plugin is deprecated since a very long time. Look at http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Modulefor informations about the "new" one (which exists since 1.6).
On Fri, Nov 16, 2012 at 12:57 PM, crocket <[email protected]> wrote:
What is the old query plugin? I hope it is not $xwiki.query.
On Fri, Nov 16, 2012 at 7:32 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
Following the discussion on http://markmail.org/message/uck6w56gqus2mxswI would like to extract the query plugin from xwiki-platform-legacy-oldcore and move it to retired repository.
The good things is that we will get rid of 3 jars in standard XE by doing this.
I plan to do it in 4.4M1.
WDYT ?
Here is my +1 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Sat, Nov 17, 2012 at 10:46 AM, Ludovic Dubost <[email protected]> wrote:
Hi,
The reality right now is that there is no alternative to this code that has been moved to legacy, at least for part of it.
Let me explain a bit what some of this code is doing.
- it allows to create a java object XWikiQuery which represents an XWiki Query in Java as a structured object per field. This object stores criterias - the XWiki Core itself provides a function to display a search field for each field of an XWiki class (displaySearch) and a function that allows to retrieve the content of search a search field into an XWikiQuery object, as well as a function to transform the part concerning the field in the XWikiQuery object into an XWQL statement portion
Only really works if that very old patch is applied: http://jira.xwiki.org/browse/XWIKI-4585
- some functions in XWiki.java (moved to aspects in legacy) also allow to generate a field to choose the columns and the sort fields for a query - the query plugin allows to transform the XWikiQuery object into an XWQL statement including the sort fields - a function in XWiki.java allows in one call to read the data from $request, create the XWikiQuery object, transform it in XWQL, run the query and display the results as an HTML table - another function allows just to run the query and velocity code can present the results just the way you decide
The end results is a system to build query interfaces dynamically.
We haven't used this code because nobody has been trained on it. But still
It is being used in only one of our project. The reason is that the experience was not good enough to reuse it. This was a really great feature, but due to the issues and so unexpected limitation (do not ask, I do not remember) if have choosen to leave it alone.
it's very powerful code, and I'd hate to see it go away without a replacement. Currently it's not that complex to keep it. Most of the code is in the XWiki fields anyway. The code in XWikiQuery and in QueryPlugin is not that complicated as it's just looping over the fields.
On the long run this code has even more capabilities, like being able to run query aggregates in addition to just listing XWiki documents. This could allow to do counting and summing using a UI and even generate a graph out of the result using the Graph Plugin.
I really agree that we should plan for similar feature, using the new model, and the new component.
Once you activate the QueryPlugin in xwiki.cfg this code still works.
I would not be so sure of that since almost nobody really use the query plugin that way, or my patch has more success than I thought.
It would be great if somebody from the active committers looked at it and we could work together to see where this code should be headed. I'm available to help understand the code.
If I had seen it so valuable after our first try, I would have do so since long. Moving the plugin to legacy does not means that we loose it. IMO, keeping this plugin currently cause confusion with the new query manager, which is worse compare to what it really provide. This is why I am +1. Now I do agree that the idea should not be lost and that we should plane a replacement for it once the new model is ready. Compare to the general rule which is to keep until we replace, I think it does not apply here, since almost nobody use the part not replaced by the new query manager (else we would have received more complains about it not working due to XWIKI-4585 and more) Now if anyone is really using it, tell us what you do that is not covered by the new query manager. This could change my vote.
Right now the key functions are:
- the XWikiQuery class - QueryPlugin.makeQuery - XWiki.createQueryFromRequest - XWiki.displaySearch - XWiki.displaySearchColumns - XWiki.displaySearchOrder - and code in each XWiki Field class
less important code is:
- XWiki.search(XWikiQuery) - XWiki.searchAsTable(XWikiQuery)
Ludovic
2012/11/16 Thomas Mortagne <[email protected]>
On Fri, Nov 16, 2012 at 3:28 PM, Ludovic Dubost <[email protected]> wrote:
Can you point to the code of the old query plugin. I'm probably -1 because it contains some code that is usefull to generate Search UIs. This code should be moved to the new query component before the plugin is removed
https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik...
The whole point of moving something to legacy is that it's not used
anymore
and we provide alternative for it, if there is missing feature in the query module it should listed and added.
Ludovic
2012/11/16 Eduard Moraru <[email protected]>
+1
Thanks, Eduard
On Fri, Nov 16, 2012 at 3:02 PM, Thomas Mortagne <[email protected]>wrote:
It is.
This plugin is deprecated since a very long time. Look at
http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Modulefor
informations about the "new" one (which exists since 1.6).
On Fri, Nov 16, 2012 at 12:57 PM, crocket <[email protected]
wrote:
What is the old query plugin? I hope it is not $xwiki.query.
On Fri, Nov 16, 2012 at 7:32 PM, Thomas Mortagne <[email protected]>wrote:
> Hi devs, > > Following the discussion on http://markmail.org/message/uck6w56gqus2mxswI > would like to extract the query plugin from xwiki-platform-legacy-oldcore > and move it to retired repository. > > The good things is that we will get rid of 3 jars in standard
XE by
doing
> this. > > I plan to do it in 4.4M1. > > WDYT ? > > Here is my +1 > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
Envoyé de mon iPad Le 17 nov. 2012 à 13:35, Denis Gervalle <[email protected]> a écrit :
On Sat, Nov 17, 2012 at 10:46 AM, Ludovic Dubost <[email protected]> wrote:
Hi,
The reality right now is that there is no alternative to this code that has been moved to legacy, at least for part of it.
Let me explain a bit what some of this code is doing.
- it allows to create a java object XWikiQuery which represents an XWiki Query in Java as a structured object per field. This object stores criterias - the XWiki Core itself provides a function to display a search field for each field of an XWiki class (displaySearch) and a function that allows to retrieve the content of search a search field into an XWikiQuery object, as well as a function to transform the part concerning the field in the XWikiQuery object into an XWQL statement portion
Only really works if that very old patch is applied: http://jira.xwiki.org/browse/XWIKI-4585
I think I committed some code since then to make it generate xwql. I juste trier it on 4.3m2 and my sample works
- some functions in XWiki.java (moved to aspects in legacy) also allow to generate a field to choose the columns and the sort fields for a query - the query plugin allows to transform the XWikiQuery object into an XWQL statement including the sort fields - a function in XWiki.java allows in one call to read the data from $request, create the XWikiQuery object, transform it in XWQL, run the query and display the results as an HTML table - another function allows just to run the query and velocity code can present the results just the way you decide
The end results is a system to build query interfaces dynamically.
We haven't used this code because nobody has been trained on it. But still
It is being used in only one of our project. The reason is that the experience was not good enough to reuse it. This was a really great feature, but due to the issues and so unexpected limitation (do not ask, I do not remember) if have choosen to leave it alone.
The limitation is that you cannot extend it to do custom querying but it could
it's very powerful code, and I'd hate to see it go away without a replacement. Currently it's not that complex to keep it. Most of the code is in the XWiki fields anyway. The code in XWikiQuery and in QueryPlugin is not that complicated as it's just looping over the fields.
On the long run this code has even more capabilities, like being able to run query aggregates in addition to just listing XWiki documents. This could allow to do counting and summing using a UI and even generate a graph out of the result using the Graph Plugin.
I really agree that we should plan for similar feature, using the new model, and the new component.
Once you activate the QueryPlugin in xwiki.cfg this code still works.
I would not be so sure of that since almost nobody really use the query plugin that way, or my patch has more success than I thought.
It would be great if somebody from the active committers looked at it and we could work together to see where this code should be headed. I'm available to help understand the code.
If I had seen it so valuable after our first try, I would have do so since long. Moving the plugin to legacy does not means that we loose it. IMO, keeping this plugin currently cause confusion with the new query manager, which is worse compare to what it really provide. This is why I am +1.
Now I do agree that the idea should not be lost and that we should plane a replacement for it once the new model is ready. Compare to the general rule which is to keep until we replace, I think it does not apply here, since almost nobody use the part not replaced by the new query manager (else we would have received more complains about it not working due to XWIKI-4585 and more)
Now if anyone is really using it, tell us what you do that is not covered by the new query manager. This could change my vote.
It's the round trip from forms and the query generation What i don't like in dropping the code without replacement is that we Will postpone working on this. Now it might be possible to port it to groovy Ludovic
Right now the key functions are:
- the XWikiQuery class - QueryPlugin.makeQuery - XWiki.createQueryFromRequest - XWiki.displaySearch - XWiki.displaySearchColumns - XWiki.displaySearchOrder - and code in each XWiki Field class
less important code is:
- XWiki.search(XWikiQuery) - XWiki.searchAsTable(XWikiQuery)
Ludovic
2012/11/16 Thomas Mortagne <[email protected]>
On Fri, Nov 16, 2012 at 3:28 PM, Ludovic Dubost <[email protected]> wrote:
Can you point to the code of the old query plugin. I'm probably -1 because it contains some code that is usefull to generate Search UIs. This code should be moved to the new query component before the plugin is removed
https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik...
The whole point of moving something to legacy is that it's not used
anymore
and we provide alternative for it, if there is missing feature in the query module it should listed and added.
Ludovic
2012/11/16 Eduard Moraru <[email protected]>
+1
Thanks, Eduard
On Fri, Nov 16, 2012 at 3:02 PM, Thomas Mortagne <[email protected]>wrote:
It is.
This plugin is deprecated since a very long time. Look at
http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Modulefor
informations about the "new" one (which exists since 1.6).
On Fri, Nov 16, 2012 at 12:57 PM, crocket <[email protected]
wrote:
> What is the old query plugin? I hope it is not $xwiki.query. > > > On Fri, Nov 16, 2012 at 7:32 PM, Thomas Mortagne > <[email protected]>wrote: > >> Hi devs, >> >> Following the discussion on http://markmail.org/message/uck6w56gqus2mxswI >> would like to extract the query plugin from xwiki-platform-legacy-oldcore >> and move it to retired repository. >> >> The good things is that we will get rid of 3 jars in standard
XE by
doing >> this. >> >> I plan to do it in 4.4M1. >> >> WDYT ? >> >> Here is my +1 >> -- >> Thomas Mortagne >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Nov 17, 2012, at 1:35 PM, Denis Gervalle <[email protected]> wrote:
On Sat, Nov 17, 2012 at 10:46 AM, Ludovic Dubost <[email protected]> wrote:
Hi,
The reality right now is that there is no alternative to this code that has been moved to legacy, at least for part of it.
Let me explain a bit what some of this code is doing.
- it allows to create a java object XWikiQuery which represents an XWiki Query in Java as a structured object per field. This object stores criterias - the XWiki Core itself provides a function to display a search field for each field of an XWiki class (displaySearch) and a function that allows to retrieve the content of search a search field into an XWikiQuery object, as well as a function to transform the part concerning the field in the XWikiQuery object into an XWQL statement portion
Only really works if that very old patch is applied: http://jira.xwiki.org/browse/XWIKI-4585
- some functions in XWiki.java (moved to aspects in legacy) also allow to generate a field to choose the columns and the sort fields for a query - the query plugin allows to transform the XWikiQuery object into an XWQL statement including the sort fields - a function in XWiki.java allows in one call to read the data from $request, create the XWikiQuery object, transform it in XWQL, run the query and display the results as an HTML table - another function allows just to run the query and velocity code can present the results just the way you decide
The end results is a system to build query interfaces dynamically.
We haven't used this code because nobody has been trained on it. But still
It is being used in only one of our project. The reason is that the experience was not good enough to reuse it. This was a really great feature, but due to the issues and so unexpected limitation (do not ask, I do not remember) if have choosen to leave it alone.
it's very powerful code, and I'd hate to see it go away without a replacement. Currently it's not that complex to keep it. Most of the code is in the XWiki fields anyway. The code in XWikiQuery and in QueryPlugin is not that complicated as it's just looping over the fields.
On the long run this code has even more capabilities, like being able to run query aggregates in addition to just listing XWiki documents. This could allow to do counting and summing using a UI and even generate a graph out of the result using the Graph Plugin.
I really agree that we should plan for similar feature, using the new model, and the new component.
Once you activate the QueryPlugin in xwiki.cfg this code still works.
I would not be so sure of that since almost nobody really use the query plugin that way, or my patch has more success than I thought.
It would be great if somebody from the active committers looked at it and we could work together to see where this code should be headed. I'm available to help understand the code.
If I had seen it so valuable after our first try, I would have do so since long. Moving the plugin to legacy does not means that we loose it. IMO, keeping this plugin currently cause confusion with the new query manager, which is worse compare to what it really provide. This is why I am +1.
Now I do agree that the idea should not be lost and that we should plane a replacement for it once the new model is ready. Compare to the general rule which is to keep until we replace, I think it does not apply here, since almost nobody use the part not replaced by the new query manager (else we would have received more complains about it not working due to XWIKI-4585 and more)
BTW "keep until replace" is not a current rule of the xwiki project. Right now the practice that we have followed instead is: retire/deprecate when quality is not high enough and nobody is working on it. We've done this in lots of places. For example with the Calendar application, the Photo Album application (retired before we had the gallery macro, which isn't exactly similar) and on several others plugins too. And we didn't have replacements for those. It's a better rule than "keep until replace" because we want to increase XWiki's quality. If a domain has not been worked on for a long time, keeping it won't make it better. For that we need to find a committer who can be active on the feature and make that part of the roadmap. And again, the user would still be able to install it, and if some committer becomes active again on the topic we can revive it. Thanks -Vincent
Now if anyone is really using it, tell us what you do that is not covered by the new query manager. This could change my vote.
Right now the key functions are:
- the XWikiQuery class - QueryPlugin.makeQuery - XWiki.createQueryFromRequest - XWiki.displaySearch - XWiki.displaySearchColumns - XWiki.displaySearchOrder - and code in each XWiki Field class
less important code is:
- XWiki.search(XWikiQuery) - XWiki.searchAsTable(XWikiQuery)
Ludovic
2012/11/16 Thomas Mortagne <[email protected]>
On Fri, Nov 16, 2012 at 3:28 PM, Ludovic Dubost <[email protected]> wrote:
Can you point to the code of the old query plugin. I'm probably -1 because it contains some code that is usefull to generate Search UIs. This code should be moved to the new query component before the plugin is removed
https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik...
The whole point of moving something to legacy is that it's not used
anymore
and we provide alternative for it, if there is missing feature in the query module it should listed and added.
Ludovic
2012/11/16 Eduard Moraru <[email protected]>
+1
Thanks, Eduard
On Fri, Nov 16, 2012 at 3:02 PM, Thomas Mortagne <[email protected]>wrote:
It is.
This plugin is deprecated since a very long time. Look at
http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Modulefor
informations about the "new" one (which exists since 1.6).
On Fri, Nov 16, 2012 at 12:57 PM, crocket <[email protected]
wrote:
> What is the old query plugin? I hope it is not $xwiki.query. > > > On Fri, Nov 16, 2012 at 7:32 PM, Thomas Mortagne > <[email protected]>wrote: > >> Hi devs, >> >> Following the discussion on http://markmail.org/message/uck6w56gqus2mxswI >> would like to extract the query plugin from xwiki-platform-legacy-oldcore >> and move it to retired repository. >> >> The good things is that we will get rid of 3 jars in standard
XE by
doing >> this. >> >> I plan to do it in 4.4M1. >> >> WDYT ? >> >> Here is my +1 >> -- >> Thomas Mortagne >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Envoyé de mon iPad Le 17 nov. 2012 à 18:05, Vincent Massol <[email protected]> a écrit :
On Nov 17, 2012, at 1:35 PM, Denis Gervalle <[email protected]> wrote:
On Sat, Nov 17, 2012 at 10:46 AM, Ludovic Dubost <[email protected]> wrote:
Hi,
The reality right now is that there is no alternative to this code that has been moved to legacy, at least for part of it.
Let me explain a bit what some of this code is doing.
- it allows to create a java object XWikiQuery which represents an XWiki Query in Java as a structured object per field. This object stores criterias - the XWiki Core itself provides a function to display a search field for each field of an XWiki class (displaySearch) and a function that allows to retrieve the content of search a search field into an XWikiQuery object, as well as a function to transform the part concerning the field in the XWikiQuery object into an XWQL statement portion
Only really works if that very old patch is applied: http://jira.xwiki.org/browse/XWIKI-4585
- some functions in XWiki.java (moved to aspects in legacy) also allow to generate a field to choose the columns and the sort fields for a query - the query plugin allows to transform the XWikiQuery object into an XWQL statement including the sort fields - a function in XWiki.java allows in one call to read the data from $request, create the XWikiQuery object, transform it in XWQL, run the query and display the results as an HTML table - another function allows just to run the query and velocity code can present the results just the way you decide
The end results is a system to build query interfaces dynamically.
We haven't used this code because nobody has been trained on it. But still
It is being used in only one of our project. The reason is that the experience was not good enough to reuse it. This was a really great feature, but due to the issues and so unexpected limitation (do not ask, I do not remember) if have choosen to leave it alone.
it's very powerful code, and I'd hate to see it go away without a replacement. Currently it's not that complex to keep it. Most of the code is in the XWiki fields anyway. The code in XWikiQuery and in QueryPlugin is not that complicated as it's just looping over the fields.
On the long run this code has even more capabilities, like being able to run query aggregates in addition to just listing XWiki documents. This could allow to do counting and summing using a UI and even generate a graph out of the result using the Graph Plugin.
I really agree that we should plan for similar feature, using the new model, and the new component.
Once you activate the QueryPlugin in xwiki.cfg this code still works.
I would not be so sure of that since almost nobody really use the query plugin that way, or my patch has more success than I thought.
It would be great if somebody from the active committers looked at it and we could work together to see where this code should be headed. I'm available to help understand the code.
If I had seen it so valuable after our first try, I would have do so since long. Moving the plugin to legacy does not means that we loose it. IMO, keeping this plugin currently cause confusion with the new query manager, which is worse compare to what it really provide. This is why I am +1.
Now I do agree that the idea should not be lost and that we should plane a replacement for it once the new model is ready. Compare to the general rule which is to keep until we replace, I think it does not apply here, since almost nobody use the part not replaced by the new query manager (else we would have received more complains about it not working due to XWIKI-4585 and more)
BTW "keep until replace" is not a current rule of the xwiki project. Right now the practice that we have followed instead is: retire/deprecate when quality is not high enough and nobody is working on it.
We've done this in lots of places. For example with the Calendar application, the Photo Album application (retired before we had the gallery macro, which isn't exactly similar) and on several others plugins too. And we didn't have replacements for those.
It's a better rule than "keep until replace" because we want to increase XWiki's quality.
If a domain has not been worked on for a long time, keeping it won't make it better. For that we need to find a committer who can be active on the feature and make that part of the roadmap.
And again, the user would still be able to install it, and if some committer becomes active again on the topic we can revive it.
This is not the case with this code since there are aspects extending them XWiki core classes. Unless there are ways to try it and improve it this type of stuff will be lost. As I said this has potential if done right, this is why core committed help to give feedback about how to integrate it with the new APIs would be useful Ludovic
Thanks -Vincent
Now if anyone is really using it, tell us what you do that is not covered by the new query manager. This could change my vote.
Right now the key functions are:
- the XWikiQuery class - QueryPlugin.makeQuery - XWiki.createQueryFromRequest - XWiki.displaySearch - XWiki.displaySearchColumns - XWiki.displaySearchOrder - and code in each XWiki Field class
less important code is:
- XWiki.search(XWikiQuery) - XWiki.searchAsTable(XWikiQuery)
Ludovic
2012/11/16 Thomas Mortagne <[email protected]>
On Fri, Nov 16, 2012 at 3:28 PM, Ludovic Dubost <[email protected]> wrote:
Can you point to the code of the old query plugin. I'm probably -1 because it contains some code that is usefull to generate Search UIs. This code should be moved to the new query component before the plugin is removed
https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik...
The whole point of moving something to legacy is that it's not used
anymore
and we provide alternative for it, if there is missing feature in the query module it should listed and added.
Ludovic
2012/11/16 Eduard Moraru <[email protected]>
+1
Thanks, Eduard
On Fri, Nov 16, 2012 at 3:02 PM, Thomas Mortagne <[email protected]>wrote:
> It is. > > This plugin is deprecated since a very long time. Look at > http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Modulefor > informations about the "new" one (which exists since 1.6). > > On Fri, Nov 16, 2012 at 12:57 PM, crocket <[email protected]
wrote: > >> What is the old query plugin? I hope it is not $xwiki.query. >> >> >> On Fri, Nov 16, 2012 at 7:32 PM, Thomas Mortagne >> <[email protected]>wrote: >> >>> Hi devs, >>> >>> Following the discussion on > http://markmail.org/message/uck6w56gqus2mxswI >>> would like to extract the query plugin from > xwiki-platform-legacy-oldcore >>> and move it to retired repository. >>> >>> The good things is that we will get rid of 3 jars in standard XE by > doing >>> this. >>> >>> I plan to do it in 4.4M1. >>> >>> WDYT ? >>> >>> Here is my +1 >>> -- >>> Thomas Mortagne >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, I've looked a bit more about what has been moved to aspects and it is not only the plugin but all the displaySearch functions that were added to the XWiki Core objects and classes. I cannot +1 the removal of all displaySearch functions. There is a lot of work on this code to generate search forms for each fields. I can accept that we remove the QueryPlugin itself but I believe we should keep: - the XWikiCriteria class - the XWikiQuery class - the code in the XWiki objects and fields displaySearch is a function that each property needs to define. The rest of the code in the XWiki class or the QueryPlugin itself can be removed as we can reimplement this easily in a groovy class or in some other component. But the code in the XWiki fields cannot be implement anywhere but in these classes. The XWikiQuery or XWikiCriteria classes can be renamed if there is a confusion but they are needed to represent a Query object which can be passed to fields to display the search form. I'm -1 on the removal of this code and believe it should be move backed from aspect to real code in the core. Ludovic 2012/11/17 [email protected] <[email protected]>
Envoyé de mon iPad
Le 17 nov. 2012 à 18:05, Vincent Massol <[email protected]> a écrit :
On Nov 17, 2012, at 1:35 PM, Denis Gervalle <[email protected]> wrote:
On Sat, Nov 17, 2012 at 10:46 AM, Ludovic Dubost <[email protected]>
wrote:
Hi,
The reality right now is that there is no alternative to this code
that has
been moved to legacy, at least for part of it.
Let me explain a bit what some of this code is doing.
- it allows to create a java object XWikiQuery which represents an XWiki Query in Java as a structured object per field. This object stores criterias - the XWiki Core itself provides a function to display a search field for each field of an XWiki class (displaySearch) and a function that allows to retrieve the content of search a search field into an XWikiQuery object, as well as a function to transform the part concerning the field in the XWikiQuery object into an XWQL statement portion
Only really works if that very old patch is applied: http://jira.xwiki.org/browse/XWIKI-4585
- some functions in XWiki.java (moved to aspects in legacy) also allow to generate a field to choose the columns and the sort fields for a query - the query plugin allows to transform the XWikiQuery object into an XWQL statement including the sort fields - a function in XWiki.java allows in one call to read the data from $request, create the XWikiQuery object, transform it in XWQL, run the query and display the results as an HTML table - another function allows just to run the query and velocity code can present the results just the way you decide
The end results is a system to build query interfaces dynamically.
We haven't used this code because nobody has been trained on it. But still
It is being used in only one of our project. The reason is that the experience was not good enough to reuse it. This was a really great feature, but due to the issues and so unexpected limitation (do not ask, I do not remember) if have choosen to leave it alone.
it's very powerful code, and I'd hate to see it go away without a replacement. Currently it's not that complex to keep it. Most of the code is in the XWiki fields anyway. The code in XWikiQuery and in QueryPlugin is not that complicated as it's just looping over the fields.
On the long run this code has even more capabilities, like being able to run query aggregates in addition to just listing XWiki documents. This could allow to do counting and summing using a UI and even generate a graph out of the result using the Graph Plugin.
I really agree that we should plan for similar feature, using the new model, and the new component.
Once you activate the QueryPlugin in xwiki.cfg this code still works.
I would not be so sure of that since almost nobody really use the query plugin that way, or my patch has more success than I thought.
It would be great if somebody from the active committers looked at it and we could work together to see where this code should be headed. I'm available to help understand the code.
If I had seen it so valuable after our first try, I would have do so since long. Moving the plugin to legacy does not means that we loose it. IMO, keeping this plugin currently cause confusion with the new query manager, which is worse compare to what it really provide. This is why I am +1.
Now I do agree that the idea should not be lost and that we should plane a replacement for it once the new model is ready. Compare to the general rule which is to keep until we replace, I think it does not apply here, since almost nobody use the part not replaced by the new query manager (else we would have received more complains about it not working due to XWIKI-4585 and more)
BTW "keep until replace" is not a current rule of the xwiki project. Right now the practice that we have followed instead is: retire/deprecate when quality is not high enough and nobody is working on it.
We've done this in lots of places. For example with the Calendar application, the Photo Album application (retired before we had the gallery macro, which isn't exactly similar) and on several others plugins too. And we didn't have replacements for those.
It's a better rule than "keep until replace" because we want to increase XWiki's quality.
If a domain has not been worked on for a long time, keeping it won't make it better. For that we need to find a committer who can be active on the feature and make that part of the roadmap.
And again, the user would still be able to install it, and if some committer becomes active again on the topic we can revive it.
This is not the case with this code since there are aspects extending them XWiki core classes. Unless there are ways to try it and improve it this type of stuff will be lost. As I said this has potential if done right, this is why core committed help to give feedback about how to integrate it with the new APIs would be useful
Ludovic
Thanks -Vincent
Now if anyone is really using it, tell us what you do that is not covered by the new query manager. This could change my vote.
Right now the key functions are:
- the XWikiQuery class - QueryPlugin.makeQuery - XWiki.createQueryFromRequest - XWiki.displaySearch - XWiki.displaySearchColumns - XWiki.displaySearchOrder - and code in each XWiki Field class
less important code is:
- XWiki.search(XWikiQuery) - XWiki.searchAsTable(XWikiQuery)
Ludovic
2012/11/16 Thomas Mortagne <[email protected]>
On Fri, Nov 16, 2012 at 3:28 PM, Ludovic Dubost <[email protected]> wrote:
Can you point to the code of the old query plugin. I'm probably -1 because it contains some code that is usefull to generate Search UIs. This code should be moved to the new query component before the plugin is removed
https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik...
The whole point of moving something to legacy is that it's not used
anymore
and we provide alternative for it, if there is missing feature in the query module it should listed and added.
Ludovic
2012/11/16 Eduard Moraru <[email protected]>
> +1 > > Thanks, > Eduard > > > On Fri, Nov 16, 2012 at 3:02 PM, Thomas Mortagne > <[email protected]>wrote: > >> It is. >> >> This plugin is deprecated since a very long time. Look at >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Modulefor >> informations about the "new" one (which exists since 1.6). >> >> On Fri, Nov 16, 2012 at 12:57 PM, crocket <[email protected]
> wrote: >> >>> What is the old query plugin? I hope it is not $xwiki.query. >>> >>> >>> On Fri, Nov 16, 2012 at 7:32 PM, Thomas Mortagne >>> <[email protected]>wrote: >>> >>>> Hi devs, >>>> >>>> Following the discussion on >> http://markmail.org/message/uck6w56gqus2mxswI >>>> would like to extract the query plugin from >> xwiki-platform-legacy-oldcore >>>> and move it to retired repository. >>>> >>>> The good things is that we will get rid of 3 jars in standard XE by >> doing >>>> this. >>>> >>>> I plan to do it in 4.4M1. >>>> >>>> WDYT ? >>>> >>>> Here is my +1 >>>> -- >>>> Thomas Mortagne >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> >> >> -- >> Thomas Mortagne >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
On Mon, Nov 19, 2012 at 1:47 PM, Ludovic Dubost <[email protected]> wrote:
Hi,
I've looked a bit more about what has been moved to aspects and it is not only the plugin but all the displaySearch functions that were added to the XWiki Core objects and classes.
I cannot +1 the removal of all displaySearch functions. There is a lot of work on this code to generate search forms for each fields.
I can accept that we remove the QueryPlugin itself but I believe we should keep:
- the XWikiCriteria class - the XWikiQuery class - the code in the XWiki objects and fields
displaySearch is a function that each property needs to define.
I don't fully agree. I recently (4.3M2) moved all the "displayer" code (view and edit) from DateClass, UsersClass and GroupsClass to default custom displayers implemented using Velocity templates (displayer_*.vm) because I don't think we should output HTML code directly from Java. We can keep some default implementation in PropertyClass but I think for concrete property types we should move the displayer code to Velocity. Thanks, Marius
The rest of the code in the XWiki class or the QueryPlugin itself can be removed as we can reimplement this easily in a groovy class or in some other component. But the code in the XWiki fields cannot be implement anywhere but in these classes.
The XWikiQuery or XWikiCriteria classes can be renamed if there is a confusion but they are needed to represent a Query object which can be passed to fields to display the search form.
I'm -1 on the removal of this code and believe it should be move backed from aspect to real code in the core.
Ludovic
2012/11/17 [email protected] <[email protected]>
Envoyé de mon iPad
Le 17 nov. 2012 à 18:05, Vincent Massol <[email protected]> a écrit :
On Nov 17, 2012, at 1:35 PM, Denis Gervalle <[email protected]> wrote:
On Sat, Nov 17, 2012 at 10:46 AM, Ludovic Dubost <[email protected]>
wrote:
Hi,
The reality right now is that there is no alternative to this code
that has
been moved to legacy, at least for part of it.
Let me explain a bit what some of this code is doing.
- it allows to create a java object XWikiQuery which represents an XWiki Query in Java as a structured object per field. This object stores criterias - the XWiki Core itself provides a function to display a search field for each field of an XWiki class (displaySearch) and a function that allows to retrieve the content of search a search field into an XWikiQuery object, as well as a function to transform the part concerning the field in the XWikiQuery object into an XWQL statement portion
Only really works if that very old patch is applied: http://jira.xwiki.org/browse/XWIKI-4585
- some functions in XWiki.java (moved to aspects in legacy) also allow to generate a field to choose the columns and the sort fields for a query - the query plugin allows to transform the XWikiQuery object into an XWQL statement including the sort fields - a function in XWiki.java allows in one call to read the data from $request, create the XWikiQuery object, transform it in XWQL, run the query and display the results as an HTML table - another function allows just to run the query and velocity code can present the results just the way you decide
The end results is a system to build query interfaces dynamically.
We haven't used this code because nobody has been trained on it. But still
It is being used in only one of our project. The reason is that the experience was not good enough to reuse it. This was a really great feature, but due to the issues and so unexpected limitation (do not ask, I do not remember) if have choosen to leave it alone.
it's very powerful code, and I'd hate to see it go away without a replacement. Currently it's not that complex to keep it. Most of the code is in the XWiki fields anyway. The code in XWikiQuery and in QueryPlugin is not that complicated as it's just looping over the fields.
On the long run this code has even more capabilities, like being able to run query aggregates in addition to just listing XWiki documents. This could allow to do counting and summing using a UI and even generate a graph out of the result using the Graph Plugin.
I really agree that we should plan for similar feature, using the new model, and the new component.
Once you activate the QueryPlugin in xwiki.cfg this code still works.
I would not be so sure of that since almost nobody really use the query plugin that way, or my patch has more success than I thought.
It would be great if somebody from the active committers looked at it and we could work together to see where this code should be headed. I'm available to help understand the code.
If I had seen it so valuable after our first try, I would have do so since long. Moving the plugin to legacy does not means that we loose it. IMO, keeping this plugin currently cause confusion with the new query manager, which is worse compare to what it really provide. This is why I am +1.
Now I do agree that the idea should not be lost and that we should plane a replacement for it once the new model is ready. Compare to the general rule which is to keep until we replace, I think it does not apply here, since almost nobody use the part not replaced by the new query manager (else we would have received more complains about it not working due to XWIKI-4585 and more)
BTW "keep until replace" is not a current rule of the xwiki project. Right now the practice that we have followed instead is: retire/deprecate when quality is not high enough and nobody is working on it.
We've done this in lots of places. For example with the Calendar application, the Photo Album application (retired before we had the gallery macro, which isn't exactly similar) and on several others plugins too. And we didn't have replacements for those.
It's a better rule than "keep until replace" because we want to increase XWiki's quality.
If a domain has not been worked on for a long time, keeping it won't make it better. For that we need to find a committer who can be active on the feature and make that part of the roadmap.
And again, the user would still be able to install it, and if some committer becomes active again on the topic we can revive it.
This is not the case with this code since there are aspects extending them XWiki core classes. Unless there are ways to try it and improve it this type of stuff will be lost. As I said this has potential if done right, this is why core committed help to give feedback about how to integrate it with the new APIs would be useful
Ludovic
Thanks -Vincent
Now if anyone is really using it, tell us what you do that is not covered by the new query manager. This could change my vote.
Right now the key functions are:
- the XWikiQuery class - QueryPlugin.makeQuery - XWiki.createQueryFromRequest - XWiki.displaySearch - XWiki.displaySearchColumns - XWiki.displaySearchOrder - and code in each XWiki Field class
less important code is:
- XWiki.search(XWikiQuery) - XWiki.searchAsTable(XWikiQuery)
Ludovic
2012/11/16 Thomas Mortagne <[email protected]>
On Fri, Nov 16, 2012 at 3:28 PM, Ludovic Dubost <[email protected]> wrote:
> Can you point to the code of the old query plugin. I'm probably -1 because > it contains some code that is usefull to generate Search UIs. > This code should be moved to the new query component before the plugin is > removed >
https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik...
The whole point of moving something to legacy is that it's not used
anymore
and we provide alternative for it, if there is missing feature in the query module it should listed and added.
> Ludovic > > > 2012/11/16 Eduard Moraru <[email protected]> > >> +1 >> >> Thanks, >> Eduard >> >> >> On Fri, Nov 16, 2012 at 3:02 PM, Thomas Mortagne >> <[email protected]>wrote: >> >>> It is. >>> >>> This plugin is deprecated since a very long time. Look at >>> http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Modulefor >>> informations about the "new" one (which exists since 1.6). >>> >>> On Fri, Nov 16, 2012 at 12:57 PM, crocket <[email protected]
>> wrote: >>> >>>> What is the old query plugin? I hope it is not $xwiki.query. >>>> >>>> >>>> On Fri, Nov 16, 2012 at 7:32 PM, Thomas Mortagne >>>> <[email protected]>wrote: >>>> >>>>> Hi devs, >>>>> >>>>> Following the discussion on >>> http://markmail.org/message/uck6w56gqus2mxswI >>>>> would like to extract the query plugin from >>> xwiki-platform-legacy-oldcore >>>>> and move it to retired repository. >>>>> >>>>> The good things is that we will get rid of 3 jars in standard XE by >>> doing >>>>> this. >>>>> >>>>> I plan to do it in 4.4M1. >>>>> >>>>> WDYT ? >>>>> >>>>> Here is my +1 >>>>> -- >>>>> Thomas Mortagne >>>>> _______________________________________________ >>>>> devs mailing list >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>> >>> >>> >>> -- >>> Thomas Mortagne >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Ludovic Dubost > Founder and CEO > Blog: http://blog.ludovic.org/ > XWiki: http://www.xwiki.com > Skype: ldubost GTalk: ldubost > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Maybe we should move new code, but there is existing code here that we need to keep In any case even if there is code in velocity templates, there needs to be a default displayer in case there is no velocity template. Ludovic 2012/11/19 Marius Dumitru Florea <[email protected]>
On Mon, Nov 19, 2012 at 1:47 PM, Ludovic Dubost <[email protected]> wrote:
Hi,
I've looked a bit more about what has been moved to aspects and it is not only the plugin but all the displaySearch functions that were added to the XWiki Core objects and classes.
I cannot +1 the removal of all displaySearch functions. There is a lot of work on this code to generate search forms for each fields.
I can accept that we remove the QueryPlugin itself but I believe we should keep:
- the XWikiCriteria class - the XWikiQuery class - the code in the XWiki objects and fields
displaySearch is a function that each property needs to define.
I don't fully agree. I recently (4.3M2) moved all the "displayer" code (view and edit) from DateClass, UsersClass and GroupsClass to default custom displayers implemented using Velocity templates (displayer_*.vm) because I don't think we should output HTML code directly from Java. We can keep some default implementation in PropertyClass but I think for concrete property types we should move the displayer code to Velocity.
Thanks, Marius
The rest of the code in the XWiki class or the QueryPlugin itself can be removed as we can reimplement this easily in a groovy class or in some other component. But the code in the XWiki fields cannot be implement anywhere but in these classes.
The XWikiQuery or XWikiCriteria classes can be renamed if there is a confusion but they are needed to represent a Query object which can be passed to fields to display the search form.
I'm -1 on the removal of this code and believe it should be move backed from aspect to real code in the core.
Ludovic
2012/11/17 [email protected] <[email protected]>
Envoyé de mon iPad
Le 17 nov. 2012 à 18:05, Vincent Massol <[email protected]> a écrit :
On Nov 17, 2012, at 1:35 PM, Denis Gervalle <[email protected]> wrote:
On Sat, Nov 17, 2012 at 10:46 AM, Ludovic Dubost <[email protected]>
wrote:
Hi,
The reality right now is that there is no alternative to this code
that has
been moved to legacy, at least for part of it.
Let me explain a bit what some of this code is doing.
- it allows to create a java object XWikiQuery which represents an XWiki Query in Java as a structured object per field. This object stores criterias - the XWiki Core itself provides a function to display a search
field
for
each field of an XWiki class (displaySearch) and a function that allows to retrieve the content of search a search field into an XWikiQuery object, as well as a function to transform the part concerning the field in the XWikiQuery object into an XWQL statement portion
Only really works if that very old patch is applied: http://jira.xwiki.org/browse/XWIKI-4585
- some functions in XWiki.java (moved to aspects in legacy) also allow to generate a field to choose the columns and the sort fields for a query - the query plugin allows to transform the XWikiQuery object into an XWQL statement including the sort fields - a function in XWiki.java allows in one call to read the data from $request, create the XWikiQuery object, transform it in XWQL, run the query and display the results as an HTML table - another function allows just to run the query and velocity code can present the results just the way you decide
The end results is a system to build query interfaces dynamically.
We haven't used this code because nobody has been trained on it. But still
It is being used in only one of our project. The reason is that the experience was not good enough to reuse it. This was a really great feature, but due to the issues and so unexpected limitation (do not ask, I do not remember) if have choosen to leave it alone.
it's very powerful code, and I'd hate to see it go away without a replacement. Currently it's not that complex to keep it. Most of the code is in the XWiki fields anyway. The code in XWikiQuery and in QueryPlugin is not that complicated as it's just looping over the fields.
On the long run this code has even more capabilities, like being able to run query aggregates in addition to just listing XWiki documents. This could allow to do counting and summing using a UI and even generate a graph out of the result using the Graph Plugin.
I really agree that we should plan for similar feature, using the new model, and the new component.
Once you activate the QueryPlugin in xwiki.cfg this code still
works.
I would not be so sure of that since almost nobody really use the query plugin that way, or my patch has more success than I thought.
It would be great if somebody from the active committers looked at it and we could work together to see where this code should be headed. I'm available to help understand the code.
If I had seen it so valuable after our first try, I would have do so since long. Moving the plugin to legacy does not means that we loose it. IMO, keeping this plugin currently cause confusion with the new query manager, which is worse compare to what it really provide. This is why I am +1.
Now I do agree that the idea should not be lost and that we should plane a replacement for it once the new model is ready. Compare to the general rule which is to keep until we replace, I think it does not apply here, since almost nobody use the part not replaced by the new query manager (else we would have received more complains about it not working due to XWIKI-4585 and more)
BTW "keep until replace" is not a current rule of the xwiki project. Right now the practice that we have followed instead is: retire/deprecate when quality is not high enough and nobody is working on it.
We've done this in lots of places. For example with the Calendar application, the Photo Album application (retired before we had the gallery macro, which isn't exactly similar) and on several others plugins too. And we didn't have replacements for those.
It's a better rule than "keep until replace" because we want to increase XWiki's quality.
If a domain has not been worked on for a long time, keeping it won't make it better. For that we need to find a committer who can be active on the feature and make that part of the roadmap.
And again, the user would still be able to install it, and if some committer becomes active again on the topic we can revive it.
This is not the case with this code since there are aspects extending them XWiki core classes. Unless there are ways to try it and improve it this type of stuff will be lost. As I said this has potential if done right, this is why core committed help to give feedback about how to integrate it with the new APIs would be useful
Ludovic
Thanks -Vincent
Now if anyone is really using it, tell us what you do that is not covered by the new query manager. This could change my vote.
Right now the key functions are:
- the XWikiQuery class - QueryPlugin.makeQuery - XWiki.createQueryFromRequest - XWiki.displaySearch - XWiki.displaySearchColumns - XWiki.displaySearchOrder - and code in each XWiki Field class
less important code is:
- XWiki.search(XWikiQuery) - XWiki.searchAsTable(XWikiQuery)
Ludovic
2012/11/16 Thomas Mortagne <[email protected]>
> On Fri, Nov 16, 2012 at 3:28 PM, Ludovic Dubost <[email protected]
wrote: > >> Can you point to the code of the old query plugin. I'm probably -1 > because >> it contains some code that is usefull to generate Search UIs. >> This code should be moved to the new query component before the plugin is >> removed >> > > >
https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwik...
> > The whole point of moving something to legacy is that it's not used anymore > and we provide alternative for it, if there is missing feature in the query > module it should listed and added. > > >> Ludovic >> >> >> 2012/11/16 Eduard Moraru <[email protected]> >> >>> +1 >>> >>> Thanks, >>> Eduard >>> >>> >>> On Fri, Nov 16, 2012 at 3:02 PM, Thomas Mortagne >>> <[email protected]>wrote: >>> >>>> It is. >>>> >>>> This plugin is deprecated since a very long time. Look at >>>>
http://extensions.xwiki.org/xwiki/bin/view/Extension/Query+Modulefor
>>>> informations about the "new" one (which exists since 1.6). >>>> >>>> On Fri, Nov 16, 2012 at 12:57 PM, crocket < [email protected] > >>> wrote: >>>> >>>>> What is the old query plugin? I hope it is not $xwiki.query. >>>>> >>>>> >>>>> On Fri, Nov 16, 2012 at 7:32 PM, Thomas Mortagne >>>>> <[email protected]>wrote: >>>>> >>>>>> Hi devs, >>>>>> >>>>>> Following the discussion on >>>> http://markmail.org/message/uck6w56gqus2mxswI >>>>>> would like to extract the query plugin from >>>> xwiki-platform-legacy-oldcore >>>>>> and move it to retired repository. >>>>>> >>>>>> The good things is that we will get rid of 3 jars in standard XE > by >>>> doing >>>>>> this. >>>>>> >>>>>> I plan to do it in 4.4M1. >>>>>> >>>>>> WDYT ? >>>>>> >>>>>> Here is my +1 >>>>>> -- >>>>>> Thomas Mortagne >>>>>> _______________________________________________ >>>>>> devs mailing list >>>>>> [email protected] >>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>>> >>>>> _______________________________________________ >>>>> devs mailing list >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>> >>>> >>>> >>>> -- >>>> Thomas Mortagne >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> >> >> -- >> Ludovic Dubost >> Founder and CEO >> Blog: http://blog.ludovic.org/ >> XWiki: http://www.xwiki.com >> Skype: ldubost GTalk: ldubost >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
+0 Thanks, Marius On Fri, Nov 16, 2012 at 12:32 PM, Thomas Mortagne <[email protected]> wrote:
Hi devs,
Following the discussion on http://markmail.org/message/uck6w56gqus2mxsw I would like to extract the query plugin from xwiki-platform-legacy-oldcore and move it to retired repository.
The good things is that we will get rid of 3 jars in standard XE by doing this.
I plan to do it in 4.4M1.
WDYT ?
Here is my +1 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Thomas, On Nov 16, 2012, at 11:32 AM, Thomas Mortagne <[email protected]> wrote:
Hi devs,
Following the discussion on http://markmail.org/message/uck6w56gqus2mxsw I would like to extract the query plugin from xwiki-platform-legacy-oldcore and move it to retired repository.
Normally it's our strategy to keep forever what's in legacy. As I understand it, your use case is to reduce the size of the WAR by removing 3 JARs brought by this plugin. Is it just a problem of size or is there some other reason? Now I can see 2 choices for us: * Solution 1: Keep the plugin in legacy but extract it out of legacy-oldcore into legacy-query-plugin and don't bundle it by default in XE * Solution 2: Move it to retire but create an extension entry on e.x.o. so that users who need it can still install it easily (IMO it doesn't have to be installable through the EM, keeping it as a plugin is fine) Now it would be nice to have a special release notes area in the Distribution Wizard where we could put some release-related information. For example when someone upgrade to 4.4 and if we chose to retire the plugin we would put something like: "The old Query plugin has been retired from the NN distribution you've installed and is no longer actively maintained. However if you're using it in some wiki pages, you can still install it by going to XXX.". This information could be taken from some README file that we provide at the root of the WAR for example. We could use this area whenever we break user-related backward compatibility. WDYT? Now personally I'm ok with your proposal Thomas (+1) as long as: * The user knows about it. Release notes is one solution but the solution I indicated above goes even further and would be a nice addition IMO. * There's an easy way for him/her to install it Thanks -Vincent
The good things is that we will get rid of 3 jars in standard XE by doing this.
I plan to do it in 4.4M1.
WDYT ?
Here is my +1 -- Thomas Mortagne
On Sat, Nov 17, 2012 at 9:48 AM, Vincent Massol <[email protected]> wrote:
Hi Thomas,
On Nov 16, 2012, at 11:32 AM, Thomas Mortagne <[email protected]> wrote:
Hi devs,
Following the discussion on http://markmail.org/message/uck6w56gqus2mxswI would like to extract the query plugin from xwiki-platform-legacy-oldcore and move it to retired repository.
Normally it's our strategy to keep forever what's in legacy. As I understand it, your use case is to reduce the size of the WAR by removing 3 JARs brought by this plugin. Is it just a problem of size or is there some other reason?
Now I can see 2 choices for us:
* Solution 1: Keep the plugin in legacy but extract it out of legacy-oldcore into legacy-query-plugin and don't bundle it by default in XE * Solution 2: Move it to retire but create an extension entry on e.x.o. so that users who need it can still install it easily (IMO it doesn't have to be installable through the EM, keeping it as a plugin is fine)
Now it would be nice to have a special release notes area in the Distribution Wizard where we could put some release-related information. For example when someone upgrade to 4.4 and if we chose to retire the plugin we would put something like: "The old Query plugin has been retired from the NN distribution you've installed and is no longer actively maintained. However if you're using it in some wiki pages, you can still install it by going to XXX.". This information could be taken from some README file that we provide at the root of the WAR for example.
We could use this area whenever we break user-related backward compatibility.
WDYT?
Now personally I'm ok with your proposal Thomas (+1) as long as: * The user knows about it. Release notes is one solution but the solution I indicated above goes even further and would be a nice addition IMO. * There's an easy way for him/her to install it
Why not for usertools and chart plugins that you moved to retired ?
Thanks -Vincent
The good things is that we will get rid of 3 jars in standard XE by doing this.
I plan to do it in 4.4M1.
WDYT ?
Here is my +1 -- Thomas Mortagne
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Nov 17, 2012, at 9:20 PM, Thomas Mortagne <[email protected]> wrote:
On Sat, Nov 17, 2012 at 9:48 AM, Vincent Massol <[email protected]> wrote:
Hi Thomas,
On Nov 16, 2012, at 11:32 AM, Thomas Mortagne <[email protected]> wrote:
Hi devs,
Following the discussion on http://markmail.org/message/uck6w56gqus2mxswI would like to extract the query plugin from xwiki-platform-legacy-oldcore and move it to retired repository.
Normally it's our strategy to keep forever what's in legacy. As I understand it, your use case is to reduce the size of the WAR by removing 3 JARs brought by this plugin. Is it just a problem of size or is there some other reason?
Now I can see 2 choices for us:
* Solution 1: Keep the plugin in legacy but extract it out of legacy-oldcore into legacy-query-plugin and don't bundle it by default in XE * Solution 2: Move it to retire but create an extension entry on e.x.o. so that users who need it can still install it easily (IMO it doesn't have to be installable through the EM, keeping it as a plugin is fine)
Now it would be nice to have a special release notes area in the Distribution Wizard where we could put some release-related information. For example when someone upgrade to 4.4 and if we chose to retire the plugin we would put something like: "The old Query plugin has been retired from the NN distribution you've installed and is no longer actively maintained. However if you're using it in some wiki pages, you can still install it by going to XXX.". This information could be taken from some README file that we provide at the root of the WAR for example.
We could use this area whenever we break user-related backward compatibility.
WDYT?
Now personally I'm ok with your proposal Thomas (+1) as long as: * The user knows about it. Release notes is one solution but the solution I indicated above goes even further and would be a nice addition IMO. * There's an easy way for him/her to install it
Why not for usertools and chart plugins that you moved to retired ?
Simply because nobody thought about it… AFAIR I extracted them out of oldcore though. But I didn't think about the idea of the DM message. Thanks -Vincent
Thanks -Vincent
The good things is that we will get rid of 3 jars in standard XE by doing this.
I plan to do it in 4.4M1.
WDYT ?
Here is my +1 -- Thomas Mortagne
On Nov 18, 2012, at 9:47 AM, Vincent Massol <[email protected]> wrote:
On Nov 17, 2012, at 9:20 PM, Thomas Mortagne <[email protected]> wrote:
On Sat, Nov 17, 2012 at 9:48 AM, Vincent Massol <[email protected]> wrote:
Hi Thomas,
On Nov 16, 2012, at 11:32 AM, Thomas Mortagne <[email protected]> wrote:
Hi devs,
Following the discussion on http://markmail.org/message/uck6w56gqus2mxswI would like to extract the query plugin from xwiki-platform-legacy-oldcore and move it to retired repository.
Normally it's our strategy to keep forever what's in legacy. As I understand it, your use case is to reduce the size of the WAR by removing 3 JARs brought by this plugin. Is it just a problem of size or is there some other reason?
Now I can see 2 choices for us:
* Solution 1: Keep the plugin in legacy but extract it out of legacy-oldcore into legacy-query-plugin and don't bundle it by default in XE * Solution 2: Move it to retire but create an extension entry on e.x.o. so that users who need it can still install it easily (IMO it doesn't have to be installable through the EM, keeping it as a plugin is fine)
Now it would be nice to have a special release notes area in the Distribution Wizard where we could put some release-related information. For example when someone upgrade to 4.4 and if we chose to retire the plugin we would put something like: "The old Query plugin has been retired from the NN distribution you've installed and is no longer actively maintained. However if you're using it in some wiki pages, you can still install it by going to XXX.". This information could be taken from some README file that we provide at the root of the WAR for example.
We could use this area whenever we break user-related backward compatibility.
Actually here's a revised proposal on this theme: * Have a Release Notes tab in the DM * Create a Release Notes app for xwiki.org to have a more structured content (one area of information would be retired modules for example) * Have the DM display the Release notes from xwiki.org WDYT? Thanks -Vincent
WDYT?
Now personally I'm ok with your proposal Thomas (+1) as long as: * The user knows about it. Release notes is one solution but the solution I indicated above goes even further and would be a nice addition IMO. * There's an easy way for him/her to install it
Why not for usertools and chart plugins that you moved to retired ?
Simply because nobody thought about it…
AFAIR I extracted them out of oldcore though. But I didn't think about the idea of the DM message.
Thanks -Vincent
Thanks -Vincent
The good things is that we will get rid of 3 jars in standard XE by doing this.
I plan to do it in 4.4M1.
WDYT ?
Here is my +1 -- Thomas Mortagne
participants (9)
-
Andreas Jonsson -
crocket -
Denis Gervalle -
Eduard Moraru -
Ludovic Dubost -
ludovic＠xwiki.com
-
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol