[Grok-dev] Grok Application and content initialization

Souheil CHELFOUH trollfot at gmail.com
Thu Oct 1 05:48:59 EDT 2009

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

More information about the Grok-dev mailing list