[Springframework-developer] re: TilesView & Resolver

[Rob B. <rob...@ve...>]

Hello all,

> However I saw someone commenting about the TilesView stuff I posted a
> while ago. I recall you asking about whether or not it would be
> integrated before 1.0. Well, that's the plan indeed. You commented that
> the ViewResolver could better be a view configurer! Good idea!

Integration of Tiles would be very nice.
 
> First of all there's the dependency on Struts. Of course there won't be
> any runtime dependency if you don't use it, but I still strongly object
> to linking in the Struts11.jar, simply because it would send the wrong
> message. 

While not ideal, this is not so horrible.  Plus the rest of the spring framework can be used with Struts if someone so chooses.

> Why in heaven's name link in a competitor-MVC-framework!

In my opinion this is not the best attitude...  Don't think of them as a competitor, think of them as a co-petitor (cooperative-competitor).  A little FRIENDLY competition between different frameworks is a good thing, but if either framework can be improved by some cooperation along the way then why not.  Both projects are open source so it's not like your competing for $$ like corporations are.  

> I just doesn't feel right. However, since Tiles is completely
> integrated into Struts, it will be hard to split the tiles.jar
> from it or something.

Tiles used to be separate, it was only more recently that it was integrated into Struts.  Struts has a fairly decent track record of splitting out functionality that is re-usable by other projects (Digester for example).  If you asked nicely on the Struts list, they would probably consider moving the core of Tiles out of Struts and into a separate jakarta commons package for better re-use (especially if you helped a little).  In that way, both frameworks can make use of the Tiles code without having to "link" with each other.  This is beneficial for all involved because it will make tiles more modular, and thus potentially re-usable for other frameworks too.  Also it will increase the # of developers who maintain Tiles, because now both the struts developers & the spring developers will make use of it.

> We would have to maintain ourselves or something like that, and
> that's a mess too! Well, maybe some plugins feature or part of the
> website would be nice, maybe some people can think about this.

Basically you would be code-forking the tiles portion of struts.  This is unfortunate as forked code will always eventually diverge, and there will be different features in each of the code bases.  The additional work to maintain a separate fork would not be needed if you and the struts group code make it a commons project as I suggest above, and the single tiles code base would hopefully be more robust and featureful since it did not fork.

Hope this helps out
Later
Rob