Hm, yes. Of course, "libID:pageName" should not really be a literal You can, for example, list all child-Namespace-IDs from your-app namespace, then load the pages and look for one that implements your interface, or always look for a page named "Home", or whatever.
> -----Original Message----- > From: Eckenfellner Klaus [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 24, 2007 8:26 AM > To: Tapestry users > Subject: Re: component export message properties to global / > application catalog > > the libId (which equals namespaceId) is set in the > application-specification (or library-specification if > library is used in library). so if i would hard-code > cycle.getPage("libId:pageName") in my border-component (which > is also a own library), i would get a problem if anyone would > make a typo in the application-specification. > > the next reason is, that i couldn't know to compile-time > which libraries > (plugins) to use, because they could be plugged in / out dynamically. > also a aspect is, that third-party developers should be able > with "zero investment in time" to write own plugin. > > therefore i decided to do something like i posted yesterday > (http://mail-archives.apache.org/mod_mbox/tapestry-users/20070 > 7.mbox/raw/[EMAIL PROTECTED]/) > > are there any other alternatives? > > [EMAIL PROTECTED] wrote: > > Hm, you could do cycle.getPage("libID:pageName") in your > > nav-component, couldn't you? > > > >> -----Original Message----- > >> From: Eckenfellner Klaus [mailto:[EMAIL PROTECTED] > >> Sent: Monday, July 23, 2007 10:58 AM > >> To: users@tapestry.apache.org > >> Subject: Re: component export message properties to global / > >> application catalog > >> > >> maybe you can tell me how to initialize all my plugin libraries > >> (which are tapestry component libraries) before the first > request?! > >> because the behavior that library - specifications are > only parsed if > >> the are needed is tapestry default mechanism. i wasn't > able to find > >> any configuration or service which could help me. > >> > >> [EMAIL PROTECTED] wrote: > >>> I see, but why can't you initialise all your plugin libs upon the > >>> first request? > >>> Does this really hurt a lot performance-wise? Sorry, but I'm just > >>> being curious ... > >>> > >>> > >>>> -----Original Message----- > >>>> From: Eckenfellner Klaus [mailto:[EMAIL PROTECTED] > >>>> Sent: Friday, July 20, 2007 11:56 AM > >>>> To: users@tapestry.apache.org > >>>> Subject: Re: component export message properties to global / > >>>> application catalog > >>>> > >>>> sorry my fault .... > >>>> > >>>>> you should be able to access your components > msg-catalog from the > >>>>> navigation/border-component via IComponent.getMessages() > >> Does that > >>>>> help? > >>>> plugins are realized as !!! component-libraries !!!. > >> problem is that > >>>> library-resources (library-global-catalog and > >>>> specification) are parsed the first time the library is used. > >>>> > >>>> but in my navigation solution i need the translation > >> BEFORE any of my > >>>> library-information is parsed, exceptionally the > >> border-library which > >>>> includes THE navigation logic. > >>>> > >>>> therefore IComponent.getMessages() doesn't work for me. > >>>> > >>>>> Also, you components/pages could be required to implement some > >>>>> interface Named {getDisplayName(Locale);} > >>>> already done, but also not useful for this case ... reason > >> see above. > >>>> any other suggestions? > >>>> > >>>> --- > >>>> > >>>> [EMAIL PROTECTED] wrote: > >>>>> you should be able to access your components > msg-catalog from the > >>>>> navigation/border-component via IComponent.getMessages() > >> Does that > >>>>> help? > >>>>> Also, you components/pages could be required to implement some > >>>>> interface Named {getDisplayName(Locale);} > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Eckenfellner Klaus [mailto:[EMAIL PROTECTED] > >>>>>> Sent: Friday, July 20, 2007 10:30 AM > >>>>>> To: users@tapestry.apache.org > >>>>>> Subject: component export message properties to global / > >>>> application > >>>>>> catalog > >>>>>> > >>>>>> hi everybody! > >>>>>> > >>>>>> short description of my application: > >>>>>> my application uses tapestry components to create some > >>>> dynamic plugin > >>>>>> behavior. tapestry components can be plugged in and are > >> registered > >>>>>> with the help of a configuration-point (hint from > marcus schulte > >>>>>> thx). > >>>>>> > >>>>>> every plugin / component contribute to configuration-point > >>>> a pageName > >>>>>> and displayName of page. another component (most > called border) > >>>>>> injects information of configuration point and renders > >>>> some kind of > >>>>>> navigation bar. > >>>>>> > >>>>>> and here is my problem.... > >>>>>> > >>>>>> the attribute displayName tells me how the page is called. > >>>>>> this value is > >>>>>> key for i18n - message. problem is, that only the > components, > >>>>>> which contribute to configuration-point, knows the > >>>> translation. for > >>>>>> example: > >>>>>> only the login component know how login is called in EN / > >>>> DE / FR .... > >>>>>> but the message information of the specific component > >> (for example > >>>>>> login) is not available for the border component > (which renders > >>>>>> navigation). > >>>>>> > >>>>>> I need some mechanism to export messages to > Application Catalog. > >>>>>> does anybody have any idea? > >>>>>> > >>>>>> thx > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >> > --------------------------------------------------------------------- > >>>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>>>> > >>>>>> > >>>> > >>>> > >> > --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>>> > >>>> > >> > >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
