9 Jan
2012
9 Jan
'12
6:29 p.m.
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 <dgl(a)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 <guillaume(a)xwiki.com>wrote;wrote:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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 <dgl(a)softec.lu> wrote:
comments:
following
context=current
about
your
very
an
display
the
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
On Mon, Oct 10, 2011 at 09:31, Thomas Mortagne <
thomas.mortagne(a)xwiki.com>wroteote:
On Fri, Oct 7, 2011 at 12:13 PM, Vincent Massol <vincent(a)massol.net>
wrote:
> > Hi guys,
> >
> > Ok here's second version taking into account Denis and Marius >
> * 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
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 and
time
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 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 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.
new
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
> "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
one
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" 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 page.
I am still -1 on this last point. First, it is precisely because it is 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 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 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 > 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
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs