cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Baptiste Quenot (JIRA)" <j...@apache.org>
Subject [jira] Closed: (COCOON-1379) [i18n] extending the I18nTransformer
Date Wed, 11 Oct 2006 07:25:20 GMT
     [ http://issues.apache.org/jira/browse/COCOON-1379?page=all ]

Jean-Baptiste Quenot closed COCOON-1379.
----------------------------------------

    Fix Version/s: 2.2-dev (Current SVN)
       Resolution: Fixed
         Assignee:     (was: Cocoon Developers Team)

I think we can close this one now.

> [i18n] extending the I18nTransformer
> ------------------------------------
>
>                 Key: COCOON-1379
>                 URL: http://issues.apache.org/jira/browse/COCOON-1379
>             Project: Cocoon
>          Issue Type: Improvement
>          Components: * Cocoon Core
>    Affects Versions: 2.2-dev (Current SVN)
>         Environment: Operating System: All
> Platform: All
>            Reporter: Christoph Gaffga
>            Priority: Minor
>             Fix For: 2.2-dev (Current SVN)
>
>         Attachments: AbstractI18nTransformer.java, I18nTransformer.java
>
>
> copy of my mail to dev@cocoon.apache.org:
> -----------------------------------------
> (see source attached)
> recently I needed to extend cocoon's I18nTransfomer for loading multiple  sets
> of catalogues for different pipelines. The information what catalogues form a
> set, which sets to use for the different pipelines was stored in DB. So I had to
> change a lot and recognized that it is quite difficult for me to extend the
> existing I18N transformer.
> The Idea was, whenever cocoon's I18N transformer is enhanced with some more
> functionallity, my new transfomer should support the features too.
> With the existing I18nTransformer class this seems not to be possible. So my
> Idea was to move all the stuff doing the real transformations, implementing the
> logic for the i18n:*-Elements and doing lookups in the catalugues to an abstract
> class called AbstractI18nTransformer. 
> Now the cocoon I18nTransformer extends this class and implements only the logic
> for loading the right catalogues as configured in the sitemap,  mainly the
> setup(..) and configure(..) methods and the Cachable interface are implemented here.
> Like this I have a nice separation between the real transforming part and the
> part loading and configuring the catalogues. Now I can simply extend this
> AbstractI18nTransformer and add my own catalogue loading logic. 
> Coming back to my point that I want to have enhancments to the I18n functions
> also in my transfomer without editing my code again and again:  My separation of
> the two parts of the I18n transfomer only makes sense if there is some interest
> in having this AbstractI18nTransformer integrated into cocoon.
> So I'd like to know if there is some interest in having this change integrated
> into cocoon. 
> I sent my example how this separation could be done as an enhancement to the
> bugzilla. Would be nice to hear some thoughts about the idea.
> kind regards,
> Christoph Gaffga
> cgaffga@triplemind.com

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message