6 Sep
2016
6 Sep
'16
9:12 a.m.
On 06 Sep 2016, at 08:42, Vincent Massol
<vincent(a)massol.net> wrote:
@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
On 05 Sep 2016, at 22:27, Guillaume Delhumeau
<guillaume.delhumeau(a)xwiki.com> wrote:
[snip]
The only solution is to use an XWiki Syntax 2.1
editor and, depending on
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. 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). 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