Seems to me that there has been an agreement to revert to the old behavior has soon as possible, but I do not see the link with XWiki 3.2.1 release ?
On Mon, Jan 9, 2012 at 17:59, Guillaume Lerouge <[email protected]> wrote: > Hi guys, > > can we please finish and/or close this vote so that Sergiu can act on it > and we can release XE 3.2.1? > > Thanks in advance, > > Guillaume > > On Mon, Oct 10, 2011 at 10:13 AM, Denis Gervalle <[email protected]> wrote: > > > > > > > On Mon, Oct 10, 2011 at 09:31, Thomas Mortagne < > > [email protected]>wrote: > > > > On Fri, Oct 7, 2011 at 12:13 PM, Vincent Massol <[email protected]> > > wrote: > > > > Hi guys, > > > > > > > > Ok here's second version taking into account Denis and Marius > comments: > > > > > > > > * Have a {{display}} macro which is equivalent to context=new and > > > resolve=source (ie links resolved on the reference being displayed) > > > > > > > +1, this is simpler and clearer > > > > > * Have a compatibility mode for the {{include}} macro with the > following > > > behavior: > > > > ** {{include}} in non-compatiiblity mode is equivalent to > > context=current > > > and resolve=current (ie links resolve on the including document) > > > > ** {{include}} in compatiiblity mode is equivalent to context=current > > and > > > resolve=source (the default we have now and which we need to not break > > > people) > > > > > > * We would have a rendering.macro.include.compatibility configuration > > > property > > > > > * We would set that property to true by default for 3.3 to give some > time > > > for people to adjust > > > > * We would set that property to false by default for 3.4 > > > > > > -0, this is for me useless, since I doubt many understand that and have > > notice this change in 3.x. I was unaware myself of this change, and I do > > not > > remember any discussion about it in the past. If you have a ML thread > about > > the rational behind this mistake, I am still interested, but I it could > > have > > been introduce without notice, it could be removed as well. > > At least, this should not be in compatibility mode by default. > > > > > > > So you propose to get back to previous behavior by default, right ? > > > Given the fact that it has been changed very recently maybe we should > > > have the property false right away and say it was a mistake ? > > > > > > > I agree. > > > > > > > > * Deprecate "document" parameter for the include macro and add a new > > > "reference" parameter + a new "type" parameter (I forgot that one in my > > > first email). The "type" parameter represents the Entity Reference > Type. > > > > * Also add a "type" parameter for the display macro (I forgot that > one > > in > > > my first email) > > > > * Have the "type" parameter default to "document". > > > > > > > +1 > > > > > > > I forgot to mention the following point: > > > ** The {{include}} macro has a new "resolve" parameter (the "context" > one > > > is deprecated) which can be "current" or "source". > > > This is needed since there are use cases both resolve=current and > > > resolve=source for the include macro. Once again the context param has > > > nothing to do with how links/images are resolved. And again the writer > > of a > > > page isn't necessarily the same as the person who's going to include > your > > > page. > > > > > > I am still -1 on this last point. First, it is precisely because it is > very > > difficult to understand the differences between the context and the > resolve > > parameter that I am against it. I repeat myself, but not having the same > > behavior between $doc.getURL() and [[ ]] is for me not acceptable, since > > the > > included document author could no more count on the equality of these to > > resolution methods. If I have been aware of that change in 3.x I would > have > > veto it already. > > > > Moreover, if the writer of the included document is the not the writer of > > the including document, he would be better if he could stay in control of > > how links/image are accessed, protecting the way its own document works, > > and > > not leaving this to the including document author. This is why I have > > proposed to move the resolve parameter on individual links, which is more > > flexible and understandable. > > > > Currently, AFAIK, during an {{include}} (without context=new), using > > velocity, the included document do not have an easy access to itself > > (without knowing its own name), but you want this possibility for links ? > > and you want it globally ? This seems to me curious that something > > difficult > > to do by code would be easy by syntax. > > > > If you still want to convince me, please explain why you need $doc and > > relative links to diverge, especially without the included document > author > > to be aware of this. What cannot you do with {{display}} that would be > > possible by {{include resolve=source}}; and that would not be better > served > > by giving the control to the included document author ? > > > > Denis > > > > > > > > > Some additional notes: > > > > * The person writing a page is not necessarily the same as the person > > > writing an include. > > > > * With the new sheet mechanism there are a lot less use cases for the > > > include in compatibility mode. > > > > > > > > Please vote again. > > > > > > > > Here's my +1 > > > > > > +1 (with the previous note) > > > > > > > > > > > Thanks > > > > -Vincent > > > > > > > > On Oct 6, 2011, at 2:58 PM, Vincent Massol wrote: > > > > > > > >> Hi devs, > > > >> > > > >> As you know in XE 3.0 we've changed the behavior for resolving local > > > links/attachments when they're included using the {{include}} macro > > (they're > > > now resolved against the included document instead of the including > > > document). > > > >> > > > >> Now there might be some use cases (pretty rare IMO but they exist) > > where > > > you'd want the links to be resolved against the including document. > > Here's a > > > use case: you have a sheet document that references an image called > > > image.png and you want that the including document provides it (like an > > > Abstract in Java! ;)). > > > >> > > > >> So we've brainstormed with Thomas and here's our proposal: > > > >> > > > >> * Introduce a new {{display reference="…"/}} macro. This macro will > > > *execute* the passed reference in its own context (it'll do what > > {{include > > > context="new"…}} was doing before). It'll be located in the new display > > > module. > > > >> * Deprecate the "context" parameter of the {{include}} macro. The > > reason > > > is that calling with context=new is not an include, it's a display. > > > >> * Add a new "resolve" parameter for the {{include}} macro with > > possible > > > values = "current" | "source", with a default value of "source". > > > resolve=source means that the links/attachments are resolved against > the > > > source (ie the document being included). Using resolve=current means > that > > > you want the links/attachments resolved against the including document. > > > >> > > > >> Pros: > > > >> * Clearly separate the 2 use cases: display and include > > > >> * Make the include macro simple (a single "resolve" parameter) > > > >> * Use the new display module as it should be and start the direction > > of > > > having displayer macros for displaying all types of entities > > > >> > > > >> Note: In the future we'll also want to deprecate the "document" > > > parameter of the include macro in favor of a more generic "reference" > > > parameter, which will allow the macro to include other types of > entities > > > (such as an object property for ex). > > > >> > > > >> WDYT? > > > >> > > > >> Here's my +1 > > > >> > > > >> Thanks > > > >> -Vincent > > > >> > > > > > > > > _______________________________________________ > > > > 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 > > > _______________________________________________ > 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
