Well, i was assuming that you had a "tapestry" solution for this problem
but, although it is a hardcoded solution, it works well. I will try your
suggestion about adding a service decorator.

Thank you a lot!

2007/11/20, Chris Lewis <[EMAIL PROTECTED]>:
>
> 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]
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
>


-- 
Atenciosamente,
Marcelo Lotif

Reply via email to