On Oct 6, 2011, at 4:21 PM, Denis Gervalle wrote:
> 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
It doesn't! The link resolving has nothing to do with context=new or not.
> , 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.
You need a way to express how relative links/attachments are resolved.
> {{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.
>
>
>>
>>>> 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
