> 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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
