10 Feb
2014
10 Feb
'14
9:13 p.m.
On 02/06/2014 04:09 AM, vincent(a)massol.net wrote:
This sounds like an interesting approach, does it parallel anything you
know of in the field and if so, what were the benefits and challenges
for that team's implementation?
+1 for making a loadable servlet-like interface then putting the action
adapter into an extension so we have 2 levels of interfaces and there
is a way forward if we discover we need to backpeddle on the action
module.
My understanding is the Action module is a clean slate, we're not
actually implementing servlet or anything else in this case.
The technological progress of servlets has been constrained by backward
compatibility concerns and as such has not changed much in the 17 years
since the original spec so basing a new interface on them alone would
almost be throwing out 17 years of research and industry experience.
If I were in your position I would not accept this as a proposal.
At this point I lack the data to take a strong position on whether to use
filters or not but I will take a strong position on taking strong positions
without supporting data :)
Haha that's always the problem, if you want to cover the maximum of use
cases then you'll need to write a servlet proxy for loadable servlets
so we can fix the Action module when we encounter the problems later.
Nobody gets it right on the first try...
( says the guy whose network project is on it's 7th protocol version ;) )
Thanks,
Caleb
Hi Caleb/all,
On 6 Feb 2014 at 01:24:38, Caleb James DeLisle
(cjd@hyperboria.ca(mailto:cjd@hyperboria.ca)) wrote:
I'm not that knowledgeable in the field but I raised the issue mostly to
make sure you've thought it through and since it seems that you have, I'll
trust that you've got a workable solution.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs