forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thorsten Scherler <>
Subject Re: [jira] Commented: (FOR-934) i18n language override menu
Date Thu, 21 Sep 2006 09:10:31 GMT
On Wed, 2006-09-20 at 16:42 +0100, Ross Gardler wrote:
> Sjur Moshagen wrote:
> > Den 20. sep. 2006 kl. 17.00 skrev Thorsten Scherler (JIRA):
> > 
> >>     [ 
> >> 
> >> ]
> >>
> >> Thorsten Scherler commented on FOR-934:
> >> ---------------------------------------
> >>
> >> I had a quick look at the patch and it would make a good plugin.
> >>
> >> Since the dispatcher contract is only a small part of the overall code 
> >> and the code is not limited to the dispatcher it makes sense to create 
> >> a plugin out of it.
> >>
> >> wdyt?
> > 
> > Sure, that way I guess it would be available both to dispatcher and 
> > non-dispatcher users. One could argue that this i18n-functionality 
> > should really be part of the core, to make the i18n services of Forrest 
> > complete, though.
> I've not been following the i18n discussions, but I have to admit that 
> when I saw Thorstens comments I wondered "why not core?".
> I'm not doing the work on this so do it however you like. But if you 
> want my (possibly uninformed) opinion then I'd say core is the right place.

Hmm, after all the feature contains a dispatcher contract. Further who
said core cannot be in a plugin? 

I think we should split the *whole* core into plugins, that will help to
refactor and simplify the code. Now we have spread the e.g. i18n code
all over our core. Ugly for understanding, ugly to maintain.

We already agreed that we would need a skin plugin as well, which is as
well a core feature, or? 

IMO *everything* should go into plugins and the core would be just a
couple of sitemaps. Maybe we should restructure the locations for
tree $FORREST_HOME/plugins
|-- core
|-- incubator (the plugins from the whiteboard)
`-- optional

Starting an i18n plugin and move all code to there has much more
benefits (keeping documentation and code releated to i18n in one place)
and this is why we introduced plugins in the first place, or?

So I am -1 to put it in the core, as long someone names a *good* reason
to put it in core?

Thorsten Scherler
COO Spain
Wyona Inc.  -  Open Source Content Management  -  Apache Lenya               

View raw message