Le 30 janv. 2012 à 09:25, Vincent Massol a écrit :
On Jan 30, 2012, at 8:24 AM, Paul Libbrecht
wrote:
I am regularly working with my favorite IDE,
IntelliJ IDEA, and it is doing a very good work for me to edit velocity and groovy. I am
using this also for the source of wiki pages which I upload using a tiny upload script
(that posts like a form using curl and simple preemptive authentication, [1]).
The interest of storing page-sources as files is that you get all the IDE services (it
could work with most IDEs) such as auto-completion, code-usage-tracking, or html and
javascript validation.
The other interest is that my source files enter versioning. I can commit these so that I
and other developers know it's part of the build for the future, independently of my
server upload and developer readable in versioning system.
Yep, we already save our XAR pages in our SCM in the xwiki project dev.
Thus far I've been using
wiki/src/main/pages/<spaceName>/<pageName>.vm (or .grv, .properties, ...).
There's a single issue I stumble across: for IntelliJ to do me classpath resolution
(e.g. recognize an import for the Context class), I need to change the maven project type
from xar to jar. And this is not so good.
My next step would thus be to create a new sub-project, xwikipages, containing these
pages... but maybe everything is wrong here.
My questions:
• how much of that is good or best practice?
• what do others use as IDE-exploitation for XWiki-pages? (XEclipse and the Git
xwiki-application?)
• is anyone else interested into sharing such a practice and enhance it commonly?
Personally I'd love to have an IDE plugin (for intellij IEA for example; )) that
would take a file in XWiki XML format and displays the content as editable text. When
saved, it would be saved in the XWiki XML format with proper XML-encoding.
Tastes interesting but I think it might be easier to accomodate our tool to the
widespread practice.
An alternative which might be even better (since
it would work with all IDEs and I think this is what you're proposing) would be to do
something like this:
* Store XAR pages into 2 files:
** one file for the content itself saved without XML-encoding, as plain text
** another file containing the metadata
Correct.
And XInclude has one form for such inclusion.
* Modify our XAR plugin so that it combines the 2
files into one XML file in the XWiki XML file format when it generates the XAR.
I would love that!
* Adding a Mojo so that the user can upload a
given page into a running instance would be the icing on the cake.
indeed. Or use some other simpler tool.
Here, the real power might be to do some version control to avoid conflict with a
previous... not sure it is desired or possible.
* We'll also need another mojo that takes an
existing XAR and extracts it and split pages into the 2 files mentioned above.
Very easy if XInclude is used.
(I tend to use jdom for this kind of things, dom4j works well also)
The issue you have with classpath resolution is
probably not so hard to fix.
I'll need to try this out to try to find a solution.
Gotcha, you remember me JetBrains Support helped me there... Just add "xar"
among the archive file types in the preferences!!
Definitely +1 from me to explore such ideas. The
best IMO Paul would be to continue the work we started with the XAR plugin.
Ok... where' the code?
Right now, nobody, it's all yours ;)
You can send pull requests and we'll apply.
I sure have the XML competency but less the maven
competency (last i programmed for maven when at jelly times).
oh good old jelly! I remember that times when James just created Jelly and we were having
fun with it. It didn't look at bad idea at the time ;)
Thanks
-Vincent