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? Who are the guys on it? I sure have the XML competency but less the maven competency (last i programmed for maven when at jelly times). paul _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
