[Grok-dev] New grokcore for messages

Christian Klinger cklinger at novareto.de
Tue Mar 2 07:10:02 EST 2010


Hey Souheil,

i like this idea very much.

I think the main problem with the "flash message" and the 
application_url method in grok is that these two methods
are only definied in grok itself. This means if you work on a
megrok.* addon which has a grok.View like functionality, for example
a Table or a Form, you always have to depend on grok itself,
to get these functionalities in your addon.

With the help of grokcore.message you can depend on this small
package to get the functionality. It will help to hold the
dependencies small.

Christian


> Hello Grokkers,
>
> Uli and I have been discussing the current state of grokui and we can
> to an agreement :
> The current dependency of grok upon grokui to register the flash
> message machinery is not a good thing.
> Currently, megrok.layout>= 1.0 is providing a way to register the
> same utilities, which is also not a good thing.
> Our idea is to externalize the message machinery, actually the
> registration of z3c.flashmessage utilities into an independant
> package.
> This, according to us, could go inside a new grokcore package. It's a
> very light codebase, since all it does is to register the utilities.
> But, if we ever move away from z3c.flashmessage to, say use a new
> package or cook our own, we'll have a central place with an API we can
> keep stable.
> There, I'd like to start the package "grokcore.messages" and I'd like
> Grok gurus' opinions, objections or input, to try, sort this situation
> and come up with the most acceptable solution !
>
> cheers,
> - Souheil




More information about the Grok-dev mailing list