[Grok-dev] Grok Application and content initialization

[Souheil CHELFOUH]

Yes, ok, but, don't you agree that we need a generic solution ?
This is a real issue. Having to run things by hand is not a solution
for me, it's a work around.
If I distribute a grok project, I'd rather have that automatized to
avoid telling the user to run the things by hand himself

2009/10/1 Sebastian Ware <sebastian at urbantalk.se>:
> I put my app init code in an init view that I run manually once after
> creating an app. That way I don't experience this problem.
>
> Mvh Sebastian
>
> On 1 okt 2009, at 11.31, Souheil CHELFOUH wrote:
>
>> Hello Grokkers,
>>
>> Well, I'd appreciate ANY opinions and reactions on this.
>> This is an important matter an it has to be discussed.
>> *takes his club out*
>>
>>
>>
>> 2009/9/29 Souheil CHELFOUH <trollfot at gmail.com>:
>>>
>>> Hello Grokkers !
>>>
>>> As i'm currently pushing my troll hands deep into grokui's guts, a
>>> couple of issues I wanted to fix now require some attention. The most
>>> annoying one is about the init of a Grok Application. I'll try to
>>> summarize the problem :
>>>
>>> Currently, when one adds a Grok Application, indexes and local
>>> utilities are created using an event subscriber plugged on
>>> IObjectAddedEvent. However, if one wants to add any content inside the
>>> Application during the creation process, there is a very high
>>> probability that he will use the same event (the only useable and
>>> reliable one) and his event subscriber has a very high probability to
>>> be fired BEFORE the indexes and the local utilities ones. It means
>>> that the content created by his subscriber won't be cataloged, nor
>>> added to the IntIds utility, etc...
>>>
>>> This situation is very annoying, since the creation of content as the
>>> site creation is a fairly common usecase (yes... one of mine, you've
>>> got it). I propose the creation of a new event we could call
>>> ApplicationInitializedEvent, for instance, and that would be fired
>>> AFTER the ObjectCreatedEvent. This would permit a more flexible
>>> handling of the different application statuses => instanciated,
>>> persisted, ready to be used. Obviously, this can't be plugged in
>>> grokui.base, it belongs to Grok itself. What do you guys think ?
>>>
>>> - Souheil 'Trollfot'
>>>
>> _______________________________________________
>> Grok-dev mailing list
>> Grok-dev at zope.org
>> https://mail.zope.org/mailman/listinfo/grok-dev
>
>