XML vs Lua for GUI Best Practices

[Yazilliclick]

I'm just barely getting into addon development and wondering what's considered best practice here or pros and cons against each? I see some addons and some guides that seem to push using Lua over XML for GUI of addons though it's never really explained why. Is there are a time to go with one over the other?

[Kith]

Originally Posted by Yazilliclick I'm just barely getting into addon development and wondering what's considered best practice here or pros and cons against each? I see some addons and some guides that seem to push using Lua over XML for GUI of addons though it's never really explained why. Is there are a time to go with one over the other?

As I found out today, there is either a bug (is what I was told may be the case) or just some extra criteria to allow a LUA created GUI frame to use an OnUpdate handler so keep that in mind when picking between XML and LUA.

My personal preference is to do it all in LUA being brought over from WoW modding.

[Xrystal]

My usual preference is to do so as well to keep as much as possible out of the global namespace but it seems some functionality doesn't have a Lua equivalence, or no one has found it yet so I have had to use XML in my addon anyway.

[Yazilliclick]

Originally Posted by Kith As I found out today, there is either a bug (is what I was told may be the case) or just some extra criteria to allow a LUA created GUI frame to use an OnUpdate handler so keep that in mind when picking between XML and LUA. My personal preference is to do it all in LUA being brought over from WoW modding.

What was the reasoning there with WoW? Believe it's default method was XML with Lua too wasn't it? Thanks for notice on the bug, guessing that's what I'm running smack into as well.

Originally Posted by Xrystal My usual preference is to do so as well to keep as much as possible out of the global namespace but it seems some functionality doesn't have a Lua equivalence, or no one has found it yet so I have had to use XML in my addon anyway.

Ah good point about global clutter thanks!

[Halja]

It not an either XML or LUA best practice for GUI construction. As it’s been said, there are pros and cons to weigh because not everything is documented, a feature is not exposed, or construction is cleaner in one or the other. Some have even noticed an occasional runtime differences. Personally, I’m taking a hybrid approach. I will define the fixed UI elements in XML. On the dynamically created controls, I’ll use XML defined virtual templates. Then in LUA code call CreateControlFromVirtual(). Its what's comfortable for me.
--halja

[Dio]

Either way works. XML certainly makes it easier to see the hierarchy of your GUI. As a web developer I've just been conditioned against XML, having begrudgingly worked with it in years past, and it's sort of become less relevant in favor of JSON. If I was designing a unit frame addon I would probably use XML, but to me it's not necessary for a simple addon that uses a few frames generated imperatively.

[Kith]

Originally Posted by Yazilliclick What was the reasoning there with WoW? Believe it's default method was XML with Lua too wasn't it? Thanks for notice on the bug, guessing that's what I'm running smack into as well. Ah good point about global clutter thanks!

I believe it was, as you said, global clutter. XML frames needed a globally defined name to be referenced whereas with LUA you could not give the frame a name and reference it through saving its return to a local. Most WoW mods in the latter days would only have 2 globals, the mod table itself and its SavedVariables table.

With my 2-part library (due to the OnUpdate XML thing), my mod is up to 5 globals which bugs me more than it should :P

[Seerah]

Xrystal: look at LibAddonMenu to see how I create dropdowns

[thelegendaryof]

I have to say mixing code with layout-structure always reminds me about using inline JS and inline CSS in HTML:

Bad practice

There is a reason you have both.

1. XML is for structure (as in describing your layout)
2. LUA is for functionality that uses that structure (as in bringing that layout to life)

While some coders do prefer doing everything with only code due to performance reasons (which might be valid and better if there isn't much going on) the usability and maintenance of it is significantly harder especially if things get more complex.

For example when they introduce bigger API changes the XML-Definition is high likely to stay the same -
while the API-Functions itself are most likely to change. Resulting in a broken layout that needs to get adjusted.

That taken aside when you have multiple people working on a project (speaking from a professional side) it 's way easier for the Designers to just jump in and make their adjustments in a simple XML-File then by digging in your Code (and breaking the functionality instead of changing the Layout).

At least that is how one should tell it to a beginner in terms of optimal viewpoints overall for both the Designer as well as the Developers.

Pawkette's Projects are an good example at how you could / should mix them properly (in my opinion)

[Xrystal]

I can see where you are coming from and I don't negate anything you said. However.

My main reasons for doing everything in Lua is as follows:

1. Ability to create un-named frames to keep them out of the global namespace and local to the file itself.
2. Ability to at a later date allow access outside of the addon to one or more frames/tables at will with a simple function.
3. Error track ability. Lua related errors will show file name and line that the last error was noticed. XML related errors will not even mention what file let alone which element within the file is triggering the problem.

So here goes my view on Pros and Cons.

Both XML and Lua
Pros
-- Separates layout and functionality
-- Allows easier relocation of individual frames without the need to change functionality
Cons
-- Forces global naming and public access to every frame regardless to whether you wanted to or not
-- Forces unique and normally longwinded naming due to the global nature of XML structure
-- Errors are harder to identify if they are triggered in the XML and not the Lua file first.

Just Lua
Pros
-- Full control over process order
-- The ability to keep all data out of the global namespace and private to the addon
-- Allows realistic naming of variables as they are only used in your addon.
-- Errors are easier to identify as file name and line number are reported when errors occur
Cons
-- Some functionality, so far, seems to only be available inside of XML files meaning a Lua only project may not be possible.
-- Changing of layout may be somewhat more work, depending on how it was coded in the first place.

I have never said or felt that XML users were doing anything wrong, just that I felt more comfortable to use just Lua. I have no real problem using XML and Lua in my projects but I don't like the idea of having frames unnecessarily in the global table. Which at present all my frames are, and my addon still hasn't reached it's peak yet so I won't be surprised to find myself adding more frames later on for one functionality or another which will mean I will have even more frames flooding the global table needlessly. Unless of course there is a way to make un named frames with XML ? I doubt that the name field is optional if you need to access it in your lua file.

[Seerah]

Sorry, Xrystal, guess I was too tired and missed a couple of things. >< I'll look at it again tonight.

[Xrystal]

Originally Posted by Seerah Sorry, Xrystal, guess I was too tired and missed a couple of things. >< I'll look at it again tonight.

It's cool. It gave me a chance to try and figure it out myself but none of my thoughts and ideas panned out rofl. But it also showed me how close I was to converting it correctly, it almost looked like my code rofl.

[Seerah]

Tada!!! Didn't have to make one from scratch, I found a nice and easy template in the UI files. (Sorry guys, we still don't have permission to upload them. )

From the character sheet, the dropdown that you can select a title in uses this template...

        <Control name="ZO_StatsDropdownRow" virtual="true">
            <Dimensions x="607" y="30" />
            <OnInitialized>
                self.name = self:GetNamedChild("Name")
                self.dropdown = ZO_ComboBox_ObjectFromContainer(self:GetNamedChild("Dropdown"))
            </OnInitialized>
            <Controls>
                <Label name="$(parent)Name" inherits="ZO_StatsRowName"/>
                <Control name="$(parent)Dropdown" inherits="ZO_ComboBox">
                    <Dimensions x="300"/>
                    <Anchor point="RIGHT"/>
                </Control>
            </Controls>
        </Control>

To just Lua, using the pre-existing template shown above:

local wm = WINDOW_MANAGER  --just an upvalue
local choices = {"apple", "banana", "cherry"}  --this is the table of choices to go in the dropdown
 
local myFrame = wm:CreateTopLevelWindow("myFrameForXrystal")  --this can be whatever toplevel frame you need it to be to anchor the dropdown stuff to
    myFrame:SetAnchor(CENTER)
    myFrame:SetDimensions(200, 50)
local dropdownContainer = wm:CreateControlFromVirtual("myFrameForXrystalDropdown", myFrame, "ZO_StatsDropdownRow")  --create your dropdown container using the template above
    dropdownContainer:SetAnchor(TOPLEFT)  --anchor this container however you need to
    dropdownContainer:GetNamedChild("Dropdown"):SetWidth(200)  --change your dimensions if different from the template's (607, 30)
local selected = dropdownContainer.name  --the template put the label in our container's table, you don't need this line unless you want it
local dropdown = dropdownContainer.dropdown  --the template put our actual dropdown object into our container's table. Here's a local reference so we don't have to keep doing a table look-up
    dropdown:SetSelectedItem("cherry")  --set your initial dropdown selection - usually taken from the saved variables
 
local function OnItemSelect(_, choiceText, choice)  --this is the callback function for when an item gets selected in the dropdown
    d(choiceText, choice)
end
 
for i=1,#choices do  --loop through your table to add the selections to the dropdown
    local entry = dropdown:CreateItemEntry(choices[i], OnItemSelect)  --this really just creates a table with {name = choices[i], callback = OnItemSelect} - you may be able to skip this step and just pass the correctly formatted table into the below function...
    dropdown:AddItem(entry)  --again, entry is just a table with the above args stored in it
end

If everything works right, we can put it on the wiki.

[thelegendaryof]

Originally Posted by Xrystal I can see where you are coming from and I don't negate anything you said. However. My main reasons for doing everything in Lua is as follows: 1. Ability to create un-named frames to keep them out of the global namespace and local to the file itself. 2. Ability to at a later date allow access outside of the addon to one or more frames/tables at will with a simple function. 3. Error track ability. Lua related errors will show file name and line that the last error was noticed. XML related errors will not even mention what file let alone which element within the file is triggering the problem. So here goes my view on Pros and Cons. Both XML and Lua Pros -- Separates layout and functionality -- Allows easier relocation of individual frames without the need to change functionality Cons -- Forces global naming and public access to every frame regardless to whether you wanted to or not -- Forces unique and normally longwinded naming due to the global nature of XML structure -- Errors are harder to identify if they are triggered in the XML and not the Lua file first. Just Lua Pros -- Full control over process order -- The ability to keep all data out of the global namespace and private to the addon -- Allows realistic naming of variables as they are only used in your addon. -- Errors are easier to identify as file name and line number are reported when errors occur Cons -- Some functionality, so far, seems to only be available inside of XML files meaning a Lua only project may not be possible. -- Changing of layout may be somewhat more work, depending on how it was coded in the first place. I have never said or felt that XML users were doing anything wrong, just that I felt more comfortable to use just Lua. I have no real problem using XML and Lua in my projects but I don't like the idea of having frames unnecessarily in the global table. Which at present all my frames are, and my addon still hasn't reached it's peak yet so I won't be surprised to find myself adding more frames later on for one functionality or another which will mean I will have even more frames flooding the global table needlessly. Unless of course there is a way to make un named frames with XML ? I doubt that the name field is optional if you need to access it in your lua file.

Yip absolutely valid as well. Wasn't basically directed towards you or any other advanced developer more like a general rule for the thread opener and alike. As always if you're experienced - break the rule when you feel like it 's right to do so (there 's always pros and cons).

[Brainling]

In the professional world, mixing your code and layout are absolute no-no's. UI programming 101 stuff.

That said, this isn't a professional environment. If people are more comfortable in pure code, let them use pure code. Bugs and maintenance headaches caused by this aren't likely to lose anyone money or cause direct harm to a 'business'. People are writing these add-ons for fun, and in many cases aren't professional software engineers. Provided their style of coding isn't directly causing client issues (high memory and/or CPU usage), I'm all for letting people do things the way they are comfortable and find fun.

Personally I'll be going the route of using XML and virtual XML templates for my UI, as that's the environment I feel comfortable in coming from a professional web and WPF background. The idea of layout markup being fundamentally separated from the code is like a warm blanket for me.

[CatoTheElder]

Originally Posted by Brainling In the professional world, mixing your code and layout are absolute no-no's. UI programming 101 stuff. That said, this isn't a professional environment. If people are more comfortable in pure code, let them use pure code. Bugs and maintenance headaches caused by this aren't likely to lose anyone money or cause direct harm to a 'business'. People are writing these add-ons for fun, and in many cases aren't professional software engineers. Provided their style of coding isn't directly causing client issues (high memory and/or CPU usage), I'm all for letting people do things the way they are comfortable and find fun. Personally I'll be going the route of using XML and virtual XML templates for my UI, as that's the environment I feel comfortable in coming from a professional web and WPF background. The idea of layout markup being fundamentally separated from the code is like a warm blanket for me.

This has been a huge argument, for a long time. I am a professional software developer (linux kernel and drivers), so I can do API scripting, but it is far more difficult, especially without documentation. That said, in a professional environment you need to maximize your efficiency. This means clear memory when you're done with it (especially arrays/tables), dispose of objects when they're no longer required, minimize indexing/searching arrays etc. This is the reason XML should not be used at all. It is insecure, inefficient, and as a result requires more system resources than necessary.

ESPECIALLY IF YOU HOOK OnUpdate() - OnUpdate() gets called every frame re-draw (ie 60 FPS = 60 calls to OnUpdate(). This creates a huge drain on system resources, even from minimal code.

XML:
Parses file, creates templates (or objects) on addon load, loads them into memory in the global name space, and leaves them there forever, allowing another to modify/overwrite your controls, accidentally or otherwise. So, bad security, bad memory management. Don't use XML.

Professional LUA Script:
Controls are dynamically loaded in to memory when needed.
Controls are protected from tampering by being in a private memory space
Controls are dynamically unloaded, freeing memory as soon as the control is no longer required.
Multiple controls can easily be created by using a function.

I've seen addons that require higher memory usage, and CPU utilization than entire operating systems. This is why it shouldn't be "okay" for people to "do things the way they are comfortable."

I spend a lot of time and effort keeping my system optimized, and poor code is extremely frustrating, especially from so-called professional web developers. Gee, I wonder what GUI is used to make your operating sytem's GUI? ... Oh, right, that's an infinite loop. At the bottom, the GUI is written in code. Absolute no-nos? Please, stop talking.