[Freeipa-devel] [PATCH] 106 I18n update.

[Adam Young]

On 02/18/2011 11:48 PM, Endi Sukma Dewata wrote:
> On 2/18/2011 10:35 PM, Adam Young wrote:
>>>>>> Hard-coded messages through out the code have been replaced by i18n
>>>>>> messages obtained from json_metadata and i18n_messages.
>>>>>>
>>>>>> https://fedorahosted.org/freeipa/ticket/899
>>>>>>
>>>>> Needs rebase, due to mkosek's big patch.
>>>>
>>>> Attached is an updated version. I had to change IPA.cert into an 
>>>> entity
>>>> because it has to be initialized after IPA.init() finishes loading the
>>>> metadata & messages.
>>>>
>>>> We might want to introduce a concept of plugin for Web UI (similar to
>>>> plugin for ipalib). The first step is to rename IPA.entity_factories
>>>> into IPA.plugins, but most of the work will be splitting the 
>>>> IPA.entity
>>>> into plugin and real entity.
>>>>
>>>> Patch #107 can be used without rebase.
>>>
>>> Attached is a new version using the plugin framework. Please see
>>> certificate.js.
>>>
>> Every function is an Object. There is no reason to create an object, and
>> then have an init method on it.
>
> I haven't got a chance to provide a long explanation for this, but 
> please try to apply all patches that I've submitted (until 109) and 
> see the user.js, group.js and certificate.js. I think they are clearly 
> structured and easy to understand.
>
> Try to think "plugins" as "modules", and "init()" as "start()" or 
> "main()", or some other terms. Once all entity files are converted to 
> use this framework, it maybe possible to remove init() from 
> entity/facet/widget. The init() is not an unnecessary duplication of 
> constructor, but it's a callback to indicate that the messages are 
> loaded.
>

OK, just completed a more in depth review.  I stand by my origianl 
call.  I don't want to make a change like this in the 2.0 timeframe.  
When we do make the change, it will incorporate some of these ideas, but 
we are not going to use the deliberate init() call.


For now, just make the  libraries for cert etc as lazy load accessors 
like I recommended earlier.  It should be a pretty short addition to 
Patch 106-2.  Hold on to the changes from patches 106-3 on and we will 
design a more complete refactoring target for the 2.1 release.