On Jun 5, 2006, at 6:43 AM, Antonio Petrelli wrote:
Hello there... (I just don't know a better way to start a letter,
gosh...)
I have the same problem sometimes :-)
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.
I don't have a problem *adding* TilesContext to the
DefinitionsFactory interface. Are you talking about readDefinitions
(), addDefinitions(), etc. Could you post the changes you made to
DefinitionsFactory and UrlDefinitionsFactory? I think that would
give me a better idea of the impact.
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").
I like this change. The only thing I find bothersome about it is
that it's similar to how XmlDefinitions was introduced in Struts-
Tiles. What I mean is this: XmlDefinitionsFactory (or whatever the
class name is extended DefinitionsFactory, but added features that
were really part of core Tiles functionality rather than simply part
of an XML-based implementation. It seems we are doing the same thing
here by putting some "core" functionality in a default implementation
of the DefinitionsFactory. But maybe the UrlDefinitionsFactory is
generic enough that it wouldn't matter.
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?
I'm undecided on this. I lean towards still requiring a locale
directly since that object acts as a "key" into the definitions map.
But, I get the feeling that in most places locale is on the
interface, it will be in the context of a request. In that case I
can see the value of having the full context around - especially
since it's no longer married to the servlet API. But I think that
most of the time addDefinitions() will be called at servlet init time
and many of the components in TilesContext will not be available.
But there are already cases where that situation exists.
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).
That seems like too many layers to me.
Go ahead and publish your code. I think it would be easier to
evaluate the concepts if I could actually look at it.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
