This commit implements 3 JIRA issues:
- XWIKI-10024: Introduce ResourceAction in Resource API to represent an action
- XWIKI-4713: New Action module
- XWIKI-9375: Add integration for WebJars
Once you have an XE using those changes you can build and install with EM the AngularJS
Todo Application committed here and it’ll work magically:
Let me know if you’re ok for me to commit my work on master for 6.0M1.
Thanks
-Vincent
On 6 Feb 2014 at 10:10:01, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
Hi Caleb/all,
On 6 Feb 2014 at 01:24:38, Caleb James DeLisle
(cjd@hyperboria.ca(mailto:cjd@hyperboria.ca)) wrote:
I'm glad to see this moving again.
For those who weren't watching before, the story of actions was
that they were partially developed and we wanted smooth pluggable
support for portlet and servlet without losing any features of
either. I could not find a way to implement this and development
stalled.
q1: Is portlet support still a requirement and if so, what is the
balance we want to strike between features which don't work for one
of the two paradigms or features which are missing completely to
keep the actions portable?
It’s never been a requirement of the action module itself. However, and maybe this is
what you mean, some Action implementations will be dependent on the environment (to write
to the servlet output stream for example). Said differently:
* xwiki-platform-action is a standalone module with just a dependency on
xwiki-platform-resource
* the Action implementation components will be scattered in the various modules that
require them
** Right now all old type Actions are in oldcore so we'll need to decide if we
continue putting the new ones there or elsewhere).
** I’ll use a new action to add support for webjars (a “webjars” action) which will be
located in the new xwiki-platform-webjars module I’m working on.
Right now, my first step is to have the action framework committed and a first action
done in webjars.
A second step will be to try rewriting an existing XWikiAction to the new framework. This
is where we’ll start having the debate of whether to go through the Container module or
not and the consequences… :)
Does that sound alright to you?
q2: What is the relationship between an action
and a REST request?
I can imagine in an ideal world that skin/html could actually just
be a form in which a rest response would be transported.
Actions are independent of URLs. The way I’ve designed it so far is:
URL comes in —> ResourceFactory generates a Resource our of it —> ActionManager
finds the right Action to execute it.
Technically the ResourceFactory is just an interface and the ResourceFactory
implementation that accepts a URL and generates a Resource is located in the
xwiki-platform-url module, itself delegating to xwiki-platform-url-standard which
implements the “standard” URL scheme (and it’s possible to implement other URL schemes and
the scheme used is configurable in xwiki.properties).
I’ll need to do a nice diagram for all this to make it simpler to read and post it on
xwiki.org ;)
Thus, from the Action module POV, it can handle any type of Resource, be them REST,
Entity, Skin resources, Template resources, etc. It’s up to the URL module to know how to
generate a Resource object from all URLs.
q3: Will this go through a period as an
installable extension
before it lands in XE? To me this is a big deal because we need to
really start walking the walk regarding slick'n'slim and moving
things out of XWiki's "core”.
Well, right now we have the Struts Servlet and all our mappings in web.xml go through it.
I’d rather not invent a new mapping and have to change all the URL parsing code. ATM
having a new servlet would be the only way I know of making it independent. However there
are 2 additional issues:
- issue 1: we need servlet 3.0 first to be able to install new Servlet just by dropping a
JAR in WEB-INF/lib
- issue 2 (the most important one): servlet 3.0 are not dynamic so they wouldn’t be able
to be installed as XWiki extensions.
Thus the best answer is still to have a single XWiki Servlet and from then on, only use
XWiki components which makes everything else installable from EM.
I need to research it a bit more but maybe what we could do is this:
- introduce a new servlet and make the current mapping go through it (instead of the
struts servlet)
- handle new actions in this new servlet
- whenever an action hasn’t been handled, forward to the struts servlet
I need to try this out.
q4: Where do we want to draw the line between
simplicity and
flexibility? When Servlets were devised flexibility was very popular
but today you see frameworks advertising their most simple interfaces
with "get started today" and tiny code snippets [1] [2].
Stated otherwise: do filters actually make sense at this point?
Personally I'd YAGNI the filters and shoot for simple.
Simple is Servlets for me. This is what everybody knows in the Java world and can deploy
to. It would do a lot of harm to not provide it IMO. Regarding node.js I don’t see how we
would run our Java code in it ;)
Servlet is really the simplest of the Java EE specs. I don’t feel that they are too
heavyweight. In any case, if in the future another technology arises in the Java world we
could easily switch if we make sure to go through our Container code...
These questions are food for thought but in
general, I want to do
whatever I can to sign off on this because I don't want to paint
the bikeshed here, especially when I'm not writing the actual code.
Yep, let me push a first impl in a branch and we can talk more about the details. I’m
keen to ensure that my first design covers the maximum of use cases and I’ll need your
help to verify this!
Thanks Caleb
-Vincent
Thanks,
Caleb
[1]
http://www.sinatrarb.com/
[2]
http://nodejs.org/#column1
On 02/04/2014 09:11 AM, vincent(a)massol.net wrote:
> Hi devs,
>
> I’m currently revisiting the action module, see
http://design.xwiki.org/xwiki/bin/view/Design/ActionModule
>
> Let me know what you think and if you have any other idea. I’m going to continue
exploring this over the coming couple of days and write a first implementation that I’ll
put in a branch in platform. Of course the earlier you can provide feedback the less I’ll
have to rewrite ;)
>
> Context: I’m ready to commit support for webjars (see
http://jira.xwiki.org/browse/XWIKI-9375) but I’d like to do it cleanly without
implementing it as a Servlet Filter or as an oldcore XWikiAction…
>
> Thanks!
> -Vincent