> > a) The change to manage_* seems to be completely arbitrary,
> since we already
> > had _do* methods that meant you didn't have to call manage_users with
> > fake submit buttons. So what is the point of having manage_ ?
>
>
> They were added in response to this fishbowl proposal:
>
> http://dev.zope.org/Wikis/DevSite/Proposals/UserFolderXmlRpcQuickFix
>
> It was a quick fix intended to help people doing user management over
> XML-RPC.
Right - the idea was to _add to_ the existing API, in a completely
backward-compatible way, so that:
- "untrusted code" (DTML, Python scripts, other code managed by
security constraints) could be used to do user mgmt (if the
caller has appropriate rights, of course). Previously, the
only code accessible to these was unwieldy (the build-a-fake-
request approach), and the corresponding "_" methods were not
accessible because "_" methods can't be called from Web code.
- "trusted code" (external methods, Python products) would have
a clearer and easier API for doing the same. While they could
have used the "_" methods, they are not documented as if they
are a part of the official API, which is a point of confusion.
- An XML-RPC (given appropriate rights) call could be used to
do user management work.
> If there are problems in maintaining compatibility with the previous
> API, and products that rely on that, well that's a bug and it needs
> Collecting and sorting out before 2.5 final.
>
> I'm concerned about this too, and I'm glad it's reached Zope-Dev, as
> I've got some LoginManager user folders in use, and I don't want these
> to break when I start using Zope 2.5 on those systems.
Nor do I - my goal for this was (and remains) 100% backward compatibility,
and to make people's lives easier, not harder. It looks like I've muffed
the implementation, for which I certainly take full responsibility (and
which I'll rectify today).
I think I also failed to adequately express the goal for this - I'll
need to update the docstrings as well. The goal was not to change the
(admitted ancient and crummy) way that the Web interfaces to user folders
interact with the API (the dispatching based on submit button lameness),
as I'm sure that many, many implementations would break. The goal was
not to deprecate _that_ usage of the 'manage_users' method.
The idea was to deprecate the use of 'manage_users' from Web-based or
product code in favor of the new (and hopefully easier) APIs. That
allows us to address the lameness of the 'manage_users' method re:
user folder UI as a separate issue in the future, while still being
able to give "scripters", product authors and XML-RPC users something
that they can use now.
Brian Lloyd [EMAIL PROTECTED]
Software Engineer 540.361.1716
Zope Corporation http://www.zope.com
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope )
