On Thu, Oct 6, 2011 at 6:24 PM, Denis Gervalle <[email protected]> wrote:
> On Thu, Oct 6, 2011 at 16:42, Vincent Massol <[email protected]> wrote:
>
>>
>> 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:
>>
>
> 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
>> [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
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
