[T5] Turning Off / Overriding Tapestry Name Munging
Tapestry 5 has logic that munges the name of a component based upon various heuristics. For example - if we have a component in a class called com.company.components.test.TestComponent - then when we refer to it in another component template it is addressed as test.Component. The initial Test* part of the component name gets dropped because it is the same as the package name. In tapestry 5.0.10 there seem to be additional rules involved that have broken some of our code after we upgraded from 5.0.7 We would just as soon do without this this logic. It make it rather hard to locate a template when we are looking at a component class. This is especially the case when there are many dozens of templates. We would prefer to have a simple mapping of classname to component name. In the example above we would just use test.TestComponent to refer to our component. Is there a way to fine tune this munging logic? - or turn it off completely? Thanks David Kendall Lithium Technologies - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5 Proposal: Provide a Mechanism to Force Cache Flushing
Howard - thanks for your reply. From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Friday, January 18, 2008 3:14 PM Obviously, we can't predict every possible use case ahead of time. Very true. It's notable that we have built a whole lot of functionality on T5 without encountering any significant limitations. This is the first real stumper we have come across - not bad considering this is very much an outside the box use case. For this reason - please regard my comments / questions as a testament to the flexibility of the framework. Different instances of URLChangeTracker do track different things; a single shared service would not be ideal. That's fair enough - and something I didn't spot before I just looked at the code. However the pattern of the XXXSourceImpl classes explicitly constructing an instance of UrlChangeTracker may be something to revisit. Such a pattern creates a tight coupling that inhibits the extensibility of the framework. As an alternative - perhaps a UrlChangeTrackerSource service could be injected into these services - which would act as a factory for UrlChangeTracker instances. Such a service could then be decorated or aliased as needed. I am sure there are other approaches that could achieve the same result. Supporting your situation could be accomplished by addining a new method, flushCache(), to the ComponentTemplateSource interface. This would be fine - it seems like it would be easy to implement and fitting. Probably a similar method should be added to the other XXXSource services that cache their contents. Alternatively, you may be able to replace the CTS service with your own. A contribution to the Alias service will replace Tapestry's built-in implementation with one of your own. You can re-use the implementation class, but pass in an URLChangeTracker explicitly, so that you can use the forceChange() method. That's a good idea - and something I had not considered. The only downside of this is that the CTS service constructor that takes an explicit UrlChangeTracker instance has package visibility right now - so I assume I would need a class in my source code that would be in the org.apache.tapestry.internal.services package. This would be a little ugly - but probably acceptable as a temporary work around if we could eventually get that constructor given public visibility. Let me know if I can help in any way. Thanks again. David Kendall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
T5 Proposal: Provide a Mechanism to Force Cache Flushing
I would like to have a way to force tapestry to flush/reload its caches and I am wondering how best to get such functionality incorporated into the Tapestry 5 framework. I am not sure what the best forum is to post suggestions around T5 so I thought I would start here. If there is a more appropriate venue please point me in the right direction. My specific use case is that I have built functionality to load some templates from a content repository. I basically do this through a custom class loader - so the source of the templates is largely transparent to tapestry. However - when a template in the repository changes I need a way to tell tapestry to reload. This is much like the existing logic that reloads the caches when a template file changes. In attempting to implement this I decorated the ComponentTemplateSource service with logic to query the content repository for changes. However - my implementation was blocked by the fact that the UrlChangeTracker is constructed directly by the ComponentTemplateSourceImpl class. This means I have no way to force the ComponentTemplateSourceImpl to flush its cache. It seems that UrlChangeTracker might easily be implemented as an IOC service which would make it available to other services that need to handle loading of templates. Such services could then force a cache flush through the forceChange() method. An alternative approach might be to add a forceChange method to the ComponentTemplateSource interface. We are very successfully using Tapestry 5 for the next generation user interface of our product. We love how flexible and customizable the framework is. It fits in very well with our need to be able to customize and co-brand our UI. I am somewhat new to active participation in open source and am wondering if there a best practice around lobbying for a feature request in a project like tapestry. I am pretty familiar with the tapestry source by now - so one option would be for me to code the update I would like to see and submit a patch. However - I am sure there are multiple approaches to build the functionality I want to see - so it would be helpful if someone familiar with the internals of the caching logic could provide some feedback if my approach is the optimal. If there are other strategies that people here find effective please suggest them. Thanks. David Kendall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: T5: Decorating A Service In a Sub Module
I haven't used decoration before, but I'm guessing that even with
decorators you must still provide a service id.
Chris:
Thanks for your reply. As I understand decorators - the service id is
the same as the service it is decorating. This is because a decorator is
a wrapper around a service and implements the same interface as the
service. The calling code doesn't know that it is interacting with a
decorator.
We are using decorators extensively in our code base - but this is the
first time we have multiple decorators on a single service.
Perhaps I am missing something here. If so - maybe you could elaborate
on how the service id should be defined.
In the meantime - I have simplified my code a little in the hopes that
simplicity helps highlight the problem. Here is my current code in the
sub-module - this code never gets executed and consequently - my
decorator code in PageRenderRequestHandlerDecorator is not invoked
either.
public PageRenderRequestHandler
decoratePageRenderRequestHandler(ClassPageRenderRequestHandler
serviceInterace, Object delegateObj) {
PageRenderRequestHandler castDelegate = (PageRenderRequestHandler)
delegateObj;
PageRenderRequestHandlerDecorator decorator = new
PageRenderRequestHandlerDecorator(castDelegate);
return decorator;
}
Is there anyone on this list who does have experience with using
decorators in a sub-module and can tell me what I am doing wrong - or
who can verify this is a bug in T5?
Thanks.
David Kendall
Software Architect
Lithium Technologies
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
T5: Decorating A Service In a Sub Module
I am working on a sizable application where I am trying to decorate the
PageRenderRequestHandler service. I have two modules - a Main Module and
a Sub Module. The Sub Module is loaded using the @SubModule annotation
on the Main Module. Both modules are trying to decorate the
PageRenderRequestHandler
The problem is that I am unable to get tapestry to execute the
decorating code in the SubModule. The sub module decorator looks like
this
public PageRenderRequestHandler decoratePageRenderRequestHandler
(ClassPageRenderRequestHandler serviceInterace,
Object delegateObj {
final PageRenderRequestHandler castDelegate =
(PageRenderRequestHandler) delegateObj;
return new PageRenderRequestHandler() {
public ActionResponseGenerator handle(String
logicalPageName, String[] context) {
// my decorator specific code is removed here
ActionResponseGenerator handle =
castDelegate.handle(logicalPageName, context);
return handle;
}
};
}
Whenever the code is supposed to run - I get the following message
showing up in the log...
Could not add object with duplicate id 'PageRenderRequestHandler'. The
duplicate object has been ignored.
The Main Module decorator is functioning correctly.
The documentation on decorators mentions the putting @Order annotation
on the sub module. However - when I annotate my decorator builder method
with @Order(before:*) or @Order(after:*) - I get the same logging
message and still the Sub Module decorator is not being executed.
Is anyone familiar with how to correctly specify multiple decorators on
a single service? Any help would be appreciated.
Thanks.
David Kendall
Software Architect
Lithium Technologies
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
T5 Decoupling a Template From its Component Class
I am a Tapestry newbie getting up to speed on Tap 5. I am working on an application with extensive co-branding requirements. As I understand things, there is - by default - a tight coupling between a component class name and its template path. For example - if a component has a FQCN of... org.example.myapp.components.CClamp ...then the template has to be on the classpath as org/example/myapp/components/CClamp.html It would be very helpful if the mapping between the component and the template could be decoupled - this would allow me to pull in component templates that have been tweaked for a particular co-brand. For example - I might want to have a template on the class path as org/example/myapp/override/cobrand1/components/CClamp.html Is there any way to do this? Thanks in advance. David Kendall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
