On Thu, Oct 6, 2011 at 15:38, Vincent Massol <[email protected]> wrote:
> Hi Denis, > > On Oct 6, 2011, at 3:22 PM, Denis Gervalle wrote: > > > On Thu, Oct 6, 2011 at 14:58, Vincent Massol <[email protected]> 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). > >> > > > > I do not remember this change. Does not this depends on the context=new ? > > No. Context = new is only about isolating the execution context. It's not > about deciding against what to resolve the links/attachments > > If you have a link to the previous discussion, it could help. > > Related Issues are: > http://jira.xwiki.org/jira/browse/XWIKI-5902 > http://jira.xwiki.org/jira/browse/XWIKI-5807 > http://jira.xwiki.org/jira/browse/XWIKI-5808 > http://jira.xwiki.org/jira/browse/XWIKI-4802 > http://jira.xwiki.org/jira/browse/XWIKI-6196 > http://jira.xwiki.org/jira/browse/XWIKI-6874 > > I do not see discussion about how relative links has to be resolved their. I do not feel confortable with the facts that based on context=new, $doc.getURL() obviously change its behavior, and that the equivalent XWiki syntax could follow a different path based on resolved=current|source. This seems to me introducing additional complexity, and therefore potential confusion. > >> 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! ;)). > >> > > > > This is not rare, but this could be solved using velocity anyway. > > > > > >> 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. > >> > > > > Does not this new macro exists already in 1.x syntax under name '#Topic' > ? > > Was it a mistake to have not kept this one in 2.x ? > > Probably. > > >> * 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. > >> > > > > Since I have really thought it was depending on the context parameter, > why > > use a new parameter for this ? > > See above. They're 2 separate things. > Why separating them so much ? What are the use cases ? {{display}} replacing context=new sounds good to me since it clarify a parameter that many do not understand. But, the resolve parameter seems to me putting back confusion. {{display}} implies resolve=source why {{include}} does not implies resolve=current ? If you consider all use cases, there will be situation when you want to access both source and current attachment, no ? So the global resolve parameter seems inappropriate IMO, and having the default above could be simpler. If you really want a specific resolution, it should be on a link by link basis. > > >> 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). > >> > > > > Is this reference parameter already support > > No. right now there's only a document parameter supported. > > > , and is this only the > > deprecation for future ? Why not deprecate right now ? > > We would need to agree about it first and it's not the subject of this mail > ;) (let's go step by step!). > Not that I want to mix stuffs, but since {{display}} will replace {{include context=new}}, having the first with a reference parameter only and the second with a document parameter only, is somewhat inconsistant. We should consider either supporting document in {{display}} or reference in {{include}} IMO. > > Thanks > -Vincent > > >> WDYT? > >> > >> Here's my +1 > >> > >> Thanks > >> -Vincent > > _______________________________________________ > 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
