5 Sep
2016
5 Sep
'16
10:09 p.m.
On 05 Sep 2016, at 21:26, Guillaume Delhumeau
<guillaume.delhumeau(a)xwiki.com> wrote:
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. I had understood this but this is not how it works and I don’t think
it’s a good idea to change the rendering model just for the sake of being able to edit
outside of XWiki. Or at least that’s a much bigger scope than the one we’ve been
discussing in this thread.
Right now wiki pages are written in a given syntax and macros are black boxes that can
contain anything (including other syntaxes - imagine using the {{content}} macro for
example, etc).
There’s no way that you’ll be able to find an existing IDE/editor on the market that knows
this.
For example if you take the following simple example:
{{velocity}}
#set ($a = “b”)
{{/velocity}}
And you edit with an existing velocity editor, you’ll get syntax errors, bad
autocompletion and bad syntax coloring because existing velocity editors don’t know about
XWiki Syntax 2.1 (i.e. the {{velocity}} and {{/velocity}} parts).
The only solution is to use an XWiki Syntax 2.1 editor and, depending on the macros used,
that knows how to delegate syntax highlighting and autocompletion to a specific editor for
that content (velocity in this example). But you won’t have this tool in all existing IDEs
and it’s a huge work to write that. FTR this is a bit what we started with XEclipse back
then and we’re now more going towards a Web IDE.
If Paul (and your) point is to say that we should develop by writing the following then I
wouldn't agree since that makes it very unnatural and hard to follow IMO:
{{velocity}}
#parseVelocityFromPage(‘some.other.page’)
{{/velocity}}
(And in some.other.page: #set ($a = “b”))
So I’m not sure where you’re going with this. There’s no good way unless you completely
rewrite XWiki’s rendering system (and its syntaxes) and I’m sure you’ll agree this is a
bit too much ;)
I was just trying to explain this to Paul in my previous answer.
Maybe you have an idea I haven’t imagined?
Thanks
-Vincent
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.
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.
... and is often embedded in macros. Thanks,
>
>> 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