On 05 Sep 2016, at 17:10, Paul Libbrecht
<paul(a)hoplahup.net> wrote:
I've
seen many pages be only designed to be used using
> parseGroovyFromPage. Is this something that is deprecated now?
you’re probably
talking about XWiki Syntax 1.0 but even that was wiki markup not groovy (you had to use
<% …. %> ).
No.
parseGroovyFromPage loads a whole page of groovy and typically gives an
object. That page-content should start with
http://nexus.xwiki.org/nexus/service/local/repositories/public/archive/org/…
This is mostly deprecated. The new canonical way to have groovy in a page is now to use
the {{groovy}} macro, and you can {{include}} a page that’s using {{groovy}} if you need
to bring it to another page.
Note that in the xwiki core dev we don’t use groovy at all since this requires PR and
makes it very fragile and a pain for our users.
Which is a xwiki/1.0 syntax page btw. IMO it should have been plain/1.0 instead.
Should such a source not be as a .groovy file but a
.wikipage file??
If you’re talking about
https://github.com/xwiki-contrib/application-l10n/blob/master/src/main/reso…
it should have a plain/1.0 syntax IMO.
The <% %> of the XWik syntax 1.0 is for
embedding groovy. That's
something else.
I've
also seen velocity-based content to be the core of the UI of most
> applications and be contained in the content of pages.
That’s in vm files, not
wiki pages.
... and is often embedded in macros.
Not sure what you mean by vm files embedded in macros. What type of macros are you
thinking about and what’s the relationship with wiki pages?
So, in your proposal, any macro code whose biggest
part of the code
would be between {{velocity}} and {{/velocity}} (as suggested in most
tutorials) would not be living in a separate file but within a wiki-page
file. Right?
It’s not my proposal! It’s the way XWiki works right now :)
Thanks
-Vincent
PS: When you say macro, you need to be more specific. We have at least 4 or 5 types of
macros (wiki macros, rendering macros in java, velocity macros, radeox macros).
Paul