5 Sep
2016
5 Sep
'16
9:26 p.m.
2016-09-05 18:20 GMT+02:00 Vincent Massol <vincent(a)massol.net>et>:
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/xwiki/platform/xwiki-platform-
oldcore/7.4.2/xwiki-platform-oldcore-7.4.2-javadoc.jar/!/
com/xpn/xwiki/api/XWiki.html#parseGroovyFromPage(java.lang.String)
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.
Let me explain with an example.
In an application, most pages contain a {{velocity}} macro in their
content, and their content is fully contained in that macro. Therefore,
even if the content is marked as xwiki/2.1, it would be more practical if
it were considered as velocity.
If the suffix of the file is ".xwiki21", there will be no editor with the
proper syntax highlighting in your computer to edit it. On the contrary, if
the suffix of the file that represents the content is ".vm", you will have
an editor with the syntax highlighting and everything...
So, even if the actual syntax is xwiki/2.1, I would prefer to have a ".vm"
file. But only if that file contains a {{velocity}} macro at the very
beginning.
I don't know how to handle it actually.
If we end up with a ".xwiki21" file, however, I will be able to manually
tell my text editor to consider it as Velocity.
For a page holding groovy macro, it's the same. I would prefer to have a
.groovy instead of a .xwiki21. That's what Paul is saying.
Do you see the use-case now?
Thanks,
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
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 <% …. %> ).
and it seems widely used from searching the
repositories.
(e.g.
https://github.com/xwiki-contrib/application-l10n/blob/
master/src/main/resources/L10NCode/CompareTranslationFile.xml
which calls it on
https://github.com/xwiki-contrib/application-l10n/blob/
master/src/main/resources/L10NCode/L10NGroovy.xml)
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/resources/
L10NCode/L10NGroovy.xml it should have a plain/1.0 syntax IMO.
The <% %> of the XWik syntax 1.0 is for
embedding groovy. That's
something else.
... 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?
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. 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs