![]() Potential Problems (or potential ugly workarounds) on headless systems that don't have Swing classes loaded (e.g. Mixes business logic and UI - something we have been trying to avoid Might help keep people thinking they have to edit the editor interface at the same time they modify a token syntax Prevents doubling the number of files we open Pros to putting CDOMToken and EditorToken as one file:Ĭan share implementation of getTokenClass() and getTokenName() The LST editor weight shouldn't be invoked unless the editor is started Should the CDOMToken also implement EditorToken? My theory here is that the "EditorToken" doesn't necessarily have to be the same class as the CDOMToken (in theory at least), but it at least implements the getTokenName() and getTokenClass() methods of CDOMToken (Between these items, a token is "unique" enough to associate 1:1 with a UI definition for the token.) This gives the text with which to identify the field. This interface will be developed through the discussion. This allows the editor to not need to know about each new token, but can detect tokens "on the fly".įirst, assume we have a set of objects that implement an interface called EditorToken. Just grab the secondary key set for the class. With that loaded, it will be pretty easy to get what you need. There is a DoubleKeyMapToList, first key is Class, second key is the Key name, list is the tokens to be used in order (if there is a second token it's due to compatibilty tokens). However, as of 5.16, this is (for the most part) resolved automatically, as TokenSupport caches these "parent"-based relationships when they are encountered. global tokens return CDOMObject not Skill.class, etc. The only challenge is remembering you have to test the parent classes, too. This tells you exactly where it can be used (Race, Skill, etc.). Public Class getTokenClass() is in every CDOMToken. A separate token can be loaded to provide an LST token (CDOMToken in 5.16) to have an interface that is not the basic text field entry. This will work for any token, regardless of whether a UI interface is defined for the token. The general plan is to have a default editor component which is a text field that allows token entry and validation. There are two editor modes, one for custom data (like we have today) and one for "edit in place" (which allows raw editing of the LST file) ![]() The tokens should be organized on the respective tabs (shouldn't be a complete mess of tokens when a Race is edited need some organization underneath Race. The editor should automatically pick up new tokens so as to avoid the editor getting out of date if new tokens are added to the system. We are not attempting to create a "Text" editor, similar to what can be done in any number of plain text editors used today by the data monkeys. Like many things, this has been thought through to a degree, but isn't fully cooked, so this is also posted for comments: I have distilled down a discussion I had with James a while back on the LST editor in order to give people a view of where we are and perhaps pick up portions of the project.
0 Comments
Leave a Reply. |