Morpho XML Editor updates

[Dan Higgins]

Matthew,
    Obviously I didn't make it clear that there there may be 500 editor 
panel on the right and there is no need to click on the tree on the left 
when moving between them. Thus one cannot simply use tree selection 
events to save changes in the panels. And to keep the tree selection in 
synch with the panel being edited there needs to be communucation as 
panel widgets are selected, not when the tree is clicked.

Dan

----

Matthew Brooke wrote:

>
> Dan:
>
> >> I would like to point out that this interface has exactly the same 
> number
> >> of steps as the Wizard where there is a 'Save' and 'Cancel' button 
> for each page
>
> The point I'm trying to make is that the extra step in the editor is 
> unnecessary from the user's point of view (which is why only some of 
> the editor panels have save buttons, not all of them) , whereas all 
> the wizard pages require a "next" button to be clicked (because it's a 
> wizard...)
>
>
> >> there is NO EASY WAY TO DO THIS WITHOUT MAKING SUBSTANTIAL
> >> CHANGES TO THE WIZARD PANE CODE (OR THE EDITOR).
>
> No need to shout :-P   why wouldn't this work:
>
> a)  in morpho/editor/DocFrame.java, add a line to the valueChanged() 
> method of your SymTreeSelection class (which will get called every 
> time a user clicks on a tree node)
>
> b)  when this event occurs, check if you have one of your wrapper 
> classes (eg AttributePanel.java) in the right hand pane, and if so, 
> call its saveButton.doClick() method
>
> c) repeat for editor's "Finished" button listener
>
>
> That way the DOM gets updated whenever the user clicks a different 
> tree node and when they click "finish".  Unless I've missed something 
> major, this doesn't appear to be a substantial change?
>
> M
>
>
>
>
>
>
> Dan Higgins wrote:
>
>> Matthew,
>>
>>     I agree with most of your comments, except in 1) I would like to 
>> point out that this interface has exactly the same number of steps as 
>> the Wizard where there is a 'Save' and 'Cancel' button for each page. 
>> An advantage of repeating those buttons is that the panels in the 
>> editor are essentially identical with the pages in the Wizard.
>>
>>     Nevertheless, having the 'in-line' Save & Cancel buttons is 
>> somewhat confusing. The standard nested text panels on the right of 
>> XML editor were written to use focus events to keep the tree 
>> up-to-date as information is edited (and the appropriate tree node is 
>> selected as one selects new panels). We should do the same thing with 
>> special editor panels like those taken from the Wizard, but there is 
>> NO EASY WAY TO DO THIS WITHOUT MAKING SUBSTANTIAL CHANGES TO THE 
>> WIZARD PANE CODE (OR THE EDITOR). In other words, the existing editor 
>> panels were put together with the goal of minimizing changes in 
>> either the Wizard code or the XML editor code. Thus the Save button 
>> is needed to save any changes in the Wizard pages displayed in the 
>> editor (just reusing code from the Wizard).
>>
>>     Note that the problem is that the XML editor can display multiple 
>> pages - e.g. if one selects the the attributeList in the tree, a 
>> whole series of attribute pages will appear on the right side of the 
>> screen. One could then move from one page to another and never save 
>> the edits (because no events are triggered) until a whole lot of 
>> changes have been made. And the tree would not get updated while all 
>> these changes were being made. Maybe we could figure out how to do 
>> this without changing the wizard page code, but it would seem to 
>> require a lot of changes in the XML editor.
>>
>>     Otherwise, we would need to revise all the widgets used in the 
>> Wizard to handle/generate events. For textboxes, this might mean 
>> simply handling focus gained/lost events, but it would be more 
>> complicated figuring how to deal with other widgets like the radio 
>> buttons used to change subpanels in the AttributePage.
>>
>>     Frankly, I am very hesitant to start making the changes needed to 
>> avoid the Save/Cancel buttons prior to the planned 1.5 release in 
>> April. We still haven't completely frozen the code base and started 
>> seriously working on bug elimination and performace enhancements. It 
>> seems to me that substantaial code changes are needed to handle the 
>> wizard pages without the Save/Cancel buttons. And I am worried that 
>> we are running out of time! (So my real concern is priority of such 
>> changes.)
>>
>> Dan
>>
>>
>> --------------
>>
>> Matthew Brooke wrote:
>>
>>>
>>> Hey Dan -
>>>
>>> The revised editor looks great - I especially like the attributes 
>>> representation.
>>>
>>> I'd strongly vote for not having the additional "save" & "cancel" 
>>> buttons, though, for the following reasons:
>>>
>>> 1) we're making users perform an extra (redundant) step that they 
>>> wouldn't have to perform under similar circumstances in most other 
>>> user interfaces - the "save" functionality could be performed by the 
>>> editor without their having to hit a button.
>>> (this also applies to those buttons below the spreadsheet in the 
>>> main morpho data view that we were going to delete... :-)
>>>
>>> 2) It may be confusing for users, having "save", "cancel", "revert" 
>>> and "finish" buttons all in the same area (this is the feedback we 
>>> got with the original XUL wizard that Chris & I did, where we had 
>>> "dialogs" nested inside the existing wizard frame - even though we 
>>> grayed out the main wizard buttons).
>>>
>>> 3) I'm guessing the "save" & "cancel" buttons aren't shown in all 
>>> editing panes - only in the ones imported from the wizard (is this 
>>> true?). This may further confuse users - they have to hit "save" on 
>>> some panels, but not on others.
>>>
>>> 4) If the user fills in some "attribute" data (in your screenshot) 
>>> and *doesn't* hit "save", but clicks on other tree nodes and makes 
>>> other edits, and finally clicks "finish", will the "attribute" 
>>> changes never make it into the final DOM?
>>>
>>> It seems both safer and less confusing to get rid of the "save" & 
>>> "cancel" buttons, and "commit" the data based on change of focus - 
>>> e.g. insert the data from the wizard panel into the DOM when the 
>>> user clicks a different tree node and/or clicks "finish" - is this 
>>> feasible?
>>>
>>> Cheers
>>>
>>> M
>>>
>>
>>
>> -- 
>> *******************************************************************
>> Dan Higgins                                  higgins at nceas.ucsb.edu
>> http://www.nceas.ucsb.edu/    Ph: 805-892-2531
>> National Center for Ecological Analysis and Synthesis (NCEAS) 735 
>> State Street - Room 205
>> Santa Barbara, CA 93195
>> *******************************************************************
>>


-- 
*******************************************************************
Dan Higgins                                  higgins at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Ph: 805-892-2531
National Center for Ecological Analysis and Synthesis (NCEAS) 
735 State Street - Room 205
Santa Barbara, CA 93195
*******************************************************************