> On 06 Sep 2016, at 08:42, Vincent Massol <[email protected]> wrote:
>
>
>> 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.
@Thomas: What would be awesome would be that the xar:deploy mojo builds the
XAR package and then in the deploy phase deploys it as an extension, along with
all its dependencies. The problem is that right now it’s the EM inside XWiki
that would resolve the dependencies (and of course it won’t find them in any of
its defined default extensions repos). So a solution would be that it’s the XAR
plugin that analyzes all the dependencies and deploys them one by one starting
with the bottom one. We would also need to handle upgrades and the ability to
redeploy a SNAPSHOT version with the same version.
That would be so awesome IMO and would really help developing in an SCM for
XWiki.
Do you think that could be doable or is it way too complex?
Thanks
-Vincent
> 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
