Chris is right, ComponentClassResolver is the service that "knows" the pages, and could easily provide a list of pages.
I do have a concern that in the future, we may become a bit more "dynamic" about what pages are available; i.e., pages with templates but no Java class, or pages created from the aether (i.e., to support some of the things Trails does in T4). I'm sure I'll be able to come up with something reasonable. On Mon, Apr 14, 2008 at 2:16 PM, Chris Lewis <[EMAIL PROTECTED]> wrote: > The problem with this approach is that it doesn't address any other page > packages that may have been added via other modules (in the same manner > that additional component packages can be added). > The idea of copying what ComponentClassResolverImpl does would be the > 'correct' method, and an extension to the API was request some time ago > to expose this as a legitimate feature. See: > https://issues.apache.org/jira/browse/TAPESTRY-1923. There's a patch > included that extends the interface as well as implements it. Hopefully > this will make it in... > > chris > > > > Marcus wrote: > > Hi Angelo, > > > > - get ContextClassLoader from current Thread > > - get path of your pages package (org.exemplo.teste.pages) from ClassLoader > > - get files on this path that ends with ".class", skiping inner classes. > > > > I think this topic already has been discussed here. > > > > Marcus. > > > > > > -- > http://thegodcode.net > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
