I implemented a much less sophisticated method in my component demo app.
Let me first say that because this is an open library and because T5
itself is still alpha, I have the freedom to use 5.0.7 (or any mutated
version I come up with). Of course my library is intended for
consumption, so in reality I can't use my own Frankenstein version.
The patch I posted is little more than an example of what might be done.
As Howard said, the machinery is already there for this feature, and so
all I did was expose it. I suspect that it (or something like it) will
be accepted, but still, I needed something to work with the actual T5 base.
My situation is quite contained - I can safely assume the page package,
so all I need do is find all classes in that package that constitute
pages. My code:
----
private void loadPages() {
//TODO provide this value somewhere else
String path = "net/godcode/t5c/pages";
ClassLoader cld = Thread.currentThread().getContextClassLoader();
File pagePath = new File(cld.getResource(path).getPath());
if(pagePath == null) {
throw new RuntimeException("Failed to enumerate pages!");
}
File[] pcFiles = pagePath.listFiles(new FilenameFilter() {
public boolean accept(File dir, String name) {
//TODO assuming class-less pages are implemented, we'll
want to
//look for .tml files instead.
if(!name.endsWith(".class") || name.equals("Start.class")) {
return false;
} else {
//Skip inner classes - they are not pages.
return name.indexOf('$') < 0;
}
}
});
for(File f : pcFiles) {
pages.add(f.getName().replaceAll(".class", ""));
}
}
----
I call this method from my start page's constructor. You'll notice some
obvious problems with this method that make it unscalable:
1) It assumes a page package and therefore removes any math needed to
find page packages. Good for controlled situations like mine, but
useless for generic reuse.
2) Class files are assumed to be in an exploded file hierarchy (that is,
not archived in a jar/war but naked in a directory). I can do this
because this app will only showcase apps from the context of a 'mvn
jetty:run' - of course this doesn't work for actual apps. Modifying it
to find classes in jar files would be easy, but its more intelligent to
have the class names provided (which is how I think T5 works).
3) The class loader which loaded the pages is assumed to be the same one
that loads the Start page class. I don't know that this is a safe
assumption...
If you're looking for a more intelligent method that can be plugged in
to 5.0.6, you'll probably have to look in to service decoration:
http://tapestry.apache.org/tapestry5/tapestry-ioc/decorator.html
Good luck :-)
chris
Marcelo Lotif wrote:
Hi Chris,
your solution looks nice. I saw your patch attached to the JIRA issue,
actually you proposed to add a method to the ComponentClassResolver on 5.0.7,
but i can't figure out how I can do this on 5.0.6... how are you doing it?
2007/11/20, Chris Lewis <[EMAIL PROTECTED]>:
I've created a JIRA and included a patch:
https://issues.apache.org/jira/browse/TAPESTRY-1923. I actually had use
for this as well - I'm working on a T5 component lib that includes a
demo app for showcasing the components. I wanted to simply enumerate all
known pages (excluding Start) and create links to them in the start
page. The idea would be that all pages (or perhaps those only in a
certain package) will display a component, so autonomously creating
links to them would prevent me from having to maintain the demo app as
components are added.
Howard Lewis Ship wrote:
Sure add an issue.
... and a patch :-)
Just curious: why do you need to list of all pages?
On Nov 19, 2007 1:14 PM, Marcus <[EMAIL PROTECTED]> wrote:
Hi Howard,
I agree with you, maybe if ComponentClassResolver can have a method
where we can get page names, just when we want?
Thanks,
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
