6 Oct
2011
6 Oct
'11
5:24 p.m.
On Thu, Oct 6, 2011 at 16:42, Vincent Massol <vincent(a)massol.net> wrote:
On Oct 6, 2011, at 4:21 PM, Denis Gervalle wrote:
I do not see discussion about how relative links has to be resolved their.
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.
Why do you say the opposite to what you want ?
If you are using {{include}} and not {{display}}, you are probably doing
something like a sheet, and the most common situation would be to use stuffs
from the including document and not the include one, so to use the
equivalent of resolve=current as a default.
What I say basically, is that you may have a default behavior globally, but
you will never solve all use case with it, and providing a global parameter
to change the default will not either, and is for me a added complexity.
Changing the global default should be more at the link level than the global
level. Introducing a appropriate link syntax to refer explicitely to either
the source document or the current document in the link would probably be
the best way to solve all use case.
Now regarding the global default, when none of the above syntax is used, I
would resolve against current for {{include}} and against source for
{{display}}. This seems to me the best default, that would be consistent
with the content of the $doc in these two ways to include documents.
So I am +1 for two macro with the above default.
I am almost -1 to provide one of them a way to divert the way links are
solve from the way $doc.getURL() would respond.
I am +1 to introduce a syntax in links to explicitly refer to the current or
source document (using your definitions).
I am almost -1 for using current and source, the seems confusing, but I have
not think enough about it to provide alternatives right now.
On Thu, Oct 6, 2011 at 15:38, Vincent Massol
<vincent(a)massol.net> wrote:
> Hi Denis,
>
> On Oct 6, 2011, at 3:22 PM, Denis Gervalle wrote:
>
>> 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
?
>
> 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 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.
{{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
{{include
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs