Hello there... (I just don't know a better way to start a letter, gosh...)
I played a bit with Tiles to integrate it with Dimensions and I noticed
that, to remove the dependency on the servlet environment, a
TilesContext class has been introduced.
After a bit of refactoring in Dimensions, I needed to refactor Tiles'
DefinitionsFactory, though I don't know if it will be the final good
thing...
Anyway, the big problem is that I need to use TilesContext for examining
the HTTP header and beans in session scope. The last class that is aware
of TilesContext is TilesUtilImpl, that is not very configurable.
So I modified the signature of some methods of DefitionsFactory (and its
main implementation UrlDefinitionsFactory) replacing the "Locale" with a
TilesContext and added a "getDefinition" method.
Then I moved some code from TilesUtilImpl to UrlDefinitionsFactory so
that all the creation of new ComponentDefinitions instances are made
directly from UrlDefinitionsFactory and, surprise!, some of the methods
declared "public" do not need to be public anymore (like
"isLocaleProcessed").
The big issue (if it can be called this way) is that, in my local
version, DefinitionsFactory must read TilesContext and not Locale.
So my question is: do you think that DefinitionsFactory should use
TilesContext, then leaving to the specific implementation the way this
context is processed, or should it use Locale directly, though
ComponentDefinitions already uses it for its own storing mechanism?
There could be another way to solve the issue: put something
configurable between TilesUtilImpl and DefinitionsFactory that processes
the TilesContext instance, but it will be another level of indirection
(read: slowness).
I don't know if I should publish this (big) patch right now because I
would like a second point of view from you.
Please let me know.
Ciao
Antonio Petrelli
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
