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. > >> 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
