On Tue, May 24, 2011 at 20:31, Thomas Mortagne <[email protected]>wrote:
> On Tue, May 24, 2011 at 20:19, Denis Gervalle <[email protected]> wrote: > > On Tue, May 24, 2011 at 18:59, Thomas Mortagne < > [email protected]>wrote: > > > >> On Tue, May 24, 2011 at 17:55, Denis Gervalle <[email protected]> wrote: > >> > On Tue, May 24, 2011 at 17:39, Thomas Mortagne < > >> [email protected]>wrote: > >> > > >> >> On Tue, May 24, 2011 at 17:35, Thomas Mortagne > >> >> <[email protected]> wrote: > >> >> > On Tue, May 24, 2011 at 17:29, Denis Gervalle <[email protected]> > wrote: > >> >> >> On Tue, May 24, 2011 at 16:17, Thomas Mortagne < > >> >> [email protected]>wrote: > >> >> >> > >> >> >>> On Tue, May 24, 2011 at 15:57, Denis Gervalle <[email protected]> > >> 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. > >> >> > >> > > >> > 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 > >> > 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. > >> > > > > 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 ? > > I'm ok with either refactoring them to use query manager behind the > scene (if I don't have to do it ;)) or just deprecate them. Whatever > the solution they should probably be deprecated anyway since they are > supposed to be covered by query manager AFAIK. > What about the default ? wouldn't it be to filter hidden document by the default, since creating XWQL query is public and we want public API to be filtered ? Then the function could be Query#withHiddenDocument(boolean) and require PR to set it true ? Is there any existing usage of Query that should be fix to not became broken by this new behavior ? WDYT ? > > > > > > >> > >> > > >> > > >> >> > >> >> > > >> >> >> 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 > >> >> >>> > [email protected] > >> >> >>> > http://lists.xwiki.org/mailman/listinfo/devs > >> >> >>> > > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> -- > >> >> >>> Thomas Mortagne > >> >> >>> _______________________________________________ > >> >> >>> 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 > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > Thomas Mortagne > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> Thomas Mortagne > >> >> _______________________________________________ > >> >> 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 > >> > > >> > >> > >> > >> -- > >> Thomas Mortagne > >> _______________________________________________ > >> 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 > > > > > > -- > Thomas Mortagne > _______________________________________________ > 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
