Re: [Zope-CMF] Portal users and some other stuff
Am 15.01.2007 um 14:55 schrieb Charlie Clark:
tal:content="python: mtool.getMemberById(creator).getProperty
('fullname')"
aagh - this only works if you have permission for getMemberById but I
want to globally replace "creator", ie. acl_user with "fullname" in
contentByLine. Do I need to create an "action" for this in
portal_memberdata?
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Portal users and some other stuff
Am 12.01.2007 um 10:13 schrieb Jens Vagelpohl:
All you need to do is to add the desired property to the list of
properties in the member data tool, and then extend the preferences
form and its handlers with your new property (untested off the top
of my head).
FWIW
while that is really straightforward, getting at the property
elsewhere (such as content byline) proved a bit of a challenge as the
creators are returned as a list of strings rather than membership
objects so
creator/fullname is not possible instead
tal:content="python: mtool.getMemberById(creator).getProperty
('fullname')"
is required. Posting to the list for reference purposes.
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Portal users and some other stuff
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12 Jan 2007, at 12:26, Charlie Clark wrote:
Am 12.01.2007 um 10:13 schrieb Jens Vagelpohl:
That's a matter of taste. I like explicit, so I prefer the
existing method.
Explicit is better than implicit but I don't see what's wrong with
having an explicit list of fields through which to loop, as long as
the call is the same as this reduces typos and makes things easier
to manage. Of course, exposing all attributes by allowing __get__
to be the same as getattr can cause problems for objects that are
not simply based on dictionaries.
You don't need to tell me this, it's a matter of taste and if you
want to do something different in your code please do it :) If
you're arguing that the CMF should be changed in this regard than I
can't help thinking that this is a whole lot of discussion for a tiny
minute detail and there's a lot more important things that could need
help and fixing.
I was initially confused that the context was the same as the
instance of my content-type and didn't support this as I use this
idiom quite frequently to reduce my typos. Is this too much of an
edge case to warrant the extension in general (but I'm free to do
it myself) or perhaps an outdated methodology?
I'm not sure what this paragraph means.
It was quite late...
In PythonScripts I quite often use
context.get('objectname') rather than context.objectname for
anything programmatic. It seems to me that there is a case for
making certain attributes of content-types available via get so
that dispatching can be used where appropriate.
I have a feeling this is another case of personal preference that
really doesn't make any difference in real life, don't you think? See
above.
If you have excess programming energy I'd love you to look at open
CMF collector issues and take on some of them, instead of debating
small details ;)
jens
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFFp3HrRAx5nvEhZLIRAsnoAJ9kgf1kiGPzvSxeJupSFgCiXHJQ1wCdHVX7
uoOh8xK8X3mbFGs2RJOTvnY=
=2DSu
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Portal users and some other stuff
Am 12.01.2007 um 10:13 schrieb Jens Vagelpohl:
That's a matter of taste. I like explicit, so I prefer the existing
method.
Explicit is better than implicit but I don't see what's wrong with
having an explicit list of fields through which to loop, as long as
the call is the same as this reduces typos and makes things easier to
manage. Of course, exposing all attributes by allowing __get__ to be
the same as getattr can cause problems for objects that are not
simply based on dictionaries.
I was initially confused that the context was the same as the
instance of my content-type and didn't support this as I use this
idiom quite frequently to reduce my typos. Is this too much of an
edge case to warrant the extension in general (but I'm free to do
it myself) or perhaps an outdated methodology?
I'm not sure what this paragraph means.
It was quite late...
In PythonScripts I quite often use
context.get('objectname') rather than context.objectname for anything
programmatic. It seems to me that there is a case for making certain
attributes of content-types available via get so that dispatching can
be used where appropriate.
If I need to add attributes to portal users such as their full
name, is it best to customise the member object for my site or to
use a plugin?
All you need to do is to add the desired property to the list of
properties in the member data tool, and then extend the preferences
form and its handlers with your new property (untested off the top
of my head).
Thanks. Works as expected.
Charlie
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
Re: [Zope-CMF] Portal users and some other stuff
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11 Jan 2007, at 23:28, Charlie Clark wrote:
For the necessary forms, at least based on the CMF Event code, it
seems to me that code like
options['title'] = form.get('title', context.Title())
options['text'] = form.get('text', context.text)
options['text_format'] = form.get('text_format', context.text_format)
options['headline'] = form.get('headline', context.headline)
options['teaser'] = form.get('teaser', context.teaser)
options['category'] = form.get('category', context.category)
options['keywords'] = form.get('keywords', context.keywords)
options['resources'] = form.get('resources', context.resources)
could be optimised in the context could be treated as a dictionary
object, ie. supported get.
That's a matter of taste. I like explicit, so I prefer the existing
method.
I was initially confused that the context was the same as the
instance of my content-type and didn't support this as I use this
idiom quite frequently to reduce my typos. Is this too much of an
edge case to warrant the extension in general (but I'm free to do
it myself) or perhaps an outdated methodology?
I'm not sure what this paragraph means.
If I need to add attributes to portal users such as their full
name, is it best to customise the member object for my site or to
use a plugin?
All you need to do is to add the desired property to the list of
properties in the member data tool, and then extend the preferences
form and its handlers with your new property (untested off the top of
my head).
jens
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)
iD8DBQFFp1FTRAx5nvEhZLIRAh+FAJ4h+rwjQddNZmgQxC9VR5YM/mIbkACfdApq
C7k1wHBdfTuf4BUvHoIqRe0=
=oxjF
-END PGP SIGNATURE-
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
[Zope-CMF] Portal users and some other stuff
Hi,
my shiny new content type is now working pretty much as expected.
Thanks to Tres and Jens for pointing me in the right direction and
giving me encouraging nudges.
For the necessary forms, at least based on the CMF Event code, it
seems to me that code like
options['title'] = form.get('title', context.Title())
options['text'] = form.get('text', context.text)
options['text_format'] = form.get('text_format', context.text_format)
options['headline'] = form.get('headline', context.headline)
options['teaser'] = form.get('teaser', context.teaser)
options['category'] = form.get('category', context.category)
options['keywords'] = form.get('keywords', context.keywords)
options['resources'] = form.get('resources', context.resources)
could be optimised in the context could be treated as a dictionary
object, ie. supported get.
ie.
attrs = ['headline', 'teaser', 'category']
optins = {}
# assign attributes that do not require additional processing
for attr in attrs:
options[attr] = form.get(attr, context.get(attr))
# attributes that need special treatment...
I was initially confused that the context was the same as the
instance of my content-type and didn't support this as I use this
idiom quite frequently to reduce my typos. Is this too much of an
edge case to warrant the extension in general (but I'm free to do it
myself) or perhaps an outdated methodology?
If I need to add attributes to portal users such as their full name,
is it best to customise the member object for my site or to use a
plugin?
--
Charlie Clark
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-938-5360
GSM: +49-178-782-6226
___
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
