atom feed29 messages in org.xwiki.devsRe: [xwiki-devs] [VOTE] New {{display...
FromSent OnAttachments
Vincent MassolOct 6, 2011 5:57 am 
Thomas MortagneOct 6, 2011 6:02 am 
Denis GervalleOct 6, 2011 6:22 am 
Anca LucaOct 6, 2011 6:32 am 
Vincent MassolOct 6, 2011 6:37 am 
Vincent MassolOct 6, 2011 6:47 am 
Denis GervalleOct 6, 2011 7:20 am 
Vincent MassolOct 6, 2011 7:41 am 
Denis GervalleOct 6, 2011 8:23 am 
Marius Dumitru FloreaOct 7, 2011 2:08 am 
Vincent MassolOct 7, 2011 3:13 am 
Vincent MassolOct 7, 2011 5:16 am 
Marius Dumitru FloreaOct 10, 2011 12:22 am 
Thomas MortagneOct 10, 2011 12:31 am 
Denis GervalleOct 10, 2011 1:12 am 
Guillaume LerougeJan 9, 2012 8:59 am 
Denis GervalleJan 9, 2012 9:26 am 
Denis GervalleJan 9, 2012 9:28 am 
Vincent MassolJan 9, 2012 9:37 am 
Denis GervalleJan 9, 2012 10:29 am 
Ludovic DubostJan 9, 2012 10:57 am 
Vincent MassolJan 9, 2012 2:01 pm 
Vincent MassolJan 10, 2012 4:29 am 
Denis GervalleJan 10, 2012 4:37 am 
Ludovic DubostJan 10, 2012 5:07 am 
Thomas MortagneJan 10, 2012 6:04 am 
Marius Dumitru FloreaJan 10, 2012 9:56 am 
Sergiu DumitriuJan 10, 2012 3:17 pm 
Thomas MortagneJan 11, 2012 3:30 am 
Subject:Re: [xwiki-devs] [VOTE] New {{display}} macro and changes to the {{include}} macro - Second Try
From:Denis Gervalle (dg@softec.lu)
Date:Jan 9, 2012 9:28:53 am
List:org.xwiki.devs

Oups, sorry I should have read your other mail before replying. Maybe the best would be to split this vote, and propose a vote to revert to the old behavior starting from 3.2.1.

Denis

On Mon, Jan 9, 2012 at 18:26, Denis Gervalle <dg@softec.lu> wrote:

Seems to me that there has been an agreement to revert to the old behavior has soon as possible, but I do not see the link with XWiki 3.2.1 release ?

On Mon, Jan 9, 2012 at 17:59, Guillaume Lerouge <guil@xwiki.com>wrote:

Hi guys,

can we please finish and/or close this vote so that Sergiu can act on it and we can release XE 3.2.1?

Thanks in advance,

Guillaume

On Mon, Oct 10, 2011 at 10:13 AM, Denis Gervalle <dg@softec.lu> wrote:

On Mon, Oct 10, 2011 at 09:31, Thomas Mortagne <

thom@xwiki.com>wrote:

On Fri, Oct 7, 2011 at 12:13 PM, Vincent Massol <vinc@massol.net> wrote:

Hi guys,

Ok here's second version taking into account Denis and Marius comments:

* Have a {{display}} macro which is equivalent to context=new and

resolve=source (ie links resolved on the reference being displayed)

+1, this is simpler and clearer

* Have a compatibility mode for the {{include}} macro with the following behavior:

** {{include}} in non-compatiiblity mode is equivalent to

context=current

and resolve=current (ie links resolve on the including document)

** {{include}} in compatiiblity mode is equivalent to

context=current

and

resolve=source (the default we have now and which we need to not break people)

* We would have a rendering.macro.include.compatibility configuration property

* We would set that property to true by default for 3.3 to give some time for people to adjust

* We would set that property to false by default for 3.4

-0, this is for me useless, since I doubt many understand that and have notice this change in 3.x. I was unaware myself of this change, and I do not remember any discussion about it in the past. If you have a ML thread about the rational behind this mistake, I am still interested, but I it could have been introduce without notice, it could be removed as well. At least, this should not be in compatibility mode by default.

So you propose to get back to previous behavior by default, right ? Given the fact that it has been changed very recently maybe we should have the property false right away and say it was a mistake ?

I agree.

* Deprecate "document" parameter for the include macro and add a

new

"reference" parameter + a new "type" parameter (I forgot that one in my first email). The "type" parameter represents the Entity Reference

Type.

* Also add a "type" parameter for the display macro (I forgot that

one

in

my first email)

* Have the "type" parameter default to "document".

+1

I forgot to mention the following point: ** The {{include}} macro has a new "resolve" parameter (the "context" one is deprecated) which can be "current" or "source". This is needed since there are use cases both resolve=current and resolve=source for the include macro. Once again the context param has nothing to do with how links/images are resolved. And again the writer of a page isn't necessarily the same as the person who's going to include your page.

I am still -1 on this last point. First, it is precisely because it is very difficult to understand the differences between the context and the resolve parameter that I am against it. I repeat myself, but not having the same behavior between $doc.getURL() and [[ ]] is for me not acceptable, since the included document author could no more count on the equality of these to resolution methods. If I have been aware of that change in 3.x I would have veto it already.

Moreover, if the writer of the included document is the not the writer of the including document, he would be better if he could stay in control of how links/image are accessed, protecting the way its own document works, and not leaving this to the including document author. This is why I have proposed to move the resolve parameter on individual links, which is more flexible and understandable.

Currently, AFAIK, during an {{include}} (without context=new), using velocity, the included document do not have an easy access to itself (without knowing its own name), but you want this possibility for links ? and you want it globally ? This seems to me curious that something difficult to do by code would be easy by syntax.

If you still want to convince me, please explain why you need $doc and relative links to diverge, especially without the included document author to be aware of this. What cannot you do with {{display}} that would be possible by {{include resolve=source}}; and that would not be better served by giving the control to the included document author ?

Denis

Some additional notes: * The person writing a page is not necessarily the same as the

person

writing an include.

* With the new sheet mechanism there are a lot less use cases for

the

include in compatibility mode.

Please vote again.

Here's my +1

+1 (with the previous note)

Thanks -Vincent

On Oct 6, 2011, at 2:58 PM, Vincent Massol 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).

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! ;)).

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.

* 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.

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).

WDYT?

Here's my +1

Thanks -Vincent

_______________________________________________ devs mailing list de@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

_______________________________________________ devs mailing list de@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

_______________________________________________ devs mailing list de@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list de@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

_______________________________________________ devs mailing list de@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs