> You told us that you will be refining Zope 2.6 plan.
> ProposedFeatures table contains an " Implement links
> (object references)" entry by Mario Valente. I've created
> SoftLink proposal in ProposalsWiki . These works appear
> related. We (Mario and me) discussed and decided that
> we can dedicate some efforts to make it working (Mario
> has working code already). The plan is to release Patch-like
> product for Zope 2.3, 2.4 and 2.5 to get feedback. And to
> incorporate functionality into Zope 2.6 without patching
> Please give us your recommendations / feedback / instructions for us,
To be honest, I'm a little worried about the approach. Links
can be very, very hard to get right (which is why they are not
in the core now), especially with regard to security issues.
Creating an object that "impersonates" another object is tough,
because there a potentially unknown number of contracts that
the impersonator must fulfill. This usually leads to problems :(
For the SoftLink proposal in particular, the main problem you
note in the proposal is that you want to avoid 404's when
people go to a resource that has been moved. It seems to me
that the best way to address that problem is to have a
"RedirectObject" that you could add with the name of the
object that was moved. It would _not_ try to impersonate
the moved object, but when you went to "view" the object,
you would be automatically redirected to the new location.
That would avoid a lot of the problems of the link approach,
with little overhead.
Note that I'm not saying that object links are not a valid
requirement, but it sounds like the problem you want to
solve is definitely different than Mario's. In many ways,
the "correct" required behavior of a link depends on what
you expect to be able to do with it (the problem you are
trying to solve).
I can easily imagine that "right" behavior of a link if
your main goal is to avoid 404s will _not_ be right if
you are using the link in other ways. For example, if you
went to a URL that had been moved, what is the right
"context" that it should render itself in? I highly suspect
that the right context is the place that it was moved to,
rather than the context where the link lives (redirect
semantics). That is basically the opposite of another
possible usage of a link, where you would want to use the
link to "virtually include" an object into a different
I submit that trying to do both is too complex
and probably too insecure as well (as managers of security
would have to evaluate N possible security scenarios, most
of which are not readily visible to them at the time they
are setting up security).
I think that the "RedirectObject" approach could sidestep
all of these issues and provide an incremental step while
still solving your problem.
Brian Lloyd [EMAIL PROTECTED]
V.P. Engineering 540.361.1716
Zope Corporation http://www.zope.com
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -