24 May
2011
24 May
'11
8:19 p.m.
On Tue, May 24, 2011 at 18:59, Thomas Mortagne <thomas.mortagne(a)xwiki.com>wrote;wrote:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
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
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
On Tue, May 24, 2011 at 17:55, Denis Gervalle
<dgl(a)softec.lu> wrote:
So, you (Thomas and Jerome) would be in favor of reverting to the old
behavior, improving the feature by using a boolean for example, and setting
But to meet the objective of XWIKI-2843, which is to hide hidden document
from all public API (those not requiring PR), this would also means to use
org.xwiki.query.Query in all existing public API, or deprecate all those not
using it ?
On Tue, May 24, 2011 at 17:39, Thomas Mortagne
<
thomas.mortagne(a)xwiki.com>wroteote:
> On Tue, May 24, 2011 at 17:35, Thomas Mortagne
> <thomas.mortagne(a)xwiki.com> wrote:
> > On Tue, May 24, 2011 at 17:29, Denis Gervalle <dgl(a)softec.lu> wrote:
> >> On Tue, May 24, 2011 at 16:17, Thomas Mortagne <
> thomas.mortagne(a)xwiki.com>wroteote:
> >>
> >>> On Tue, May 24, 2011 at 15:57, Denis Gervalle <dgl(a)softec.lu>
wrote:
> >>> > Hi Devs,
> >>> >
> >>> > Anyone of you will surely agree that the hidden document feature
> >>> implemented
> >>> > in the store is very bad.
> >>>
> >>> The way this "feature" is implemented should never have been
accepted,
> >>> it just broke an API for
something that is not really related to
> >>> storage...
> >>>
> >>> See http://jira.xwiki.org/jira/browse/XWIKI-3925 and its
dependencies.
> >>>
> >>> > IMO, it has never been fully implemented, probably in the hope of
a
> >>> better
> >>> > way to go, and it is so for too long. I think it is the time to
take
> some
> >>> > decision about it, or I do not see the direction and I do not
> understand
> >>> > where we want to go ?
> >>> >
> >>> > I see 3 possibilities:
> >>> > 1) we remove it and found other way to solve the problem it
solves,
> >>> which
> >>> > are currently limited to the Blog, ColorThemes and Panels
> applications in
> >>> a
> >>> > standard XE.
> >>>
> >>> +1
> >>>
> >>
> >> Do you means that you are +1 for reverting the code to what it was
> before
> >> that feature, and putting some code in each application using it to
> avoid
> >> the effet of the revert ?
> >>
> >>
> >>>
> >>> > 2) we keep it as it is, since it could be hard to implement
higher
> in
> >>> the
> >>> > current implementation, but then we need to fix the places where
it
> cause
> >>> > issues.
> >>>
> >>> -1, I can see it as a long term solution. It's something to say we
> >>> will fix it latter it's something else to validate it. Adding a
> >>> boolean to searchDocument as indicated in
> >>> http://jira.xwiki.org/jira/browse/XWIKI-3925 would already be a lot
> >>> better than the current situation.
> >>>
> >>> > 3) we implement the feature using another method ?
> >>>
> >>> I don't fully understand what is the difference between 1) and 3).
> >>>
> >>
> >> The difference is that in 3), you propose an alternative solution to
the
> same issue, which is hiding document from public
interface.
"putting some code in each application using it to avoid the effet of
the revertv" is pretty much the same thing as "propose an alternative
solution to the same issue": in both case searchDocument go back to
what is used to be and you need to filter another way
Anyway whatever the real difference between 1) and 3) I think we need
a filtering system and the way it's done now is bad.
that boolean only when we want the filter applied
(for example, in calls
from the public API). Since I completely agree that this should have been
done that way in the first place, I would like to propose that in vote.
is
there any comments from others before I do ?
An idea to avoid duplicating all the searchDocument methods is to add
the hiddent document setup at org.xwiki.query.Query level.
Basically we come back to clean searchDocument implementation in
XWikiHibernateStore and we put the hidden document filter support in
Query interface with a Query#setHiddenFiltered or something like that.
In any case using query manager is supposed to be the proper current
way of dealing with XWiki model so we don't have to support anything
in "old" storage APIs.
>
> >
> >> Maybe, 3) is more like your proposal for 2), while 2) means using
search
> in
> >> place of searchDocument to bypass the filter.
> >>
> >>
> >>>
> >>> >
> >>> > If we choose 1), early in 3.x release is the probably best moment
for
> it,
> >>> > since it is a breakage in compatibility, I am -0 on this however.
> >>> >
> >>> > If we choose 2), we need to make it work properly by fixing places
> where
> >>> we
> >>> > need to include all document, including hidden one. I have some
old
> patch
> >>> to
> >>> > the application-manager to export hidden document (ie: currently
the
> blog
> >>> > application does not export properly), to the skinx plugin that
does
> not
> >>> > apply 'always' skin extensions contained in hidden
document, and
> there is
> >>> > probably other places.
> >>> >
> >>> > If we choose 3) now, what do you proposed to better implement it.
I
> have
> >>> > read some comments that it was a UI level stuff implemented at the
> store
> >>> > level, but I do not see how it could be done better in the current
> >>> > implementation.
> >>> >
> >>> > Moreover, if we keep the feature, I think that it should be
exposed
> >>> somehow
> >>> > to the admins, allowing the creation of hidden document, but also
> listing
> >>> > them, deleting them properly, etc... Concerning the document
provided
>> with
>> > XE, I also wonder what could be the rules for hiding them or not ?
Why
>> not
>> > also hidding stock document in the XWiki space, just keeping users
and
>> some
>> > top level documents ?
>> >
>> > WDYT ?
>> >
>> > --
>> > Denis Gervalle
>> > SOFTEC sa - CEO
>> > eGuilde sarl - CTO
>> > _______________________________________________
>> > 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
>>
>
>
>
> --
> Denis Gervalle
> SOFTEC sa - CEO
> eGuilde sarl - CTO
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs