On Thu, Oct 6, 2011 at 6:24 PM, Denis Gervalle <dgl@softec.lu> wrote:
On Thu, Oct 6, 2011 at 16:42, Vincent Massol <vincent@massol.net> wrote:
On Oct 6, 2011, at 4:21 PM, Denis Gervalle wrote:
On Thu, Oct 6, 2011 at 15:38, Vincent Massol <vincent@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@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 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:
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.
I agree with Denis. If the behavior of the include macro is similar to a PHP/C include in the sense that it copies the content of the included content in the current content (as Vincent said in a previous mail) then it seems natural to me to resolve references from the included document relative to the current document (as if they were written in / copied to the current document). Thanks, Marius
* 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 devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs