6 Oct
2011
6 Oct
'11
3:48 p.m.
Hi Anca,
On Oct 6, 2011, at 3:32 PM, Anca Luca wrote:
So display will just be include
context="new" if I understand this
correctly.
include with context not-new only makes sense when it's used for
including sheets.
It makes sense whenever you want to include a page in the same execution context (ie do an
include in the real sense of include, think of include like a PHP include or a C include -
ie it copies the content of the included content in the current content).
Now since as far as I understood, the sheet mechanism
is deprecated (I am still to find out in which way), I think we should
reevaluate this need in the light of that.
The sheet mechanism is definitely not deprecated. The usage of {{include}} is indeed
deprecated in favor of sheet objects (to make it short).
That doesn't change the need for an include macro. Users will still want to be able to
include stuff.
On 10/06/2011 02:58 PM, Vincent Massol wrote:
We talked about having displayer macros several times in the past. Yes it's the
correct way because the displayer need to return XDOM and not HTML. Otherwise that breaks
up the promise that wiki content can be rendered in any syntax (be it PDF, docbook or
other).
Note that this doesn't preclude having an API (the display module API).
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! ;)).
can be fixed indeed with velocity. So unless we keep this way of using
document sheets, it's not such a big deal.
I really need to look at the new sheet mechanism before being able to
have an opinion about this. If it's not needed, although it's beautiful,
I prefer we won't do it because it involves migration.
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).
only if we've made up our mind and we're sure that this will be the
'future', correct way of displaying object properties in wiki 2.0 syntax. if there's a chance we might use another macro for
that, I prefer we
don't change things.
Sure, the reason we proposed this is only because we see its alignment with the
"future", i.e. the usage of XWiki syntax 2.0 display macros for displaying
entities.
Do you see another possible direction? (I don't).
Thanks
-Vincent
Thanks,
Anca
> WDYT?
>
> Here's my +1
>
> Thanks
> -Vincent