04/08/14, 09:45 AM | #21 |
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 | #22 |
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 | #23 |
Sorry, Xrystal, guess I was too tired and missed a couple of things. >< I'll look at it again tonight.
|
|
04/08/14, 01:01 PM | #24 | |
Last edited by thelegendaryof : 04/08/14 at 01:06 PM. |
||
04/08/14, 01:28 PM | #25 | |
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. |
|
04/08/14, 01:57 PM | #26 |
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 | #27 |
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, 05:43 PM | #28 |
04/08/14, 05:44 PM | #29 |
It worked great with that little extra change.
The downside is that it must overwrite the font sizes so gonna try and get it run after the addon is loaded and see how different it works. But first screen shot shows it working as follows: edit: Well combined your two posts into the following piece of code so that you could create multiple combo boxes ( dropdowns ) in the same Top Level Window. Lua Code:
2nd picture shows the 2 together on the screen. edit 3: But as you can see, the font still isn't letting you change it for some reason. Maybe you would have to make a template of the template and change the fonts at that point. But no biggie. Last edited by Xrystal : 04/08/14 at 06:14 PM. |
|
04/08/14, 07:53 PM | #30 |
Hmm... I am able to get the font to change with only
Lua Code:
|
|
04/08/14, 08:40 PM | #31 |
Hmm, guess ZoFontGameLarge isn't that much larger than ZoFontGame rofl. I probably didn't notice the difference.
I added another combo box with a selection of built in fonts listed in Zgoo, not figured out whether there is a way to set the font per option but probably not a good idea seeing as it seems to be using the same font for the whole control. I adjusted my combo box function to add an option callback function and in the OnSelect function I return the font selected to the callback function so that it can use it and I told it to change the font for the dropdowns of the combo boxes. It changes the selected font to the same font as well. Some don't look much different but some of them you can definitely see the change. SetResizeToFitDescendents don't seem to work unless I am expecting it to do something different at the wrong time. Anyway, Function header line was changed to Lua Code:
Lua Code:
Lua Code:
Lua Code:
Picture showing what it looks like now. Just did a quick test to see if you can turn off the names but nada .. so even though the variables are local the frames/windows still have global names .. which is a pity. |
|
04/09/14, 03:07 AM | #32 |
|
I tried using lua instead of xml but i must have done something wrong:
Lua Code:
the OnUpdate function doesn't seem to be called... edit: function(self, time) doesnt work as well edit2: Lua Code:
Last edited by Shinni : 04/09/14 at 04:11 AM. |
04/09/14, 05:06 AM | #33 |
Ah, so that's why sometimes OnUpdate has been working for some people from Lua and other times not. Good find Shinni.
|
|
04/09/14, 12:40 PM | #34 |
I think I (or someone else?) have mentioned this "bug" before - it was noticed during Beta. When creating a control from scratch, the OnUpdate handler is missing. You need to set it in XML or use a template that already has it set.
|
|
04/09/14, 12:42 PM | #35 | |
Thanks Seerah. |
||
04/10/14, 09:51 AM | #36 |
Posting this here as it may help someone else.
I was getting odd "attempt to index a nil value" message on loading from my add-on, from a line in the OnUpdate() function. The reason it was happening is because I have the <OnUpdate> declared within the XML and it was firing before my add-on had completed it's initialisation, which included loading saved variables. So, the OnUpdate() function was trying to access a saved variable that hadn't been loaded yet. I resolved this by simply creating an initialised variable in my add-on. Code:
MyAddon = () MyAddon.initialised = false MyAddon.name = "MyAddon" function MyAddon.OnUpdate() -- Bail if we haven't completed the initialisation routine yet. if (not MyAddon.initialised) then return end -- code I wanted to execute here end function MyAddon.Initialise(eventCode, addOnName) -- Only initialize our own addon if (MyAddon.name ~= addOnName) then return end -- Do my initialisation tasks here, including loading saved variables etc MyAddon.initialised = true end EVENT_MANAGER:RegisterForEvent("MyAddon", EVENT_ADD_ON_LOADED, MyAddon.Initialise) Code:
<GuiXml> <Controls> <TopLevelControl name="MyAddon" mouseEnabled="true" movable="true" clampedToScreen="true"> <Dimensions x="200" y="200" /> <OnUpdate> MyAddon.OnUpdate() </OnUpdate> </TopLevelControl> </Controls> </GuiXml> |
|
04/10/14, 10:13 AM | #37 | |
Join Date: Apr 2014
Posts: 18
|
Great stuff Stormknight. Thanks for the tip. Since I am using XML for my UI's as well, I'm going to find that handy I'm sure.
|
|
04/10/14, 08:38 PM | #38 |
Upon creation of your frame in the XML, you can hide it. This will stop it from running the OnUpdate script. When you are ready to, you can show the frame again.
|
|
04/10/14, 09:30 PM | #39 |
05/11/14, 01:02 AM | #40 | ||
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 |
Linear Mode |
Switch to Hybrid Mode |
Switch to Threaded Mode |
|
|