sorry but there is a mistake in my handling. getting the page from
requestCycle and storing information in list is not correct because all
visitors would have the same translation.
correct handling is to store page name in list and border-component
fetches page informations every request from requestCycle ... then all
visitors have the correct translation.
Eckenfellner Klaus wrote:
> found the following solution to my problem...
>
> my border component needs a list of pages. pages are needed to get i18n
> which are only stored in the several libraries. for that purpose i wrote
> a little inferface, which is implemented for every page which is
> startpage of my plugins (libraries).
>
> public interface ModuleMasterPage
> {
> public String getModuleMessage();
> public int getPriority();
> }
>
> but how i get references to pages? there is a
> applicationStateObject(this is injected by border component and holds
> list of pages) which is created with the help of a factory. the factory
> looks like this:
>
> 1. get all libraryIds with : this.getApplicationSource().getLibraryIds()
> 2. libraryId is used to create path: String path =
> this.getApplicationSource().getLibrarySpecificationPath(libraryId);
> 3. path is used to create resource: ClasspathResource resource =
> this.getResourceFactory().newResource(path);
> 4. parse specification ILibrarySpecification specification =
> this.getSpecificationParser().parseLibrarySpecification(resource);
> 5. determine which page is startPage, this information is stored in meta
> property: String moduleMasterPage =
> specification.getProperty(MODULE_MASTER);
> 6. get page from requestcycle: IPage page =
> this.getRequestCycle().getPage(libraryId + ":" + moduleMasterPage);
> 7. check if page is really a modulemaster page: if(page != null && page
> instanceof ModuleMasterPage)
> 8. add page to list
> 9. return list (= ApplicationStateObject)
>
> is there anything bad on my handling? would be thankful for any response.
>
> [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: [email protected]
>>> 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: [email protected]
>>>>> 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]
