We would need a write a REST API to manipulated extension manager features first. Without that it would be quite a pain because you need your extension to be in a repository listed in xwiki.properties and hack something with Extension Manager UI URL which is not really designed to be a stable API. On Tue, Sep 6, 2016 at 9:12 AM, Vincent Massol <[email protected]> wrote:
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
-- Thomas Mortagne