2016-09-05 22:09 GMT+02:00 Vincent Massol <[email protected]>: > > > 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). >
This is what happens in practice when you use an extension like "It's all text" (https://addons.mozilla.org/en-US/firefox/addon/its-all-text/) and that is not a big deal. This how I work every day. > > 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”)) > No. The Paul's initial proposal was about introducing an @textInclude() in the XML file that could include any file. The advantage is that the developer can use whatever suffix she wants. @textInclude('myContent.vm') @textInclude('myContent.groovy') etc... The drawback is that you cannot have it when you export the page (no bijection). > > 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 > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
