I could be mistaken but I think 2.2.2 added direct support for OGNL (MVEL, freemarker, and many others), which is pretty interesting. This was the last step before what looks like a cleanup and some refactoring that resulted in Tiles 3 (It also has the same EL/Template support). If you're putting in the work might as well go to version 3? There would be more of a change but that would be using their new APIs and provide a clean way forward. From a user perspective there is very little difference between the two. That is most people use the XML tiles definitions, and those remain almost the same (I think one change in the xml schema definition that a search and replace would resolve - although I think that change may have happened somewhere in 2.x and 2.2.2 and not between 2.2.2 and 3.0). I think Tiles 3 allows for better run time creation of definitions.
The above is the only pertinent information, the following is something I thought would be a cool extension building on Tiles 3: --- Creation of tiles-defintions at run time using FreeMarker would effectively allow the pushing of views into the DB. This in turn is very interesting because tiles provides page loading advantages by avoiding buffering. However if the views can be pushed into the database another layer of abstraction can be added; effectively a dependency management layer; letting you push a deeply nested control tag into a page which declares it's required CSS and JavaScript files, it would be a trivial matter to render these definitions in the correct order. You don't get run-time composition like Sitemesh, but you do sort of get that kind of behaviour regarding nested controls, which I think is currently a PITA. Here is a link on 2.2.2 integration: http://stackoverflow.com/questions/10050433/ognl-and-wildcards-working-in-tiles-definitions-with-struts2-tiles-plugin Here is a link you've already seen on SO (as you've commented there!): http://stackoverflow.com/questions/13337938/how-to-integrate-struts-2-with-tiles-3 Here is a link mentioning the only tag difference (seems it is between 2.2.2 and 3.0 so I was wrong earlier) "tiles:useAttribute" is now "tiles:importAttribute" this link also demonstrates list attributes which are _very_ useful: http://stackoverflow.com/questions/14540158/tiles-3-not-rendering-list-attributes (the code in the question works with the simple substitution mentioned in the answer). As far as dependency management in the DB is concerned you would have a table of definitions, table of JS files, table of CSS files, and then join tables: defintion-js, definition-css, once you've retrieved the BLOBs it's a (mostly)simple matter of using list attributes to render the retrieved definitions (a field to hold an ordinal is clearly also needed). --- Into the land of crazy: I would love to see facilities for Struts definitions being loaded from DB too. Started working on that but it fell by the way side. But benefits would/could include: A Struts admin console, better ability to provide tooling (in console syntax support - so we don't need to worry about how to write such support for a specific IDE), ability to create tool similar to JS fiddle but for struts2). Better ability for a user to alter (abuse) any existing configuration. Hell why not add a class loader to load from a DB as well then we're at PHP levels of dynamism. With views, Struts configuration, and action classes all being loadable from the DB, I think it would be a pretty fun environment. On Tue, Nov 17, 2015 at 4:53 AM, Lukasz Lenart <lukaszlen...@apache.org> wrote: > Hi, > > I'm working on upgrading Tiles plugin to use the latest Tiles 2.x > version - 2.2.2 - and it looks like the only thing is to drop all the > custom code from the plugin, just leave TilesResult. > > Tiles 2.2.2 contains support for FreeMarker (the Struts custom is > doing that) plus few other features. I think the only thing would be > writing a custom variable resolver to use Struts' ValueStack. > > Am I right? > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > >
