Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
MIME-Version: 1.0
In-Reply-To: 
 <CAPcVg7mLPKeO8Q+iV9+rakwS6LAB4i6c-LUqGoaTHe6Xis=Ufg@mail.gmail.com>
References: 
 <CAMopvkPOAdCDRGDjmkwWU4=iOWdyJ7UeSYOCW-tVmJZxL2ObmQ@mail.gmail.com>
 <CAPcVg7mLPKeO8Q+iV9+rakwS6LAB4i6c-LUqGoaTHe6Xis=Ufg@mail.gmail.com>
From: Lukasz Lenart <lukaszlenart@apache.org>
Date: Wed, 18 Nov 2015 08:47:03 +0100
Message-ID: 
 <CAMopvkOxW8o-TiE=b3LE-qnjhaX-Vgm939r+QjYd-p=UEuNKMw@mail.gmail.com>
Subject: Re: Upgrading Tiles plugin
To: Struts Developers List <dev@struts.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks Ken for all your insights :)

2015-11-17 18:59 GMT+01:00 Ken McWilliams <ken.mcwilliams@gmail.com>:
> 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 ma=
y
> 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.

I'm treating keeping support for Tiles 2 as an intermediate step for
users to migrate to Tiles 3 - not sure if this a good or bad idea.

> 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 effective=
ly
> 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-wit=
h-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-at=
tributes
> (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).

Could you register a ticket in JIRA with the above? Looks like after
upgrading Tiles 2 Plugin I will have to extended Tiles 3 support as
well :)

> Into the land of crazy:
>
> I would love to see facilities for Struts definitions being loaded from D=
B
> 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) an=
y
> 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.

(I'm reading this over and over and not sure if I understand :))

Is it related to Tiles support or you mean actions' configuration? Do
you have any code to share? I'd love to hear more... maybe open a PR,
or JIRA ticket to allow track this?


Regards
--=20
=C5=81ukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org