On Wednesday February 11, 2009 02:07:35 Chris McDonough wrote:
> I don't understand. Why would both a RedirectingFormPlugin and a
> FriendlyRedirectingFormPlugin be active in the same configuration? I see
> that you've added the SCRIPT_NAME patch to the challenge method of the
> friendly version, that's not enough?
> Oh wait. I see. You're calling the superclass' "challenge" and
> "identify". Can you just not do that? At this point,
> FriendlyRedirectingPlugin should just be a plain old fork I think. There's
> no purpose in using RedirectingFormPlugin as a base class here anymore, as
> you've overridden every one of its API methods. People shouldn't be
> hamstrung by r.who.plugin implementations; it's fine to just 100% fork
> implementation here; cut-n-paste is de rigeur for plugins. It's actually
> preferable, I think, because then unexpected changes in the base class
> don't break the subclasses.
Good idea. I'll fork it instead of extending it.
> >> Of course, we'll fix r.who in the meantime and eventually release a
> >> fixed version, but you shouldn't need to wait for us to do so. I would
> >> have just applied the SCRIPT_NAME patch that Gustavo wrote to
> >> RedirectingFormPlugin if it had been correct; but as it stands, it can't
> >> work, so I'll need to understand the issue and write a correct patch
> >> which I haven't had time to do yet.
> > The problem of the patch was in the use of SCRIPT_PATH (instead of
> > SCRIPT_NAME).
> Cool. You've tested it interactively, I presume, and it does the right
> thing? (Just looking for confirmation so I can apply the fix without
> needing to set up an interactive test environment).
I didn't test it myself, but it should work because Lukasz did test it and it
worked, and also because it's mentioned here:
Gustavo Narea <http://gustavonarea.net/>.
Get rid of unethical constraints! Get freedomware:
Repoze-dev mailing list