forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [jira] Commented: (FOR-934) i18n language override menu
Date Fri, 22 Sep 2006 08:54:06 GMT
Sjur Moshagen wrote:
> Den 21. sep. 2006 kl. 12.10 skrev Thorsten Scherler:
> 
>>> 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?

By definition core is not equal to a plugin. More on this at the end.

>> 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.

If it can work like that then I agree it is a good idea, but...

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

No skins are not core features. Core works with XDocs, output plugins 
provide a final format that is not predefined by core. One does not have 
to work with any particular output plugin, one can work directly with 
XDocs, i.e. core.

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

Again, I agree in principle. But will it work...

>> 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?

Yes, that is why plugins were introduced. And (I'm repeating myself), if 
it can work I agree it should be a plugin, but...

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

OK, lets consider..

> 
> One good reason could be that i18n processing cuts across all other 
> processing - irrespective of which plugins you employ, i18n should work. 
> i18n configuration and support should be centralised and available to 
> all plugins. 

...

> Another reason is to ensure proper and systematic support for i18n in 
> all places. Forrest has been a bit patchy when it comes to i18n support, 
> and still is. This makes for a bad user experiense, both for an advanced 
> user developing web solutions with Forrest, and for end users of that 
> web solution. When you need i18n support, you want it to work 
> everywhere, with all plugins and all your documents, in all running 
> environments.

Exactly my thinking. To expand...

The problem with i18n is that it is fundamental to the resolution of 
resources for the *internal* processing of a request. As a result, it 
touches a great many matches in the sitemap.

Now consider that I may want to write an internal plugin that modifies 
some of the internal matches in our pipelines (like the dispatcher). I 
need to ensure that I do not break the i18n behaviour of those matches. 
If they i18n stuff is in core then no problem, I simply override the 
matches I want and handle i18n accordingly.

However, if the i18n handling is in a plugin I have to override those 
matches too which means that we are creating a dependency between the 
two plugins.

Now we have a situation of a plugin developer who is not using the i18n 
features creating a plugin that is likely to break the i18n behaviour 
because they do not address those issues. Furthermore, changes to the 
i18n plugin will result in changes being needed in all internal plugins.

It is true that changes in core i18n handling would also result in the 
need to change internal plugins. But we expect all plugin maintainers to 
monitor core, we do not expect the to monitor all plugins (at least I do 
not expect them to do so).

At least this is how it worked with the *old* i18n implementation. If 
your recent work (which I have not followed closely) removes this 
dependency then this is not a strong enough argument for you to remove 
your -1. Like I said before, I'm +0 for core, -0 for a plugin. If my 
argument above does not stand then go ahead and make the plugin, I trust 
your judgment.

> After some consideration, I would actually say that if any feature 
> should stay in the core and not be made a plugin, it is i18n support.

To generalise that I would suggest, "any feature that works on 
*internal* processes should be part of core. Any feature that touches 
only input or output processes should be plugins."

Internal plugins were only ever intended [1] to allow the handling of 
new formats for internal documents, such as IMS Manifests to site.xml. 
They were not, and in my opinion, should not be intended for core 
functionality.

We can still separate the code by using sitemap mounting, after all, 
that is what an internal plugin does.

Ross

[1] this intention was my own, as as original author, as opposed to the 
community leveraging that code, which has used it to rewrite whole 
chunks of core

Mime
View raw message