Hi Caleb/all, On 6 Feb 2014 at 01:24:38, Caleb James DeLisle (c...@hyperboria.ca(mailto:c...@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, vinc...@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
