OK, below is the info I originally sent to the ODesk contractor a couple of years ago:
First, some background. Everything in a Quest game is an element. All objects that appear in the game are elements, rooms are elements, the player is an element, even the game itself is an element.
All elements have attributes. The element's name is an attribute, its description is an attribute, any script attached to it is an attribute, etc.
When editing a game, you've seen files like CoreEditorObjectSetup.aslx which contain definitions for how the editor is layed out. This file specifies the type of controls that are shown for each attribute of an element. For example, an object's "name" attribute is editable with a textbox, which has the caption "Name".
In addition to the "friendly" layout of the editor, on the desktop version there's an "Attributes" tab for each element, which allows the user to go in and add, modify and delete all attributes directly. This control is loaded wherever <controltype>attributes</controltype> appears in an editor aslx file, and is always on the tab called "Attributes" which is currently hidden from the web editor - this is because the tab specifies the <desktop/> flag.
So the first thing to do is remove that flag. You'll then get errors when the editor is running because the "attributes" control does not exist in WebEditor, so you'll need to implement this control.
Implement the control by adding a new switch case to RenderEditorControl in ElementEditor.cshtml. Like the script editor, this should call an Action which will render a new partial view.
Look at WFAttributesControl in the EditorControls project to see the WinForms version of the attributes editor. It shows a list of all attributes for the currently selected element. When an attribute is selected, a "MultiControl" is rendered, allowing the user to set the type of the attribute and enter a value. We already have the concept of a MultiControl in WebEditor - see RenderMultiControl in ElementEditor.cshtml. I expect this will need to be refactored out of ElementEditor, so that the new Attributes partial view can access it too.
I wouldn't worry about the "Inherited Types" section at the top of the attributes control yet. We can implement this after we have implemented the attributes editor section itself.
One thing we will have to bear in mind is that the other editor tabs are all able to edit the same attributes. For example, when a user enters an Alias for an object on the Setup tab, that changes the value of the "alias" attribute. So, when the user clicks on to the Attributes tab, we need to ensure that they see the latest values there, and when they click elsewhere the attributes will need to be saved. Currently, elements are only saved when the user clicks on another element in the tree. We will need to change this so that the element is also saved when the user clicks on the Attributes tab, so then the attributes editor will be seeing the latest values.
I think that when the user clicks the name of the attribute in the attributes control, the multicontrol for that attribute should be loaded via AJAX. Then when they click on a different attribute name, it should be immediately saved.
That's quite a lot to think about so I hope I haven't overwhelmed you with information! I think we just need to break this up into steps. For now, I would just like you to:
- make the Attributes tab appear in the WebEditor
- create a very basic attributes viewer - not even an editor yet, so we'll just be listing the names and values of the attributes for the current element.
I think that will do to start with - then we can move on to actually making those attributes editable, and updating when and how the element is saved.
The contractor did indeed do some of that, but it doesn't work very well. If you grab the code and remove the <desktop/> flag from an attributes editor, you'll see the current state of things.