I have a best practices type of question. I am working on a new application and one of the windows has so much information on it that I do not think there would really be enough tab space and would be difficult to use.
I have seen some other sencha apps that use a left column tree list control as the navigation and the right column changes based on what option is selected on the left.
I can think of a couple of ways to do this but is there a best practice on the best way to hide/show the right column forms based on the selection in the left column?
It is a very common pattern. That design is seen, for example, in Windows Explorer and most email clients. It follows that people want to copy it in Ext. I don't think there's a clear best way to do it, just lots of options and many bad ways to do it.
There are a number of factors to consider.
Will the right-hand section show a single view at once or will it allow access via tabs to the previously accessed items?
Are the right-hand views all the same or are they different? In other words, do they appear identical but just contain different data or are they totally different?
When a view on the right-hand side is closed should it be destroyed or hidden? Note that if it is destroyed then state will be discarded (including things like scrollbars) whereas if it is hidden then most state will be preserved when it is reshown.
Are the tree items all known in advance or are they data-driven?
Answering these questions helps to determine some of the basics, like what layout to use for the right-hand section (fit, card, tab, ...). Generally the surrounding UI is written using a border layout as that allows the navigational tree to be collapsed and resized.
One common mistake that I would advise avoiding is the use of static ids. A UI design like this encourages it but you should avoid them. They save a bit of effort early on for long-term pain as a project advances.
If you want to run some of your own thoughts past us I'm sure someone would be willing to comment as to whether you're straying into dangerous territory.
1. The right hand section would be a single form at a time.
2. Each right hand side would be a different form with different information.
3. I think rather than destroying it would be hidden.
4. The tree is fixed and not dynamic.
I am basically trying to replace what would probably be 20 or more tabs with a nice structured list.
> What is the better option for not using ids?
I think it is important to ask 'to do what?' For selecting items using Component Queries? Use itemId, it does the same thing but the id's only have to be unique within their containing component. (And they don't affect DOM stuff - which I try to avoid at all (well not really all, but plenty) cost, not being a html/css dude but a plain old programmer) For the rest, I don't think you should need them? But then again 'to do what?'
For the rest I agree with Skirtle, propose your design and people can either say Halleluja or provide points of improvement
I would be interested in this too.
I have gone for the left hand panel (within border layout) being data driven from the server to automatically create the menu / selection nodes (not using tree but similar principle). When user selects a node it fires an event containing the selection id and the reference of the viewport for the content using Tibco Pagebus which my view controllers are listening for. The controller for the relevant data then matches the id from the event and renders it content into the viewport panel also obtained from the event.
I was trying to get a flexible approach to structuring my ui. It seems to work okay but would be interested to know of how others are doing it.