30 Jun
2013
30 Jun
'13
12:05 a.m.
2013/6/29 Caleb James DeLisle <calebdelisle(a)lavabit.com>
I believe we would need to stick with what the maven xar plugin will like
to be able to build, but at the same time looks nice enough in an IDE.
Making things easy for developers is quite interesting
to me because I'm
a developer and I like scratching my own itches.
more inline:
On 06/29/2013 05:41 AM, Ludovic Dubost wrote:
Yes this is similar. However your implementation is in Javascript and we
need an implementation based on the same code as xar:format as we would
also need to read from the wiki to the file system and make sure that the
xml files are properly formatted. We need xar:format compatible with this.
While XWiki has many great advantages as a
framework which takes car of
persistence, forms, user management, content management and provides tons
of APIs, when traditional developers want to extend XWiki there are
facing
a few difficulties:
- they are lost in the myriad of XWiki APIs, and there is no completion
- they don't get good visibility of the code available in their
application
- it is complicated to use editors which have
syntax highlighting
- they cannot use their favorite IDE
On the framework side there are also some improvements which could make
XWiki even more killer:
- easier integration of advanced JS framework
- advanced integration of a high level JS framework that has templating
(maybe angular js)
- better validation functions
- easier way to add REST APIs
- more XWiki and better documented javascript apis
Here are some proposals to help fix the tools issues. Three approaches
can
be looked at:
1/ Live Sync between an XWiki Instance and and improved maven xar file
structure, allowing to use any local IDE on XWiki code
First it should be possible to use any IDE on the maven xar file
structure,
allowing to open the content and textarea fields
of all XML files.
For this XWiki XML files should externalize the content and textarea
fields
in separate files with extensions based on their
content type.
The maven xar format should be able to clean the maven structure to do
this
splitting and should also be able to build the
XAR from all the files.
Finally a program should allow to do a live sync between a local or
remote
wiki instance and the maven project. Any change
in either the wiki or the
file system should be replicated to the other party.
So if you run "git pull" then your local or remote wiki would be updated.
If a change is made in the wiki, the change would show up in the file
system and your IDE would refresh it.
The sync program would keep a state of the version in the wiki, in order
to
be able to merge changes if changes occur in both
places between two
sync.
This tool could be easily launched with "mvn
xar:sync"
Syntax highlighting for XWiki Syntax+Velocity+Groovy would be developped
for the most popular editors.
When syncing the tool could show syntax checking error messages.
I actually implemented part of this for my own personal toolkit.
I presented it on the list to great fanfair here:
http://xwiki.475771.n2.nabble.com/A-new-XWiki-Model-sort-of-td7585722.html
I have the xar generation and push to XWiki in a 4 or 5 second post
operation.
The format is more makefile-esque so it's not really good for live sync but
I have been using it and have not yet thrown it across the room which is a
good indication that it's probably technologically sound.
2/ Integration with Eclipse
Based on XEclipse, we would build an Eclipse plugin to be able to connect
to an XWiki instance and load a specified list of spaces. Then each space
would be organized by the type of code in this space. Content and
Textarea
fields would be made visible as editable content
in Eclipse.
The plugin should detect the type of code in each of the content or
textarea fields (velocity/html, groovy, javascript, css, translations,
xwiki syntax) and use the appropriate editor.
Finally a completion module could be provided by loading from the server
a
list of available APIs.
The same plugin could also be able to organize the content from a local
maven project (based on 1/) and provide completion to such a project.
Live syntax checking could be provided.
3/ Integration of a WebIDE in XWiki
Based on Javascript WebIDE and web code editor softwares (Orion, Cloud9,
exoIDE, codemirror, etc..), we would provide a view on the code inside
the
XWiki instance.
Code would be organized in the same way as in the Eclipse plugin and
appropriate editors would be used depending on the code type.
Completion could be provided in the velocity and groovy editors and
eventually in Javascript
Two views should be available, one for each AWM application, and one with
all the code in the Wiki.
Live syntax checking could be provided.
If we decide this is a priority, it's something which I could investigate
and would be able to reuse experience and tools from the Resilience
project.
Solution 1/ is very powerful because it let's the user decide which is
his
development environment, even if the tree
structure won't be perfect.
Still
he can see all the code in the wiki and work on
it, including searching.
Committing is made very easy. There are some risks involved in the sync
process, particularly of you have multiple developers syncing local code
with the same dev server.
User can switch from local sync (local wiki) to remove sync (remove
shared
wiki) and can therefore work offline more easily.
Editing can be fully
done
offline.
Providing syntax highlighting for many editors might prove difficult.
Solution 2/ is providing a nice XWiki environment inside Eclipse, without
the need for a local copy of the code. Committing would happen using the
browser.
Solution 3/ is the long term bet as the future is to have everything in
the
web. Content is only in one place which makes
things a little easier.
Development environment needs no setup.
However this is more "new" for developers which need to adopt the
platform.
Live syntax checking is hard to provide but would be quite useful.
Alternatively mvn xar:format could also provide syntax checking for XWiki
syntax, velocity, groovy, js and css.
WDYT ? Which approaches do you believe would be the most promising.
#1 can be many things. It could be as simple as my little .xar generator
with ability to post to a live wiki. It could be as complex as an XWiki
filesystem which you'd mount with nfs or something.
If we commit to a directory structure, it is going to require a lot of
thought to make that structure coherent and once we commit to it, we're
kind of stuck with it.
#3 is easy at first then it gets hard. We can pull in an editor and if
we find an editor which supports ctags then we get completion for a
reasonable price. The problem is ctags (and most editors) don't support
velocity so if we want to autocomplete velocity we end up hacking
something together and making a few demos then it's forgotten, or worse
we write everything in-house to really support production ready velocity
completion and then we're saddled with maintaining another 15k LoC that
no other project has any interest in.
http://ctags.sourceforge.net/languages.html
Well we don't have much choice here. Velocity is not that well supported.
We also have XWiki Syntax which can have subparts using velocity, groovy or
anything else.
We will need to do some work here.
We could simplify if we also extracted the content of some macros into
external files, like the velocity and groovy macros. But still velocity is
velocity + html + potentially XWiki syntax, so we need some custom handling
here.
If what we want is extensions then we should go after extensions directly.
The fastest growing extension repository is npm, while it's smaller than
maven or rubygems, it's getting new packages at almost twice the rate of
maven, the next competitor. My recommendation is to move in the
#1 direction but specifically targeting XWiki extensions by copying the
npm workflow.
We have a package manager. Now we need to make it easier to create the
package from code you have in XWiki.
But this is not fully related to the development tool which is something
else. Right now you can create a XAR from xwiki in just a few clicks and
commit it to GitHub (including the pom creation), using the GitHubApp. But
this does not solve the IDE issue which is something else. However it's
true that if your get your code in the file system we need to give a quick
and easy way to create the pom.
My purpose right now is not about the extension creation workflow. It's
more about getting traditional developers to like the XWiki dev
environment. I had multiple discussions with developers and while
developers like a lot everything XWiki provides to speed up development
from a framework perspective, they get cooled off by the developping in the
browser concept. This is less true when the objective is an Intranet app on
an existing instance. This is more true of web-agency style development or
larger development projects.
I firmly believe the future is in a WebIDE, but it will take time to
takeover all developers. I like the #1 approach because it's not that
complicated. It's the GitHubApp the way around with your file system with
the "live" aspect. I've started some java code and found some nice library
to watch changes in a directory. I'm already close to have an initial
comparison of a maven xar project with a remote instance. The bigger work
is to define how we split the code files (attachments, content fields,
textarea fields and get maven xar plugin to support this). And once we have
code like that you can use any IDE which is quite cool.
Ludovic
Thanks,
Caleb
--
Ludovic Dubost
Founder and CEO
Blog: http://blog.ludovic.org/
XWiki: http://www.xwiki.com
Skype: ldubost GTalk: ldubost
Ludovic
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs