6 Oct
2011
6 Oct
'11
4:42 p.m.
On Oct 6, 2011, at 4:21 PM, Denis Gervalle wrote:
On Thu, Oct 6, 2011 at 15:38, Vincent Massol
<vincent(a)massol.net> wrote:
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
It doesn't! The link resolving has nothing to do with context=new or not.
Hi Denis,
On Oct 6, 2011, at 3:22 PM, Denis Gervalle wrote:
No. Context = new is only about isolating the execution context. It's not
about deciding against what to resolve the links/attachments
On Thu, Oct 6, 2011 at 14:58, Vincent Massol
<vincent(a)massol.net> 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 ? 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
, 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.
{{include
?
why
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.
You need a way to express how relative links/attachments are resolved.
> 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
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, use a new parameter for this ?
See above. They're 2 separate things.
{{display}} implies resolve=source
Correct
why {{include}} does not implies resolve=current ?
Because there are 2 valid use cases. If we had resolve=current the default (which is the
opposite to what we want IMO) then how would users implement the following use case:
* I have Page1 with following content: image:my.png
* I include Page1 in Page2: {{include document="Page1"/}}
* Result: when I view Page1 the image is broken since it doesn't exist in Page1
Thanks
-Vincent
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.
No. right now there's only a document parameter supported.
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
> 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 , 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!).