Grok Application and content initialization
|
View:
New views
12 Messages
—
Rating Filter:
Alert me
|
 |
Grok Application and content initialization
by Souheil CHELFOUH
::
Rate this Message:
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@... https://mail.zope.org/mailman/listinfo/grok-dev |
|
|
Re: Grok Application and content initialization
by Souheil CHELFOUH
::
Rate this Message:
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@...>: > 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@... https://mail.zope.org/mailman/listinfo/grok-dev |
|
|
Re: Grok Application and content initialization
by Sebastian Ware
::
Rate this Message:
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@...>: >> 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@... > https://mail.zope.org/mailman/listinfo/grok-dev _______________________________________________ Grok-dev mailing list Grok-dev@... https://mail.zope.org/mailman/listinfo/grok-dev |
|
|
Re: Grok Application and content initialization
by Souheil CHELFOUH
::
Rate this Message:
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@...>: > 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@...>: >>> >>> 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@... >> https://mail.zope.org/mailman/listinfo/grok-dev > > Grok-dev mailing list Grok-dev@... https://mail.zope.org/mailman/listinfo/grok-dev |
|
|
Re: Grok Application and content initialization
by Leonardo Rochael Almeida
::
Rate this Message:
The solution I see for this problem is having a way to register a view
for a plain Zope3 installation that adds a grok site and then does the other initializations needed. This way, the user wouldn't be "Adding a Grok Application" to Zope3. he'd be "Adding Your Application", which happens to add a Grok application under the hood and then proceeding to add the other stuff. Cheers, Leo On Thu, Oct 1, 2009 at 11:48, Souheil CHELFOUH <trollfot@...> wrote: > 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@...>: >> 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@...>: >>>> >>>> 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@... >>> https://mail.zope.org/mailman/listinfo/grok-dev >> >> > _______________________________________________ > Grok-dev mailing list > Grok-dev@... > https://mail.zope.org/mailman/listinfo/grok-dev > Grok-dev mailing list Grok-dev@... https://mail.zope.org/mailman/listinfo/grok-dev |
|
|
Re: Grok Application and content initialization
by Souheil CHELFOUH
::
Rate this Message:
That's not what is going on with the current grokui.admin
A generic solution should work with a base grok project, using grokui.admin Well, that's my feeling at least 2009/10/1 Leonardo Rochael Almeida <leorochael@...>: > The solution I see for this problem is having a way to register a view > for a plain Zope3 installation that adds a grok site and then does the > other initializations needed. > > This way, the user wouldn't be "Adding a Grok Application" to Zope3. > he'd be "Adding Your Application", which happens to add a Grok > application under the hood and then proceeding to add the other stuff. > > Cheers, Leo > > On Thu, Oct 1, 2009 at 11:48, Souheil CHELFOUH <trollfot@...> wrote: >> 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@...>: >>> 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@...>: >>>>> >>>>> 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@... >>>> https://mail.zope.org/mailman/listinfo/grok-dev >>> >>> >> _______________________________________________ >> Grok-dev mailing list >> Grok-dev@... >> https://mail.zope.org/mailman/listinfo/grok-dev >> > Grok-dev mailing list Grok-dev@... https://mail.zope.org/mailman/listinfo/grok-dev |
|
|
Re: Grok Application and content initialization
by Sebastian Ware
::
Rate this Message:
I agree that it is a work around, but it isn't a show stopper.
I am more surprised that people accept the fact that you can't add indexes to an existing application. That is at least my biggest gripe with Grok, and the work around requires many steps and is very complicated since it requires recreation of the application and exporting and importing of the entire data structure. This makes the upgrade story seriously flawed in it's current state. Mvh Sebastian On 1 okt 2009, at 11.48, Souheil CHELFOUH wrote: > 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@...>: >> 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@...>: >>>> >>>> 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@... >>> https://mail.zope.org/mailman/listinfo/grok-dev >> >> _______________________________________________ Grok-dev mailing list Grok-dev@... https://mail.zope.org/mailman/listinfo/grok-dev |
|
|
Re: Grok Application and content initialization
by Souheil CHELFOUH
::
Rate this Message:
My idea for the indexes was to work on it in grokui.catalog, a package
I had in mind to add/remove index and purge/reindex catalogs. But that's yet another problem :) I'm very concerned about the actions at an application creation, as it's the very basic first step. About the upgrade, I'll have a deeper look once I solved this problem :) 2009/10/1 Sebastian Ware <sebastian@...>: > I agree that it is a work around, but it isn't a show stopper. > > I am more surprised that people accept the fact that you can't add indexes > to an existing application. That is at least my biggest gripe with Grok, and > the work around requires many steps and is very complicated since it > requires recreation of the application and exporting and importing of the > entire data structure. > > This makes the upgrade story seriously flawed in it's current state. > > Mvh Sebastian > > On 1 okt 2009, at 11.48, Souheil CHELFOUH wrote: > >> 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@...>: >>> >>> 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@...>: >>>>> >>>>> 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@... >>>> https://mail.zope.org/mailman/listinfo/grok-dev >>> >>> > > Grok-dev mailing list Grok-dev@... https://mail.zope.org/mailman/listinfo/grok-dev |
|
|
Re: Grok Application and content initialization
by Roger Erens-2
::
Rate this Message:
On Thu, Oct 1, 2009 at 11:57, Souheil CHELFOUH <trollfot@...> wrote:
> That's not what is going on with the current grokui.admin > A generic solution should work with a base grok project, using grokui.admin > Well, that's my feeling at least I sympathize with you. But such a solution does not seem to be User Interface related, so is grokui the right place to have it in? Cheers, Roger ... >> On Thu, Oct 1, 2009 at 11:48, Souheil CHELFOUH <trollfot@...> wrote: >>> 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@...>: >>>> 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. Grok-dev mailing list Grok-dev@... https://mail.zope.org/mailman/listinfo/grok-dev |
|
|
Re: Grok Application and content initialization
by Souheil CHELFOUH
::
Rate this Message:
As I said previously, the event should be described in grok itself
but, of course, fired in grokui.admin, as the app is added 2009/10/1 Roger Erens <roger.erens@...>: > On Thu, Oct 1, 2009 at 11:57, Souheil CHELFOUH <trollfot@...> wrote: >> That's not what is going on with the current grokui.admin >> A generic solution should work with a base grok project, using grokui.admin >> Well, that's my feeling at least > > I sympathize with you. But such a solution does not seem to be User > Interface related, so is grokui the right place to have it in? > > Cheers, > > Roger > > ... > >>> On Thu, Oct 1, 2009 at 11:48, Souheil CHELFOUH <trollfot@...> wrote: >>>> 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@...>: >>>>> 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. > Grok-dev mailing list Grok-dev@... https://mail.zope.org/mailman/listinfo/grok-dev |
|
|
Re: Grok Application and content initialization
by Jan-Wijbrand Kolman-3
::
Rate this Message:
Souheil CHELFOUH wrote:
> As I said previously, the event should be described in grok itself > but, of course, fired in grokui.admin, as the app is added To me, this sound as good solution: have grokui.admin fire the event after it has created *and added* the application object to a container (the zope root in this case). I could be a bit strange at first to find an event type defined in grok that inside grok itself is not used, but I do not think this is a real problem. Should not be hard to add to grok and grokui.admin I guess. And since we created maintenance branches already, people can "freely" go ahead and add new features to the trunk. regards, jw _______________________________________________ Grok-dev mailing list Grok-dev@... https://mail.zope.org/mailman/listinfo/grok-dev |
|
|
Re: Grok Application and content initialization
by Martijn Faassen-2
::
Rate this Message:
Hey Souheil,
Sorry for being late in responding to this. It is indeed a very important topic. > 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 ? I'm +1 on sending an ApplicationInitializedEvent after the ObjectCreatedEvent. We can then document people should use this if they want code to run after the application is installed. I agree it shouldn't be in grokui.base but in Grok itself, as any method of installing the application would work independently of which admin tool is used. I'd be very happy to see you work on this. Looking forward to code, tests and docs. (the developer's notes in the official docs are a good place for now). Regards, Martijn _______________________________________________ Grok-dev mailing list Grok-dev@... https://mail.zope.org/mailman/listinfo/grok-dev |
| Free embeddable forum powered by Nabble | Forum Help |
