|
04/06/14, 08:57 PM | #1 | |
Join Date: Apr 2014
Posts: 6
|
XML vs Lua for GUI Best Practices
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?
|
|
04/07/14, 04:16 AM | #2 | |
|
My personal preference is to do it all in LUA being brought over from WoW modding. |
|
04/07/14, 05:10 AM | #3 |
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.
|
|
04/07/14, 06:23 AM | #4 | ||
Join Date: Apr 2014
Posts: 6
|
Ah good point about global clutter thanks! |
||
04/07/14, 09:40 AM | #5 |
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 |
|
04/07/14, 12:15 PM | #6 |
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.
Last edited by Dio : 04/07/14 at 12:17 PM. |
|
04/07/14, 03:36 PM | #7 | |
|
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 |
|
04/07/14, 04:08 PM | #8 |
Xrystal: look at LibAddonMenu to see how I create dropdowns
|
|
04/08/14, 09:45 AM | #9 |
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) Last edited by thelegendaryof : 04/08/14 at 10:04 AM. |
|
04/08/14, 10:35 AM | #10 |
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. Last edited by Xrystal : 04/08/14 at 10:43 AM. |
|
04/08/14, 12:32 PM | #11 |
Sorry, Xrystal, guess I was too tired and missed a couple of things. >< I'll look at it again tonight.
|
|
04/08/14, 01:57 PM | #12 |
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.
|
|
04/08/14, 04:47 PM | #13 |
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... Code:
<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> Lua Code:
If everything works right, we can put it on the wiki. Last edited by Seerah : 04/08/14 at 07:54 PM. |
|
04/08/14, 01:01 PM | #14 | |
Last edited by thelegendaryof : 04/08/14 at 01:06 PM. |
||
04/08/14, 01:28 PM | #15 | |
Join Date: Apr 2014
Posts: 18
|
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. |
|
05/11/14, 01:02 AM | #16 | ||
Join Date: May 2014
Posts: 44
|
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. Last edited by CatoTheElder : 05/11/14 at 01:04 AM. Reason: ignorant people piss me off |
||
ESOUI » Developer Discussions » General Authoring Discussion » XML vs Lua for GUI Best Practices |
«
Previous Thread
|
Next Thread
»
|
Display Modes |
Switch to Linear Mode |
Hybrid Mode |
Switch to Threaded Mode |
|
|