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