We have detected that cookies are not enabled on your browser. Please enable cookies to ensure the proper experience.
Results 1 to 15 of 15
  1. #1

    An idea looking for feedback from authors...

    Unfortunately due to my ISP being borderline braindead, I haven't really been able to play (either LotRO or with Plugins) for the last couple of weeks. However, an idea has recently popped into my head - one that I plan on testing as soon as I have reliable internet again.

    One common trend when it comes to organizing visual elements and code logic is to use a type of markup language to set up the visual elements, as it tends to be easier for laying things out and keeping logic separated from the eye candy. One of the most common examples of this is, of course, HTML/JavaScript - but the same general practice is used almost everywhere - except here.

    I think, I may be able to change that - obviously not as well as Turbine themselves could do - but I figure if the markup could be stored in a Lua table and imported, then a class could be written to parse the markup, and "translate" it into code, without the author having to do all the work. So basically instead of just writing standard markup, you'd have to put something in like:

    Code:
    UI={
    --markup goes here
    }
    Basic translating and parsing should be plausible enough, as would the standby "getElementById" and "getElementsByTagName" functions. Some playing around would be necessary to get it more user friendly than that, including event handling and a way to get separate collections of elements - but in theory it should be doable.

    Now for the feedback part - would you find this useful, and perhaps a better alternative to the existing system? If so, would you rather it be closer to the XML that the skinning system currently uses? (element tags, with the type of element as an attribute) or would you rather see a HTML-esque format, where the tags themselves contain the type of element?

    I'm going to be playing with this idea regardless, but how much interest from other authors I get, will influence where I go from there.
    [CENTER][IMG]http://i.imgur.com/wK9A7aa.png[/IMG]

    [SIZE=1][B][COLOR=white]75[/COLOR][/B] Fourohfour | [B][COLOR=white]75[/COLOR][/B] Artemedis | [COLOR=Blue][B]60[/B][/COLOR] Whiskeytango Foxtrot | [B][COLOR=#00ca00]50[/COLOR][/B] Mistah Boombastic | [B][COLOR=#00ca00]56[/COLOR][/B] Appetizer | [B][COLOR=#a7a7a7]25[/COLOR][/B] Aggromi | [B][COLOR=blue]61[/COLOR][/B] Onepointtwentyone Gigawatts [/SIZE] [/CENTER]

  2. #2
    Join Date
    Feb 2007
    Location
    Irvine, CA
    Posts
    467

    Re: An idea looking for feedback from authors...

    Interesting idea... while you're at it, could you create a GUI/WYSIWYG editor/IDE to generate said markup? :P
    Deus

  3. #3

    Re: An idea looking for feedback from authors...

    This concept (a "framework library") has been used successfully in other games in the past.

    However, the implementation of shared libraries has a few more hurdles in LOTRO, not the least of which is the apartment model for execution context.

    While a framework could be implemented as a static library, I wonder if the popularity of that sort of implementation might be self-defeating, in terms of resource usage.

    If every plugin is loading its own copy of the entire LOTROAce framework, for example, they may be using a lot more overhead than they need to, just for small pieces of its functionality.

    Edit: Of course, if your library has only a single purpose and does its job efficiently, or is a modular part of a larger framework that can be loaded selectively, I can see the productivity, standardization, and bug-preventing benefits of the library easily outweighing any performance impact it might have.
    Last edited by Fredelas; Apr 26 2011 at 12:50 AM.

  4. #4
    Join Date
    Mar 2007
    Posts
    108

    Re: An idea looking for feedback from authors...

    Quote Originally Posted by Digital_Utopia View Post
    Now for the feedback part - would you find this useful, and perhaps a better alternative to the existing system? If so, would you rather it be closer to the XML that the skinning system currently uses? (element tags, with the type of element as an attribute) or would you rather see a HTML-esque format, where the tags themselves contain the type of element?
    I'd be interested in using a markup language for ui stuff. Looking at all my option code most of it is just copy replace, change a few name, sizes, listeners, rinse and repeat . I'm partial to the tag containing the type of element. It would need a mechanism for custom tags to be defined so that user components could be used.

  5. #5

    Re: An idea looking for feedback from authors...

    First off, thanks to Deusdictum for resurrecting this thread. Although I hoped to have more done by now - the recent holiday, as well as a couple of new games have eaten up a lot of time.

    That being said, not all is lost - as I have been able to do some experimenting within LotRO itself, as well as plenty of time to plan.

    Regarding Files

    Unfortunately, there's no way to make a unique file extension for UI files, as "import" just assumes a .lua extension. However, there's nothing stopping someone from making a file called "UI.lua" for instance, importing it within _init_.lua, and using that as the file that contains all the necessary UI markup for that class.

    Regarding Libraries

    The entire package will consist of 2 separate libraries. The first one will contain all the classes that will create the Lua UI objects as the markup tells it to. The second one will be at least a start to an XML library. Initially it will only handle parsing/navigating the document tree - but in time, and if there's enough interest - XML creation classes could be added. As I was working this out, I realized I was going to have to basically create an XML parser - and figured that some authors who create plugins that need external data, may find XML a bit easier to deal with - instead of just working with tables

    Regarding Markup

    Right now, in order to create some kind of faux consistency, I'm using skinning format (i.e. Element tags, x,y,width,height params). In order for the library to tell which class is what, I'm also going to be introducing the "type" parameter, which will be set to a "friendly" name of the class you're using. For instance, Turbine.UI.Window will be "Window", while Turbine.UI.Lotro.Window will be "LotroWindow". One of the main things I wanted to accomplish was to make the markup require as little Lua as possible on the author end. So while internally tables will be used to varying degrees, the markup itself will be a string - using double bracket string delimiters. So for example, this is how the markup would look:

    Code:
    xmltest=
    [[<Element ID="mainSquare" type="Window" x="200" y="200" width="400" height="400" bgcolor="#ff0000">
            <Element ID="smallSquare" type="Window" x="220" y="220" width="100" height="100" bgcolor="#00ff00"/>
        </Element> ]]
    And yes, although hex based colors aren't 100% decided on, it is a primary goal - as face it, hex based colors (and alpha) are a whole lot easier to work with than percentages. Granted, this may just be my opinion - but I know both Flash and Photoshop display the hex value of the color. At any rate - feedback is appreciated.

    Regarding Usage

    This is still up in the air at the moment - as I'm still working out the best way to do this. The goal would be to require only two lines of code in order to generate, and display the UI, and then allow the author to access each individual element by the id.

    Regarding a GUI/IDE

    This is something I would really like to do at some point - the only real question is the method. Obviously the most accurate in terms of pure WYSIWYG, would be creating it as a plugin - however, the downsides are everything from limited saving (forced to copy and paste) to awkward multi-tasking (i.e. switching from your plugin to the designer and back).

    Another alternative would be modifying an existing IDE that supports previewing Lua, and modifying it (if possible) with the API classes. However, I have no idea what my options are in that regard - if there are any.

    The third and final alternative would be to create such an IDE specifically designed for LotRO - Ideally with some form of Lua support, modified to at least approximate the API, by attempting to recreate the results. Another possibility would be to create a web app that interprets this markup, and generates an approximation in HTML

    So yeah, a lot of ideas - but anything worth doing is going to take a chunk of time, especially considering some of these options are a bit out of my league currently. While I'm pretty sure I can learn anything, I haven't quite figured out how to simply download information directly to my brain - so it might take quite a while by myself. Some form of basic syntax highlighting for the markup would certainly be doable though.

    Regarding External Classes

    Obviously the library would need to recognize the element type before it can create it, which does make external classes a hurdle that needs to be addressed. Luckily, I am quite familiar with at least one UI class library, so that will be my guinea pig as I progress. I'd like to create some form of communication between this library, and other external libraries - some form of "plugin" variable that could be searched for, which would then let the UI markup library know what additional types exist, and what it can do with it.

    Of course, this would have to be author opt-in, as I would really rather not have to create special versions of existing UI libraries, or continue to update the UI markup - while keeping track of every single author created UI library/class that comes out. But, this is definitely one of the key points I'll look at.

    Anyway, that's all I have for now - hopefully this weekend I'll have an update, and get a bit clearer of a picture of what this is going to end up being.
    [CENTER][IMG]http://i.imgur.com/wK9A7aa.png[/IMG]

    [SIZE=1][B][COLOR=white]75[/COLOR][/B] Fourohfour | [B][COLOR=white]75[/COLOR][/B] Artemedis | [COLOR=Blue][B]60[/B][/COLOR] Whiskeytango Foxtrot | [B][COLOR=#00ca00]50[/COLOR][/B] Mistah Boombastic | [B][COLOR=#00ca00]56[/COLOR][/B] Appetizer | [B][COLOR=#a7a7a7]25[/COLOR][/B] Aggromi | [B][COLOR=blue]61[/COLOR][/B] Onepointtwentyone Gigawatts [/SIZE] [/CENTER]

  6. #6

    Re: An idea looking for feedback from authors...

    Just a small update, but still significant, so I thought I'd share.

    While my testxml I posted above is probably great for testing out basic UI generation, one root with one child isn't so great for testing out xml parsing. So, for that purpose, I went to data.lotro.com and used xml for an item I had in my browser's history. Unfortunately, at this point - CDATA will not be supported. At this stage, a CDATA tag would just add needless complexity to the project (both due to its non-standard tag structure, and the characters it uses).

    Two important steps were reached over the weekend. The first is the ability to grab the necessary information for a node, including attributes, values and tag names. The second is the ability tor read the entire xml string, grab the tags and innerText, and reproduce the tree, visually, in the chat window, based off of recognizing opening and closing tags.

    The next step will be bringing both of those together into a tree of Nodes, which will allow for logically accessing XML data via traditional means (i.e. getElementById, childNodes[x], attributes[x] etc). At that point the XML library (at least the input portion) will be functionally complete and I can move on to the UI generation.
    [CENTER][IMG]http://i.imgur.com/wK9A7aa.png[/IMG]

    [SIZE=1][B][COLOR=white]75[/COLOR][/B] Fourohfour | [B][COLOR=white]75[/COLOR][/B] Artemedis | [COLOR=Blue][B]60[/B][/COLOR] Whiskeytango Foxtrot | [B][COLOR=#00ca00]50[/COLOR][/B] Mistah Boombastic | [B][COLOR=#00ca00]56[/COLOR][/B] Appetizer | [B][COLOR=#a7a7a7]25[/COLOR][/B] Aggromi | [B][COLOR=blue]61[/COLOR][/B] Onepointtwentyone Gigawatts [/SIZE] [/CENTER]

  7. #7
    Join Date
    Dec 2007
    Location
    Seattle, WA
    Posts
    7,600

    Re: An idea looking for feedback from authors...

    Sounds like this will be an extremely useful tool, when it's completed - keep on truckin =)
    Maley Oakensage, Captain of Elendilmir

    Alas Elendilmir, may you *jingle jangle* forever in the Forgotten West

  8. #8

    Re: An idea looking for feedback from authors...

    I am very happy to announce that the XML Library now has basic functionality. It will parse an XML Document, stored as a string, into a collection of Nodes - where basic navigation is possible.

    For instance, using this XML document with the CDATA tags stripped from it, the following code will produce the given results

    Code:
    Turbine.Shell.WriteLine(myXML.childNodes[1].tagName);
    --result: apiresponse
    Code:
    Turbine.Shell.WriteLine(myXML.childNodes[1].childNodes[1].tagName);
    --result: item
    Code:
     Turbine.Shell.WriteLine(myXML.childNodes[1].childNodes[1].attributes[1]);
     --result: 1879151828
    Code:
      Turbine.Shell.WriteLine(myXML.childNodes[1].childNodes[1].attribute["name"]);
      --result: Dungeon-crawler's Boots
    Code:
    Turbine.Shell.WriteLine(myXML.childNodes[1].childNodes[1].childNodes[6].childNodes[1].innerText);
    --result: +22 Will
    Now, those familiar with DOM standards are probably already screaming - because I'm accessing attribute values without using the "Value" property (same goes with "innerText") . Rest easy, because this is just to show the ability to navigate the element node tree - the library itself will get a lot closer to W3C standards as I go on, but the immediate challenge was figuring out how to take an XML document and parse it into a structure that could be navigated via Lua. Now that this challenge was met, I can move on to turning this into a proper library.
    Last edited by Digital_Utopia; May 07 2011 at 11:40 PM.
    [CENTER][IMG]http://i.imgur.com/wK9A7aa.png[/IMG]

    [SIZE=1][B][COLOR=white]75[/COLOR][/B] Fourohfour | [B][COLOR=white]75[/COLOR][/B] Artemedis | [COLOR=Blue][B]60[/B][/COLOR] Whiskeytango Foxtrot | [B][COLOR=#00ca00]50[/COLOR][/B] Mistah Boombastic | [B][COLOR=#00ca00]56[/COLOR][/B] Appetizer | [B][COLOR=#a7a7a7]25[/COLOR][/B] Aggromi | [B][COLOR=blue]61[/COLOR][/B] Onepointtwentyone Gigawatts [/SIZE] [/CENTER]

  9. #9

    Re: An idea looking for feedback from authors...

    XML Library is now done enough to move on to working on the UI part, I slapped together a brief API reference for the time being - and that can be viewed here

    Further updates (here or there) will now be focused on the UI generation.
    [CENTER][IMG]http://i.imgur.com/wK9A7aa.png[/IMG]

    [SIZE=1][B][COLOR=white]75[/COLOR][/B] Fourohfour | [B][COLOR=white]75[/COLOR][/B] Artemedis | [COLOR=Blue][B]60[/B][/COLOR] Whiskeytango Foxtrot | [B][COLOR=#00ca00]50[/COLOR][/B] Mistah Boombastic | [B][COLOR=#00ca00]56[/COLOR][/B] Appetizer | [B][COLOR=#a7a7a7]25[/COLOR][/B] Aggromi | [B][COLOR=blue]61[/COLOR][/B] Onepointtwentyone Gigawatts [/SIZE] [/CENTER]

  10. #10
    Join Date
    Dec 2007
    Location
    Seattle, WA
    Posts
    7,600

    Re: An idea looking for feedback from authors...

    While this is an issue that's not going to be relevant until you have completed an alpha version....

    How are you planning on having this project interact with other plugins?

    Edit:

    On second thought... what if this framework was bundled with a plugin manager app that served dual purpose, as an example, and as a necessary way to get the code into memory and bypassing the multiple apartment issue, and prevent multiple loadings of the code. Thoughts?
    Last edited by Almagnus1; May 15 2011 at 09:52 AM.
    Maley Oakensage, Captain of Elendilmir

    Alas Elendilmir, may you *jingle jangle* forever in the Forgotten West

  11. #11

    Re: An idea looking for feedback from authors...

    Interesting, are you planning on implementing (simple) xpath functionality?

    Turbine.Shell.WriteLine(myXML. selectNode("/classes/class[@name='Burglar']/Might"))
    instead of something like
    Turbine.Shell.WriteLine(myXML. childNodes[0].childNodes[1].Might);

  12. #12

    Re: An idea looking for feedback from authors...

    Quote Originally Posted by Almagnus1 View Post
    While this is an issue that's not going to be relevant until you have completed an alpha version....

    How are you planning on having this project interact with other plugins?

    Edit:

    On second thought... what if this framework was bundled with a plugin manager app that served dual purpose, as an example, and as a necessary way to get the code into memory and bypassing the multiple apartment issue, and prevent multiple loadings of the code. Thoughts?
    To be honest, at this stage, I'm merely offering code that I wrote to fill a need, but recognize others may find it useful as well. So I really haven't put much thought into the big picture; but you do bring up an interesting point nonetheless.

    There should be a mechanism in place to only load classes that are needed, without loading a copy for each plugin that needs to use them. Unfortunately my knowledge of Lua itself doesn't yet cover all its nuances - with my normal design flow starting off with basic programming logic, and translating that to Lua syntax/methods.

    In that vein, the control should logically reside in each individual library, where regardless of how many times plugin authors attempt to import the code, that library would only be loaded if it isn't in memory already. This way the plugin authors can use a library without having to think about it. Ideally, I'd think that this test would exist in the library's __init__.lua file, where it would check to see if that code isn't already in memory before importing it again. Perhaps instead of just "import" statements, it would attempt to access that code first, in the structure of a pcall, and if it failed - it would then import it? Of course then comes the issue of at least library versioning, which is something currently shared by external plugin managers seeking to provide Minion/Curse Client functionality.

    Beyond that - I'm not sure entrusting it to a master plugin like an internal plugin manager is the best course of action - as this is functionality that should be handled by LotRO itself - leaving its necessity on borrowed time to begin with. If it goes, then everything else it does goes with it, and we're back to square one. That of course doesn't even include other potential issues of using such a plugin manager in the first place - such as putting something between a plugin and the game itself.

    In the end however, my experience so far has shown the community to be very hesitant about working towards any standards - all preferring to do their own thing, and either letting someone else decide the standard (i.e. Turbine) or putting other demands/limitations on an idea to the point where it becomes useless. Of course, it certainly doesn't help that authors are forced to play the role of the Professor on Gilligan's Island in order to pull off what they have already - when it comes down to it, it's enough of a pain to get something moderately useful out of the current API, that any additional work required to meet some kind of "standard" is basically adding insult to injury.

    The only thing we can really do is recognize potential issues, and keep them in mind as we go on - perhaps working out a way to compensate/react to them as new versions are created - considering the pace (or relative lack thereof) of API growth, we'd still end up far ahead of the curve. Turbine finally recognized that addons/plugins provide the game with more manpower/options than they could ever provide - however, they still have a lot of work left to do before we get to that point.

    Quote Originally Posted by Nekat View Post
    Interesting, are you planning on implementing (simple) xpath functionality?

    Turbine.Shell.WriteLine(myXML. selectNode("/classes/class[@name='Burglar']/Might"))
    instead of something like
    Turbine.Shell.WriteLine(myXML. childNodes[0].childNodes[1].Might);
    I would have to familiarize myself with xpath first, but there shouldn't be any issue with it. That being said, for now it's going to exist as a simple XML parser/navigator - using more mundane methods such as childNodes, getElementsByTagName and getElementById - at least until I get the UI generation part done. Basically, if this library was the only thing on my plate - there'd be nothing stopping me from making that the next focus - however, my Plugin priority is looking like this right now:

    Creating a basic XML library, in order to parse UI markup, in order to generate it, in order to provide a bit more flexibility and sanity to the UI for Palantir 2, so I can work on that and get it out by, if not before Isengard. And then I'll have a bit more freedom to tweak existing libraries for additional features. That is of course, if Turbine actually adds something substantial to the API by then - if not, I may have to reconsider devoting any more time to another Turbine-created system that is dead on arrival.
    [CENTER][IMG]http://i.imgur.com/wK9A7aa.png[/IMG]

    [SIZE=1][B][COLOR=white]75[/COLOR][/B] Fourohfour | [B][COLOR=white]75[/COLOR][/B] Artemedis | [COLOR=Blue][B]60[/B][/COLOR] Whiskeytango Foxtrot | [B][COLOR=#00ca00]50[/COLOR][/B] Mistah Boombastic | [B][COLOR=#00ca00]56[/COLOR][/B] Appetizer | [B][COLOR=#a7a7a7]25[/COLOR][/B] Aggromi | [B][COLOR=blue]61[/COLOR][/B] Onepointtwentyone Gigawatts [/SIZE] [/CENTER]

  13. #13
    Join Date
    Dec 2007
    Location
    Seattle, WA
    Posts
    7,600

    Re: An idea looking for feedback from authors...

    Quote Originally Posted by Digital_Utopia View Post
    In the end however, my experience so far has shown the community to be very hesitant about working towards any standards - all preferring to do their own thing, and either letting someone else decide the standard (i.e. Turbine) or putting other demands/limitations on an idea to the point where it becomes useless. Of course, it certainly doesn't help that authors are forced to play the role of the Professor on Gilligan's Island in order to pull off what they have already - when it comes down to it, it's enough of a pain to get something moderately useful out of the current API, that any additional work required to meet some kind of "standard" is basically adding insult to injury.
    I would much rather have a standard to work with, because that will accelerate ALL of our plugin development efforts, and let us make new stuff sooner.

    Although, without a Microsoft/IBM in the mix.... we're probably going to go the route of GTK/qt.

    Edit:
    For a manager to work with framework libraries, and bring everything into the same appartment (which part of me feels like we're defeating something Turbine set up for us), wouldn't the manager need to know what was a library plugin, what wasn't, and when it loaded itself, load all libraries, then load the plugins?
    Last edited by Almagnus1; May 15 2011 at 04:20 PM.
    Maley Oakensage, Captain of Elendilmir

    Alas Elendilmir, may you *jingle jangle* forever in the Forgotten West

  14. #14

    Re: An idea looking for feedback from authors...

    Quote Originally Posted by Almagnus1 View Post
    I would much rather have a standard to work with, because that will accelerate ALL of our plugin development efforts, and let us make new stuff sooner.

    Although, without a Microsoft/IBM in the mix.... we're probably going to go the route of GTK/qt.

    Edit:
    For a manager to work with framework libraries, and bring everything into the same appartment (which part of me feels like we're defeating something Turbine set up for us), wouldn't the manager need to know what was a library plugin, what wasn't, and when it loaded itself, load all libraries, then load the plugins?
    Well, if it were up to me, this is how it would work:

    Libraries would have a .library file (similar to the .plugin file)
    Libraries would be zipped, in order to exist as a single file
    Both .plugin and .library files would have a dependency/version section
    and a built in client plugin manager would handle loading requested libraries - once.

    This way there's a nice foundation for a proper structure/standard, and everybody lives happily ever after.

    unfortunately....I don't work for Turbine. So the best I'd be able to suggest is a special file for each plugin/library, that would contain such a dependency section, and a plugin-based plugin manager that would do the work that a client version would. Not ideal, but it could effectively work.

    Again, unfortunately - this requires authors to include such special files with their plugins/libraries, and to trust a third-party plugin manager to deliver the dependencies it asks for.

    Finally, it is worth clarifying that the only "libraries" we'll see in LotRO, are collections of .lua scripts and images. Since i.o libraries have been removed from this implementation of Lua (and for very very good reasons), even if the data (bits/bytes) functions/libraries still was there, we'd have no way of bringing in compiled libraries. Although the argument could be made for restricting i.o. functions to the plugin folder (and its subfolders) the fact that Turbine is against RT data access, is pretty much the final nail in that coffin.
    [CENTER][IMG]http://i.imgur.com/wK9A7aa.png[/IMG]

    [SIZE=1][B][COLOR=white]75[/COLOR][/B] Fourohfour | [B][COLOR=white]75[/COLOR][/B] Artemedis | [COLOR=Blue][B]60[/B][/COLOR] Whiskeytango Foxtrot | [B][COLOR=#00ca00]50[/COLOR][/B] Mistah Boombastic | [B][COLOR=#00ca00]56[/COLOR][/B] Appetizer | [B][COLOR=#a7a7a7]25[/COLOR][/B] Aggromi | [B][COLOR=blue]61[/COLOR][/B] Onepointtwentyone Gigawatts [/SIZE] [/CENTER]

  15. #15

    Re: An idea looking for feedback from authors...

    Time to dig this thread up again...

    Over the past 4? months I've been busy learning the Android API and working on an app, so this (and everything else Lua related) was placed on the back burner. Since Isengard is out, and I'm not sure how long this app is going to take, I decided to get back to working on Palantir v2, and as such, this concept.

    Since I already mentioned that the XML parser is working correctly, the next step is to take that parsed XML, and create a layout out of it. At this point I've managed to work out a way to do this without having to create a ton of "case" statements - and even better, to support external libraries.

    First off, classes are nothing more than tables, so finding a particular class via a string is relatively simple (via using assert, with a function that loops through the global namespace). So setting up a tag like < Turbine.UI.Window></Turbine.UI.Window> will work easily to not only create a new instance of that class, but to also import the required class in the first place (i.e. since import statements use strings).

    The next part is applying the XML attributes to the newly initialized class. In order to achieve this, an associative table will be created, keyed with the attribute names, and a sort of "wrapper" function as a value.

    This wrapper function essentially acts as the interface for the real function - for instance, for SetBackColor, it would look something like this:

    Code:
    backgroundColor=function(obj,val)obj:SetBackColor(Turbine.UI.Color(val[1],val[2],val[3]));end
    Where obj is the instance of the class, and val is a table containing 0 or more values. backgroundColor of course, would be both the key in the associative array and the XML attribute.

    So to reiterate, let's start off with a simple XML element

    Code:
    UI={
    < Turbine.UI.Window height="200" width="200" visible="true" backgroundColor="0,1,0"/>
    }
    and now some basic code to parse it
    Code:
    myUI=DigitalUtopia.XML.Document(UI); -- parse the xml
    testElem = myUI.childNodes[0]; -grab first element of the doc
    myUiElem = assert(findclass(testElem.tagName))(); -- create a new instance of the class it represents
    if (testElem.hasAttributes)then - check to see if it has attributes
         for k,v in pairs(testElem.attributes)do --loop through the attributes
              funcArray[k](myUIElem,string.split(v,",")) --call the appropriate functions (using custom split function to turn comma delimited values into a table
         end
    end
    in this case, funcArray is the aforementioned associative table that holds all of the class' function definitions. Now obviously, this "layoutInflater" so to speak, will be its own class, and within that class, there will already be a function array covering all the standard API UI classes.

    But what happens if you want to use an external library? Well, that's simple enough - provided that library authors wish to support this. All the author would need to do is define a similar function table within each class, returned via a getFunctions() method. This way, when the layout library comes across something like:

    Code:
    < DigitalUtopia.DUInterface.Slider/>
    it can import DigitalUtopia.DUInterface, create the new element, and call its getFunctions() method - which will return a function table- before going through the attributes.

    Now of course, this is just to show the basic implementation - when the inflater class is finished, the author that uses this library would just have to do the following:

    Code:
    myUI = DigitalUtopia.LayoutInflater.inflate(UI);
    myUI:SetParent(self)
    where UI is the XML referenced above.

    Now, at this point I obviously have a lot of polishing to do, but more importantly, I still have to work out exactly how referencing is going to work. I'm leaning towards having the inflater return not only the UI elements themselves, but also a sort of resource table that would allow authors to reference the individual elements by an id. So for instance:

    Code:
    < DigitalUtopia.DUInterface.Slider id="mySlider"/>
    would allow the author to reference it by something like

    Code:
    myUI.R[mySlider];
    and then apply the interface like so:

    Code:
    myUI.UI:SetParent(self);
    again, this last part is not finalized or anything - but that's what I'm planning on for now

    Additional Notes:

    Just to clarify as I go along, without having to make a new post each time:

    The inflater class will be "aware" of classes that extend other UI classes, via a "implementation" key in that class' function table. For instance, the pre-added UI class Turbine.UI.Lotro.Button will have implementation="Turbine.UI.But ton", which in turn will have implementation="Turbine.UI.Con trol". This will be used to "merge" function tables prior to going through the element's attributes. So, if you are a UI library author, and wish to allow support for your classes, even if you don't have any visible functions, you'll still need to have self:getFunctions() return a table with the implementation key, with a string value of the full class name you're extending - if you want authors to be able to access the functions of that class via the attributes.

    For instance, if you're extending Turbine.UI.Control, your self:getFunctions() method should return {implementation="Turbine.UI.Co ntrol"} - otherwise the inflater will only process the attributes that directly relate to your class (if any), as it will assume that you're extending Turbine.Object.

    It is worth mentioning that even if you do not actively support the inflater class, authors will still be able to include, and access an instance of your class via the XML layout- the only thing that will not be possible is setting your class' or any extended class' properties via layout attributes.
    Last edited by Digital_Utopia; Sep 28 2011 at 05:30 AM.
    [CENTER][IMG]http://i.imgur.com/wK9A7aa.png[/IMG]

    [SIZE=1][B][COLOR=white]75[/COLOR][/B] Fourohfour | [B][COLOR=white]75[/COLOR][/B] Artemedis | [COLOR=Blue][B]60[/B][/COLOR] Whiskeytango Foxtrot | [B][COLOR=#00ca00]50[/COLOR][/B] Mistah Boombastic | [B][COLOR=#00ca00]56[/COLOR][/B] Appetizer | [B][COLOR=#a7a7a7]25[/COLOR][/B] Aggromi | [B][COLOR=blue]61[/COLOR][/B] Onepointtwentyone Gigawatts [/SIZE] [/CENTER]

 

 

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

This form's session has expired. You need to reload the page.

Reload