+):(.+)')
I propose to extend this to allow the '-' character too.
Any objections to this?
Are there any other characters that should be included?
Do any specifications need changing?
--
Steve Alexander
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http
and path('%s/%s' (base, x))
I don't understand this example.
I see that there's meant to be a '%' operator in there.
But, I don't understand what use of the name of a namespace as a
function in a Python expression means, and I see only the function
'path' above.
--
Steve Alexander
in some simple systems it is good to conflate the concepts of
user and principal. Making the principal available from the request
in zope3 encourages this. But, I think that it is not good application
design, and it does not make for clear abstractions.
--
Steve Alexander
Shane Hathaway wrote:
Steve Alexander wrote:
In Launchpad, request.principal is not used by the application
programmers. It is used only by the authentication, authorization and
publication machinery. The machinery looks up a Person (an application
domain object) for the current principal
of their application.
--
Steve Alexander
[1] Desperately trying to avoid using the term user there.
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
of implicit. I'd rather see a first class
User concept.
--
Steve Alexander
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
If not that, we can at least make the weaker case that no Zope 3 *UI*
user (whether it's the ZMI or something built on top of it) ordinarily
should have to know about 'principals'.
I agree with that.
--
Steve Alexander
___
Zope3-dev mailing list
++, as at is now, but no extensible user info with extra
information like email addresses, etc, I think).
--
Steve Alexander
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
).
--
Steve Alexander
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
this discussion that registering layers is needed only
for certain ZMI things, to be implemented later on. So, I guess the
ZCML will be implemented later on, or not implemented later on. In
either case, later on.
--
Steve Alexander
___
Zope3-dev mailing list
in the ZMI.
In addition, I'd like to say that I believe that it is important to keep
things that are just for the ZMI separate from the core, where they
add complexity to the core.
--
Steve Alexander
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub
of months, though.
--
Steve Alexander
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
.
--
Steve Alexander
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
by the community of people
developing on these projects.
--
Steve Alexander
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Jim Fulton wrote:
Steve Alexander wrote:
I'd be happy using launchpad too. The last link points to a discussion
that didn't have any decision in the end. I wouldn't go as far as
abandoning the old collector data.
Then I think we should stick with the current collector unless someone
comes
15 matches
Mail list logo
