Ticket #2528463 (closed defect)
Reporter Nate Cavanaugh |
Opened: 12/9/09 Last modified: 03/31/10 Status: closed Type: defect Resolution: fixed |
Owner Satyen Desai |
Target Release: 3.1.0 Priority: P3 (normal) |
|---|---|---|---|
| Summary: | Plugin doAfter methods should be a little clearer | ||
| Description: | In Plugin's doAfter methods, it uses both AOP and event listeners. However, this is an issue both in clarity (the name makes it appear that it's a simple wrapper for Y.Do.after), but the fact that it Maybe have doAfter only do one, and then also have a method such as doAfterEvent or doAfterMethod ? This ticket is more or less to bubble it up and open the discussion. |
||
| Type: | defect | Observed in Version: | development master |
| Component: | Plugin | Severity: | S3 (normal) |
| Assigned To: | Satyen Desai | Target Release: | 3.1.0 |
| Location: | Library Code | Priority: | P3 (normal) |
| Tags: | Relates To: | ||
| Browsers: | N/A | ||
| URL: | |||
| Test Information: | |||
Change History
|
Posted: 12/23/09
|
|
Posted: 12/23/09
|
|
Posted: 12/23/09
Needs to be fixed for 3.1. Will probably deprecate doAfter, in favor of clearer methods - afterHostMethod, beforeHostMethod, onHostEvent, afterHostEvent (maybe?, since the other thing we could probably highlight is that it's the host you're messing with. Need to evaluate shorter names which are clear enough) |
|
Posted: 01/8/10
Ticket #2528532 was marked as a duplicate of this ticket. |
|
Posted: 01/12/10
Thanks for Re for ticket 2528532. When I was creating this ticket I also discovered this bug and I was very satisfied with your last post from 12/23/09 (adding afterHostMethod, beforeHostMethod, onHostEvent, afterHostEvent), because it gives us possibility that binding to host events can be clearly detached on YUI framework level while removing plugin/destroying plugin without explicitly calling detach. But I don't think my post was understood clearly. I tried to express that plugin should have one render method (or can be named differently) which could have simple logic - when plugin is plugged and host is not rendered it waits and is executed after host's render, if is host already rendered is executed just after initializer (and this is use case which I cannot handle only with doAfter ... when plugin is plugged after host render was already called only one thing is to check 'rendered' attribute and it leads to not nice code ...). |
|
Posted: 01/12/10
Hi Jan, if (host.get("rendered")) { can be reduced to: host.doAfterEvent("render", doSomething); (doAfterEvent does not exist yet, but will (or something similar) when this bug is fixed) Regards, |
|
Posted: 01/12/10
Forgot to clarify - this should be true even with the latest code, and the workaround I provided... host.doAfter("host:render", doSomething); Will always invoke doSomething() - even if the render event has already fired. |
|
Posted: 02/6/10
Added explicit methods to plugin for host event/method subscription (doBefore, doAfter do not work if the host has a method name which is the same as an event name. May make a 2nd pass for kweight. Fixes #2528463 |
|
Posted: 03/31/10
|


Ticket #2528412 was marked as a duplicate of this ticket.