19 Nov
2012
19 Nov
'12
4:10 p.m.
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 <mariusdumitru.florea(a)xwiki.com>
On Mon, Nov 19, 2012 at 1:47 PM, Ludovic Dubost
<ludovic(a)xwiki.com> wrote:
https://github.com/xwiki/xwiki-platform/tree/master/xwiki-platform-core/xwi…
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
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
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 ludovic(a)xwiki.com <ludovic(a)xwiki.com>
>
>
> Envoyé de mon iPad
>
> Le 17 nov. 2012 à 18:05, Vincent Massol <vincent(a)massol.net> a écrit :
>
> >
> > On Nov 17, 2012, at 1:35 PM, Denis Gervalle <dgl(a)softec.lu> wrote:
> >
> >> On Sat, Nov 17, 2012 at 10:46 AM, Ludovic Dubost <ludovic(a)xwiki.com>
> 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
> >>> 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
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> 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 <thomas.mortagne(a)xwiki.com>
>>>
>>>> On Fri, Nov 16, 2012 at 3:28 PM, Ludovic Dubost <ludovic(a)xwiki.com
> >>>>
> >>>> 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 <enygma2002(a)gmail.com>
> >>>>>
> >>>>>> +1
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Eduard
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Nov 16, 2012 at 3:02 PM, Thomas Mortagne
> >>>>>> <thomas.mortagne(a)xwiki.com>wrote;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 <
crockabiscuit(a)gmail.com
>>>
>>>>> 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
>>>>>>> <thomas.mortagne(a)xwiki.com>wrote;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
>>>>>>>> devs(a)xwiki.org
>>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> devs mailing list
>>>>>>> devs(a)xwiki.org
>>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Thomas Mortagne
>>>>>> _______________________________________________
>>>>>> devs mailing list
>>>>>> devs(a)xwiki.org
>>>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>>>
>>>>> _______________________________________________
>>>>> devs mailing list
>>>>> devs(a)xwiki.org
>>>>> 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
>>>> devs(a)xwiki.org
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>>>
>>>
>>>
>>>
>>> --
>>> Thomas Mortagne
>>> _______________________________________________
>>> devs mailing list
>>> devs(a)xwiki.org
>>> 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
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs