On 05 Sep 2016, at 21:26, Guillaume Delhumeau <[email protected]> wrote:
2016-09-05 18:20 GMT+02:00 Vincent Massol <[email protected]>:
On 05 Sep 2016, at 17:10, Paul Libbrecht <[email protected]> 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/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.
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.
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?
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
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