Re: [Grok-dev] Grok-dev Digest, Vol 89, Issue 2
0 views
Skip to first unread message
Paul Sephton
Sep 21, 2015, 8:26:56 AM9/21/15
to grok...@zope.org
On 9/21/2015 12:00 PM,
grok-dev...@zope.org wrote:
Ha Ha, I appreciate your comments!By the gods! Where were you two years ago when I was trying to learn Grok!?
I have found grok to be an amazing RAD tool for two reasons:
a) It provides you with all the power of the Zope Component Framework (ZCF) without the pain of having to use ZCML (Zope Config XML) andI refuse to be an apologist for the ZCF- it's an amazing achievement by some great Python coders, and well worth learning even if you never use grok. I think a lot of peoples gripe with the ZCF was due to the use of ZCML for site configuration for Zope-3, and I don't really think Pyramid gains a whole lot by hiding the ZCF from developers.
b) It's just so easy to adapt existing code as requirements change
Anyway, thanks and good luck,
Paul
Paul Sephton
Sep 26, 2015, 5:31:45 AM9/26/15
to Christopher Lozinski, Grok Development
On 9/25/2015 9:00 AM, Christopher Lozinski wrote:
> Great Question.
>
> I don't use local or global utilities much so I went ahaed and reread
> the documentation.
> And leanred something in the process.
That's really surprising to hear, given your work in porting the Zope 2
ZMI. I found the structure of the site fascinating. I thought you must
be a boffin on local utilities to accomplish what you did.
> I do use a PAU Pluggable authentication local utility. And also
> component registration but the latter I do not notice.
The problem I have been working on, is that the grok.local_utility
directive does not work if you introduce it after the fact to an already
installed and live application. This is more than a slight irritation
if your site already has data which you want to keep, and you want to
add authentication later.
> I would like to have multiple PAU. Maybe not yet. But I do not quite
> know how all of registration works.
Ok, now that I have got it all going I can help with that. I will be
documenting it in my wiki's data soon.
> Philosophically I like to think of zodb as a graph of objects, indexed
> as a tree. One should be able to browse the tree
> and see a viaual representation of the object. So there should be a
> default HTML GUI on local utilities. What I did was I accessed
> the PAU using ++etc++site, although I cannot get that command to work
> this morning. And I moved it over to my main tree.
AFAIK you can do that manually from inside the bin/interactive_debugger,
but not from the ZMI any more, since the ZMI is so stripped down. Grok
1.0 had an interactive explorer mode, but that was removed.
> I read your code line by line. The second time, after reading the
> manual it all made sense to me.
>
> This should not be that hard to debug. In getUtility or query utility
> add a pdb, and see why the global utility is being
> returned before the local utility.
You know what they say? that assumption is the mother of all ...???
Well, I had assumed that if I register a named local utility, that a
normal queryUtility() without specifying the name would find it by
preference over the global utility.
In reality, all utilities are named- the default name being an empty
string. So queryUtility() when given a name finds that utility by name,
but if not given a name, queryUtility() finds the matching utility with
a name of an empty string.
A named utility cannot be located using queryUtility() unless a name is
specified as an argument.
The queryUtilitiesFor(<interface>) can find all registered utilities
regardless of name.
> <snip>
> I hope that helps. I certainly leanred a lot in replying.
>
> I forget where you are located. Are you interested in a grok sprint?
Thanks for your help. It is always useful to talk to another warm
blooded intelligence, even as a sounding board.
I am afraid sprints are aout for me. I am located in South Africa :-(
> On 9/25/15 8:08 AM, Paul Sephton wrote:
>> So, have you delved into manually installing local utilities at all?
>> The grok.local_utility() directive only works when installing an app
>> for the first time. Really limiting.
>>
>> I would like to figure an easy way to do this without things going
>> completely awry.
>>
>> Currently I have: (context is an ISite)
>>
>> def registerUtility(self, factory, provided, name='', setup=None):
>> ''' Register a new local utility with the site. If it already
>> exists
>> we remove the old one first
>> '''
>>
>> sm = self.context.getSiteManager()
>>
>> old = sm.queryUtility(provided, name=name)
>> if old is not None:
>> sm.unregisterUtility(provided=provided, name=name)
>> if name in sm: del sm[name]
>>
>> try:
>> obj = factory()
>> except:
>> obj = factory
>>
>> sm[name] = obj
>> sm.registerUtility(obj, provided=provided, name=name)
>> if setup: setup(obj)
>>
>> ...but that doesn't quite cut it. I did get it working once, but I
>> forget what I did to do so.
>>
>> With the above, the local utility installs, but the global utility
>> takes precedence.
>>
>> Regards
>> Paul
>>
_______________________________________________
Grok-dev mailing list
Grok...@zope.org
https://mail.zope.org/mailman/listinfo/grok-dev
> Great Question.
>
> I don't use local or global utilities much so I went ahaed and reread
> the documentation.
> And leanred something in the process.
That's really surprising to hear, given your work in porting the Zope 2
ZMI. I found the structure of the site fascinating. I thought you must
be a boffin on local utilities to accomplish what you did.
> I do use a PAU Pluggable authentication local utility. And also
> component registration but the latter I do not notice.
The problem I have been working on, is that the grok.local_utility
directive does not work if you introduce it after the fact to an already
installed and live application. This is more than a slight irritation
if your site already has data which you want to keep, and you want to
add authentication later.
> I would like to have multiple PAU. Maybe not yet. But I do not quite
> know how all of registration works.
Ok, now that I have got it all going I can help with that. I will be
documenting it in my wiki's data soon.
> Philosophically I like to think of zodb as a graph of objects, indexed
> as a tree. One should be able to browse the tree
> and see a viaual representation of the object. So there should be a
> default HTML GUI on local utilities. What I did was I accessed
> the PAU using ++etc++site, although I cannot get that command to work
> this morning. And I moved it over to my main tree.
AFAIK you can do that manually from inside the bin/interactive_debugger,
but not from the ZMI any more, since the ZMI is so stripped down. Grok
1.0 had an interactive explorer mode, but that was removed.
> I read your code line by line. The second time, after reading the
> manual it all made sense to me.
>
> This should not be that hard to debug. In getUtility or query utility
> add a pdb, and see why the global utility is being
> returned before the local utility.
You know what they say? that assumption is the mother of all ...???
Well, I had assumed that if I register a named local utility, that a
normal queryUtility() without specifying the name would find it by
preference over the global utility.
In reality, all utilities are named- the default name being an empty
string. So queryUtility() when given a name finds that utility by name,
but if not given a name, queryUtility() finds the matching utility with
a name of an empty string.
A named utility cannot be located using queryUtility() unless a name is
specified as an argument.
The queryUtilitiesFor(<interface>) can find all registered utilities
regardless of name.
> <snip>
> I hope that helps. I certainly leanred a lot in replying.
>
> I forget where you are located. Are you interested in a grok sprint?
Thanks for your help. It is always useful to talk to another warm
blooded intelligence, even as a sounding board.
I am afraid sprints are aout for me. I am located in South Africa :-(
> On 9/25/15 8:08 AM, Paul Sephton wrote:
>> So, have you delved into manually installing local utilities at all?
>> The grok.local_utility() directive only works when installing an app
>> for the first time. Really limiting.
>>
>> I would like to figure an easy way to do this without things going
>> completely awry.
>>
>> Currently I have: (context is an ISite)
>>
>> def registerUtility(self, factory, provided, name='', setup=None):
>> ''' Register a new local utility with the site. If it already
>> exists
>> we remove the old one first
>> '''
>>
>> sm = self.context.getSiteManager()
>>
>> old = sm.queryUtility(provided, name=name)
>> if old is not None:
>> sm.unregisterUtility(provided=provided, name=name)
>> if name in sm: del sm[name]
>>
>> try:
>> obj = factory()
>> except:
>> obj = factory
>>
>> sm[name] = obj
>> sm.registerUtility(obj, provided=provided, name=name)
>> if setup: setup(obj)
>>
>> ...but that doesn't quite cut it. I did get it working once, but I
>> forget what I did to do so.
>>
>> With the above, the local utility installs, but the global utility
>> takes precedence.
>>
>> Regards
>> Paul
>>
_______________________________________________
Grok-dev mailing list
Grok...@zope.org
https://mail.zope.org/mailman/listinfo/grok-dev
Reply all
Reply to author
Forward
0 new messages