Pre/PostUpdate for all elements

[Buddie]

I noticed not all elements don't have Pre/PostUpdate, even though I thought every element was supposed to support this? After taking a look at runebar.lua I was able to get a PostUpdate working for self.Runes so I was wondering if there was a good reason for not having the pre/postupdates or if haste just hadn't gotten around to it yet.

[haste]

{Pre,Post}Update and Override are only added to elements where I can see they are required, or if someone asks for it.

The rune element has been in oUF for over a year now, without anyone asking for additional hooks/callbacks. A lot more control was given to the layout in 1.4.x tho'. Based on that it would seem like my initial hunch was correct.

I don't mind adding any, just state why and where.

[Buddie]

Well I recently tried replacing the statusbars for the runeframe with text strings and the easiest way to update it was though a postupdate.

It would be nice to have pre/postupdate and override on most if not all elements just for the sake of flexibility.

[haste]

If you are adding text, you could use OnValueChanged on the statusbars to add the timers.

If you are only doing text, I'd suggest using tags and frequentUpdates on them. Abusing the current element to just do text is really pushing stuff beyond sanity.

[Buddie]

I wanted to avoid using tags as I've read they aren't the most efficient way of updating a string, making sub elements for health/power was working for me and I wanted to keep using the same method.

Either way I still think it would be nice to have pre/postupdates for most elements.

[haste]

If you worry that much about performance then you should either write your own update mechanism or start from scratch.

Having {Pre,Post}Update callbacks are nice, but there has to be some level of sense behind them. Currently 11 elements support {Pre,Post}Update, while 20 support Override. This is out of the current 28 elements on github, where some have non-common callbacks (for example the castbar element).

The ones that are lacking {Pre,Post}Updates are generally very simple elements, which only Hide/Show a texture. The runes element is among the few exceptions actually.

[Buddie]

I already have my own postupdate functions that are working with my health, power, cast and runebar. If I could access self from a tag then I could see myself using tags in place of butchering the existing elements.

I can understand why you don't have pre/post updates on the elements that are just textures. But is there any reason in particular that the runebar is an exception, Or you just haven't seen a legitimate use for it yet?

[haste]

The rune bare doesn't have callbacks because I haven't been able to see any legitimate use of any, and so far no-one has really been able to put forward any either.

You don't have access to self in tags, as they are intended to just return strings and be detached from the frame they are updating. It is however possible to abuse closures in Lua and create a tag function with access to one frame.

Also, you might want to benchmark tags before thinking of them as a bottleneck. They are pretty much just generating strings, which creates slightly more garbage[1] than focused updating.

[1] [dead][offline] would fetch the return from both functions, then combine them into a third string. Most people would write the update function to do this concatenation anyway.

[Buddie]

I don't know how I got the idea of tags being a bottleneck but I'm glad you cleared that up. I'll definitely use tags if I can wrap my head around closures.

I never intended for this topic to be support for my layout but thanks anyways :D.