Jeffery To wrote:
You're not missing anything - the Template and Facebook Connect
plugins aren't playing nicely together :-) The issue(s) are with how
multiple plugins interact in general.
Well, I think the /main/ issue is whether the template plugin we have is
/really /how we want to do templating (I don't think it is). As it
stands right now, if you are using template plugin, You're Doing It Wrong.
I actually think the use-case that templating provides -- changing the
/entire page's output/ -- is so rare as to be unsupportable.
I think that the things that people want to do that they have to use
templating for with other software are things we could easily provide
with configuration options, hooks and plugins. For example, adding a
single entry to the primary navigation menu shouldn't require writing
your own HTML output template for the entire page, or figuring out where
in templates/mytemplate/menus/primary/structure.php (or whatever) you're
supposed to write your code.
So if the start event handler overrides the default code, the end
event is never triggered. In this case, the FB start event handler
only outputs its nav HTML and doesn't trigger the end event, so the
Template end event handler is never called (and so no nav HTML gets to
the output page).
Yes. I've just pushed a change to 0.8.x branch that makes the FBConnect
plugin emit the EndPrimaryNav event when it replaces the default processing.
Zach, it would be great if we could make this plugin less intrusive,
there. Maybe just prepend the FB login link, and use JavaScript to
change the logout link...?
1) Change Event::handle() to call all registered handlers, instead of
stopping after the first false return value.
No way. We absolutely want to let plugins /replace/ or prevent the
default behaviour at event times, not just augment it.
2) Change all event triggering code to always trigger the end event,
i.e. move it out of the if block.
That doesn't match the semantics of what those events are for. Consider
the EndNoticeSave event, which fires when we've correctly saved a
notice. It would be incorrect to fire that event if a plugin has blocked
the save.
I don't know if there are any side-effects from these, which is why
I'm not submitting merge requests already.
I think the fix here is a coding convention that /if your plugin
replaces the default processing/, and if the replacement is roughly
equivalent to the default processing, you should fire the event. The
FBConnect plugin now does that.
-Evan
--
Evan Prodromou
CEO, StatusNet, Inc.
e...@status.net - http://identi.ca/evan - +1-514-554-3826
_______________________________________________
StatusNet-dev mailing list
StatusNet-dev@lists.status.net
http://lists.status.net/mailman/listinfo/statusnet-dev
