> On 05 Sep 2016, at 22:27, Guillaume Delhumeau <[email protected]>
> wrote:
[snip]
> 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).
Yes I didn’t mention this option because for me it’s not an option and it”s not
going to work:
* As you say there’s no bijection, that’s the main issue
* won’t fully work in some cases. Imagine a Velocity macro wrapping an HTML
macro. You can edit with a velocity editor but then you loose the HTML edition
or you can edit in an HTML editor but then you loose the velocity syntax.
My feeling is that using a specific editor doesn’t bring that much value
compared to editing directly in XWiki (using the syntax hilighiting and
autocompletion extensions). For example I also use IntelliJ IDEA to edit the
XWiki .vm files (velocity content) and I’ve never felt that it was providing a
much greater experience.
And since you need an execution engine anyway to validate that your code works
you need to execute it in XWiki anyway so you might as well fully edit in XWiki.
I think what I’m trying to say is that I believe more in the direction of
working to improve the syntax hilighting/autocompletion and XWebIDE to provide
a better development experience in the future.
Again, what I do find that has value:
* Be able to not have to XML-encode doc content and textarea xproperty content
* Be able to have attachments separate from the XML
* Have those new XAR mojos to fetch and push/deploy.
IMO this is what we should focus on doing in a first version.
Thanks
-Vincent
> 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
