Vincent Massol wrote:
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.
You do not reach such an impact doing that. Far
from it!
(e.g. if you want search cursors that fetch from some other data
sources; sure you can do it in Java but the Groovy way is much faster
developed).
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.
Does
this mean that apps don't use it?
Or that you wish the FS representation to not support it in a way that
makes the file source-files?
Which is a xwiki/1.0 syntax page btw. IMO it should have been plain/1.0 instead.
I don't see the point saying that this is a wiki 1.0 syntax (or
plain-text) except for rendering. This page is a "groovy page" meant to
be used by parseGroovyFromPage; it has no value displaying it thus the
syntax can be whatever you want...
If I follow your logic, it should be, within a
file-system-representation, a file with such a name as "content.txt".
Then again... since you have no flexibility of names, you have to hack
things around to make an IDE edit this file and recognize it as a groovy
file.
velocity ... and is often embedded in macros.
Not sure what you mean by vm files embedded in macros.
Did I say vm files? I said
vm fragements.
What type of macros are you thinking about
the
velocity macro.
and what’s the relationship with wiki pages?
Generally, as far as I know, this is used to generate content.
Here is one of first tutorials...
http://platform.xwiki.org/xwiki/bin/view/DevGuide/WikiMacroTutorial
The velocity suggested there can be very much bigger and being able to
split it out within a .vm file for you to edit with an IDE (and enjoy
auto-completion, method-analysis, and syntax-coloring) is, I believe, an
essential function of an FS representation.
Paul