I have designed an html document editor and I wanted some help in resolving a design problem in it. The problem is as follows -
The document editor consists of a surface (JFrame) and a menu bar. Inside the surface I have three panels - a tool panel, text panel and status panel (which are all extensions of JPanel). The text panel has the customized text pane (extension of JTextPane). Now the problem is that - there are lots of scenarios where the menus and the widgets items on the tool panel need access to the underlying document model of the JTextPane. E.g. to implement list/paragraph dragging functionality, the ruler needs to know the position of the caret inside the document model, so that I can mark the paragraph whose left inset I need to increase.
The way I have organized my design right now is that - surface is a singleton, so to access the html document model inside the JTextPane you need to code your way through the following maze -
Give me surface -> go to text panel -> go to text pane -> go to document of the text pane
Another alternative to make the reference of the document inside the text pane static, so that it can be accessed directly.
TextPane.getTextDocument ()
Also the html document inside the Text Pane I am using is not customized right now. So I am just using the default HTMLDocument returned by the text pane. Though in future I may have to replace it with a more customized extension of HTMLDocument (e.g. to implement cusom tags)
I am somewhat of a design novice. Can some design guru throw some light/insight into this?
I think if you get 10 responses you'll get 11 answers. :-)
First, there is no need for a Singleton. In this scenario, it's just a way of cheating with a global variable. And what happens when you want to have two or three text documents open?
Do your menus have ready access to the tool panel? Since toolpanel is a sibling of the textpanel, and in a 1-1 relationship (I think?) it is somewhat "reasonable" for toolpanel to know about textdocument (have a link it) and a convenience method, getTextDocument(). And it seems reasonable for your widgets to know about their immediate parent, the tool panel.
That would be my way of approaching the problem - what links between objects "make sense". You want as little coupling as possible, but there are places where you do need coupling. Maybe I have misunderstood your problem, or maybe you think a lot differently than me, in which case you should do it another way. Also, you are making a best guess as to how your code might evolve in the future. Good luck with that! :-)
One big question for any solution - does the text document change? (e.g., is there a File->New menu or a File->Open menu?). If so, that needs to be considered. In my proposal, the JFrame, on a File->Open, would create the text document and then change the link to it in the ToolBar.
p.s. MVC purists - please add appropriate models and controllers! I just talked about the graphical components to keep things simpler...
p.p.s. Examples of "thinking ahead" for reasonable enhancements
Would this handle multiple JFrames open at once? Yes.
Would this handle a single JFrame, but with multiple documents (say, a tabbed interface for the text document)? Almost. The method has to be a little smarter to know which of the many documents is active, but you can easily imagine doing that.
How about when I need to hold a lot more info about the dicument, like the name (so Save gives a good default), last time saved, is it "dirty", is it HTML or XHTML or whatever... At this point, you'll probably want to add one more model layer. But you can sortof imagine, with one more layer of indirection (one more link) this being o.k. So it depends on how close you are to implementing #3 how you want to design.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm developing an application which displays images, and plays sounds from a database. I'm trying to decide whether or not to use a separate JFrame to add images to the database from the GUI.
I'm just wondering whether it is good practice to use multiple JFrame windows?
I'm just wondering whether it is good practice to use multiple JFrames?
Bad (bad, bad) practice.
User unfriendly: The user sees multiple icons in their task bar when expecting to see only one. Plus the side effects of the coding problems..
A nightmare to code and maintain:
A modal dialog offers the easy opportunity to focus attention on the content of that dialog - choose/fix/cancel this, then proceed. Multiple frames do not.
A dialog (or floating tool-bar) with a parent will come to front when the parent is clicked on - you'd have to implement that in frames if that was the desired behavior.
There are any number of ways of displaying many elements in one GUI, e.g.:
CardLayout (short demo.). Good for:
Showing wizard like dialogs.
Displaying list, tree etc. selections for items that have an associated component.
Flipping between no component and visible component.
JInternalFrame/JDesktopPane typically used for an MDI.
JTabbedPane for groups of components.
JSplitPane A way to display two components of which the importance between one or the other (the size) varies according to what the user is doing.
JLayeredPane far many well ..layered components.
JToolBar typically contains groups of actions or controls. Can be dragged around the GUI, or off it entirely according to user need. As mentioned above, will minimize/restore according to the parent doing so.
As items in a JList (simple example below).
As nodes in a JTree.
Nested layouts.
But if those strategies do not work for a particular use-case, try the following. Establish a single main JFrame, then have JDialog or JOptionPane instances appear for the rest of the free-floating elements, using the frame as the parent for the dialogs.
Many images
In this case where the multiple elements are images, it would be better to use either of the following instead:
A single JLabel (centered in a scroll pane) to display whichever image the user is interested in at that moment. As seen in ImageViewer.
A single row JList. As seen in this answer. The 'single row' part of that only works if they are all the same dimensions. Alternately, if you are prepared to scale the images on the fly, and they are all the same aspect ratio (e.g. 4:3 or 16:9).
The multiple JFrame approach has been something I've implemented since I began programming Swing apps. For the most part, I did it in the beginning because I didn't know any better. However, as I matured in my experience and knowledge as a developer and as began to read and absorb the opinions of so many more experienced Java devs online, I made an attempt to shift away from the multiple JFrame approach (both in current projects and future projects) only to be met with... get this... resistance from my clients! As I began implementing modal dialogs to control "child" windows and JInternalFrames for separate components, my clients began to complain! I was quite surprised, as I was doing what I thought was best-practice! But, as they say, "A happy wife is a happy life." Same goes for your clients. Of course, I am a contractor so my end-users have direct access to me, the developer, which is obviously not a common scenario.
So, I'm going to explain the benefits of the multiple JFrame approach, as well as myth-bust some of the cons that others have presented.
Ultimate flexibility in layout - By allowing separate JFrames, you give your end-user the ability to spread out and control what's on his/her screen. The concept feels "open" and non-constricting. You lose this when you go towards one big JFrame and a bunch of JInternalFrames.
Works well for very modularized applications - In my case, most of my applications have 3 - 5 big "modules" that really have nothing to do with each other whatsoever. For instance, one module might be a sales dashboard and one might be an accounting dashboard. They don't talk to each other or anything. However, the executive might want to open both and them being separate frames on the taskbar makes his life easier.
Makes it easy for end-users to reference outside material - Once, I had this situation: My app had a "data viewer," from which you could click "Add New" and it would open a data entry screen. Initially, both were JFrames. However, I wanted the data entry screen to be a JDialog whose parent was the data viewer. I made the change, and immediately I received a call from an end-user who relied heavily on the fact that he could minimize or close the viewer and keep the editor open while he referenced another part of the program (or a website, I don't remember). He's not on a multi-monitor, so he needed the entry dialog to be first and something else to be second, with the data viewer completely hidden. This was impossible with a JDialog and certainly would've been impossible with a JInternalFrame as well. I begrudgingly changed it back to being separate JFrames for his sanity, but it taught me an important lesson.
Myth: Hard to code - This is not true in my experience. I don't see why it would be any easier to create a JInternalFrame than a JFrame. In fact, in my experience, JInternalFrames offer much less flexibility. I have developed a systematic way of handling the opening & closing of JFrames in my apps that really works well. I control the frame almost completely from within the frame's code itself; the creation of the new frame, SwingWorkers that control the retrieval of data on background threads and the GUI code on EDT, restoring/bringing to front the frame if the user tries to open it twice, etc. All you need to open my JFrames is call a public static method open() and the open method, combined with a windowClosing() event handles the rest (is the frame already open? is it not open, but loading? etc.) I made this approach a template so it's not difficult to implement for each frame.
Myth/Unproven: Resource Heavy - I'd like to see some facts behind this speculative statement. Although, perhaps, you could say a JFrame needs more space than a JInternalFrame, even if you open up 100 JFrames, how many more resources would you really be consuming? If your concern is memory leaks because of resources: calling dispose() frees all resources used by the frame for garbage collection (and, again I say, a JInternalFrame should invoke exactly the same concern).
I've written a lot and I feel like I could write more. Anyways, I hope I don't get down-voted simply because it's an unpopular opinion. The question is clearly a valuable one and I hope I've provided a valuable answer, even if it isn't the common opinion.
A great example of multiple frames/single document per frame (SDI) vs single frame/multiple documents per frame (MDI) is Microsoft Excel. Some of MDI benefits:
it is possible to have a few windows in non rectangular shape - so they don't hide desktop or other window from another process (e.g. web browser)
it is possible to open a window from another process over one Excel window while writing in second Excel window - with MDI, trying to write in one of internal windows will give focus to the entire Excel window, hence hiding window from another process
it is possible to have different documents on different screens, which is especially useful when screens do not have the same resolution
SDI (Single-Document Interface, i.e., every window can only have a single document):
MDI (Multiple-Document Interface, i.e., every window can have multiple documents):
I'd like to counter the "not user friendly" argument with an example that I have just been involved with.
In our application we have a main window where the users run various 'programs' as separate tabs. As much as possible we have tried to keep our application to this single window.
One of the 'programs' they run presents a list of reports that have been generated by the system, and the user can click on an icon on each line to pop open a report viewer dialog. This viewer is showing the equivalent of the portrait/landscape A4 page(s) of the report, so the users like this window to be quite big, almost filling their screens.
A few months ago we started getting requests from our customers to make these report viewer windows modeless, so that they could have multiple reports open at the same time.
For some time I resisted this request as I did not think this was a good solution. However, my mind was changed when I found out how the users were getting around this 'deficiency' of our system.
They were opening a viewer, using the 'Save As' facility to save the report as a PDF to a specific directory, using Acrobat Reader to open the PDF file, and then they would do the same with the next report. They would have multiple Acrobat Readers running with the various report outputs that they wanted to look at.
So I relented and made the viewer modeless. This means that each viewer has a task-bar icon.
When the latest version was released to them last week, the overwhelming response from them is that they LOVE it. It's been one of our most popular recent enhancements to the system.
So you go ahead and tell your users that what they want is bad, but ultimately it won't do you any favours.
SOME NOTES:
It seems to be best practice to use JDialog's for these modeless windows
Use the constructors that use the new ModalityType rather than the boolean modal argument. This is what gives these dialogs the task-bar icon.
For modeless dialogs, pass a null parent to the constructor, but locate them relative to their 'parent' window.
Version 6 of Java on Windows has a bug which means that your main window can become 'always on top' without you telling it. Upgrade to version 7 to fix this
Make an jInternalFrame into main frame and make it invisible. Then you can use it for further events.
jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);
It's been a while since the last time i touch swing but in general is a bad practice to do this. Some of the main disadvantages that comes to mind:
It's more expensive: you will have to allocate way more resources to draw a JFrame that other kind of window container, such as Dialog or JInternalFrame.
Not user friendly: It is not easy to navigate into a bunch of JFrame stuck together, it will look like your application is a set of applications inconsistent and poorly design.
It's easy to use JInternalFrame This is kind of retorical, now it's way easier and other people smarter ( or with more spare time) than us have already think through the Desktop and JInternalFrame pattern, so I would recommend to use it.
Bad practice definitely. One reason is that it is not very 'user-friendly' for the fact that every JFrame shows a new taskbar icon. Controlling multiple JFrames will have you ripping your hair out.
Personally, I would use ONE JFrame for your kind of application. Methods of displaying multiple things is up to you, there are many. Canvases, JInternalFrame, CardLayout, even JPanels possibly.
Multiple JFrame objects = Pain, trouble, and problems.
I think using multiple Jframes is not a good idea.
Instead we can use JPanels more than one or more JPanel in the same JFrame.
Also we can switch between this JPanels. So it gives us freedom to display more than on thing in the JFrame.
For each JPanel we can design different things and all this JPanel can be displayed on the single JFrameone at a time.
To switch between this JPanels use JMenuBar with JMenuItems for each JPanelor 'JButtonfor eachJPanel`.
More than one JFrame is not a good practice, but there is nothing wrong if we want more than one JFrame.
But its better to change one JFrame for our different needs rather than having multiple JFrames.
If the frames are going to be the same size, why not create the frame and pass the frame then as a reference to it instead.
When you have passed the frame you can then decide how to populate it. It would be like having a method for calculating the average of a set of figures. Would you create the method over and over again?
It is not a good practice but even though you wish to use it you can use the singleton pattern as its good. I have used the singleton patterns in most of my project its good.
I'm trying to use a GridPane for a Sudoku 9x9 using FXML.
I'm fairly new in this field so I wanted to ask you guys before proceeding.
I've created a GridPane 9x9 and for now I'm using TextField in each node to display numbers and enabling the user to write a new number themselves.
My question:
Is it okay to create the 81 TextField's in pure java code or is
there a way to do it efficiently using FXML so I don't split my view
(Model-View-Controller) setup up?
Thanks in advance and sorry if my question is unclear, I'm having a hard time explaining it tbh.
Fxml is not the only (and in my opinion not the best way) to use the model view controller pattern in javafx.
The View basically describes how the application / windows / sections look. That can be done with pure fxml, but very often it won't be enough. Especially when you want / need dynamically built content (which in your case you do not really need). So you COULD just add those 9 grid rows and 9 grid columns and add TextFields into them using FXML.
However this seems very ineffective, since you could use loops and would remove a lot of time wasters while programming.
You can do that by either using a mix of fxml and code:
First load the fxml in your view class and then add to it using code.
Or you could use pure code (my preferred way, since i do not like using fxml if I can't do it in fxml only - and since that is often the case for me i just skip it).
The Model represents your data. Changes in that data will change the view. This is done with observers and binds in the view class.
The Controller manipulates data. Most commonly this is done using user input, but could also be achieved using other events.
However: Keep in mind that MVC is only a very loose pattern and does not define a clear way to do it, since it is not tailored to a specific language / framework. While there are tutorials out there that try to teach how to implement the MVC pattern in JavaFX they all interpret MVC differently and as a result the implementation is also vastly different.
I hope my description of how to structure the View in JavaFX using three different approaches helps you. If not please comment and I'll try to elaborate. :)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I'm developing an application which displays images, and plays sounds from a database. I'm trying to decide whether or not to use a separate JFrame to add images to the database from the GUI.
I'm just wondering whether it is good practice to use multiple JFrame windows?
I'm just wondering whether it is good practice to use multiple JFrames?
Bad (bad, bad) practice.
User unfriendly: The user sees multiple icons in their task bar when expecting to see only one. Plus the side effects of the coding problems..
A nightmare to code and maintain:
A modal dialog offers the easy opportunity to focus attention on the content of that dialog - choose/fix/cancel this, then proceed. Multiple frames do not.
A dialog (or floating tool-bar) with a parent will come to front when the parent is clicked on - you'd have to implement that in frames if that was the desired behavior.
There are any number of ways of displaying many elements in one GUI, e.g.:
CardLayout (short demo.). Good for:
Showing wizard like dialogs.
Displaying list, tree etc. selections for items that have an associated component.
Flipping between no component and visible component.
JInternalFrame/JDesktopPane typically used for an MDI.
JTabbedPane for groups of components.
JSplitPane A way to display two components of which the importance between one or the other (the size) varies according to what the user is doing.
JLayeredPane far many well ..layered components.
JToolBar typically contains groups of actions or controls. Can be dragged around the GUI, or off it entirely according to user need. As mentioned above, will minimize/restore according to the parent doing so.
As items in a JList (simple example below).
As nodes in a JTree.
Nested layouts.
But if those strategies do not work for a particular use-case, try the following. Establish a single main JFrame, then have JDialog or JOptionPane instances appear for the rest of the free-floating elements, using the frame as the parent for the dialogs.
Many images
In this case where the multiple elements are images, it would be better to use either of the following instead:
A single JLabel (centered in a scroll pane) to display whichever image the user is interested in at that moment. As seen in ImageViewer.
A single row JList. As seen in this answer. The 'single row' part of that only works if they are all the same dimensions. Alternately, if you are prepared to scale the images on the fly, and they are all the same aspect ratio (e.g. 4:3 or 16:9).
The multiple JFrame approach has been something I've implemented since I began programming Swing apps. For the most part, I did it in the beginning because I didn't know any better. However, as I matured in my experience and knowledge as a developer and as began to read and absorb the opinions of so many more experienced Java devs online, I made an attempt to shift away from the multiple JFrame approach (both in current projects and future projects) only to be met with... get this... resistance from my clients! As I began implementing modal dialogs to control "child" windows and JInternalFrames for separate components, my clients began to complain! I was quite surprised, as I was doing what I thought was best-practice! But, as they say, "A happy wife is a happy life." Same goes for your clients. Of course, I am a contractor so my end-users have direct access to me, the developer, which is obviously not a common scenario.
So, I'm going to explain the benefits of the multiple JFrame approach, as well as myth-bust some of the cons that others have presented.
Ultimate flexibility in layout - By allowing separate JFrames, you give your end-user the ability to spread out and control what's on his/her screen. The concept feels "open" and non-constricting. You lose this when you go towards one big JFrame and a bunch of JInternalFrames.
Works well for very modularized applications - In my case, most of my applications have 3 - 5 big "modules" that really have nothing to do with each other whatsoever. For instance, one module might be a sales dashboard and one might be an accounting dashboard. They don't talk to each other or anything. However, the executive might want to open both and them being separate frames on the taskbar makes his life easier.
Makes it easy for end-users to reference outside material - Once, I had this situation: My app had a "data viewer," from which you could click "Add New" and it would open a data entry screen. Initially, both were JFrames. However, I wanted the data entry screen to be a JDialog whose parent was the data viewer. I made the change, and immediately I received a call from an end-user who relied heavily on the fact that he could minimize or close the viewer and keep the editor open while he referenced another part of the program (or a website, I don't remember). He's not on a multi-monitor, so he needed the entry dialog to be first and something else to be second, with the data viewer completely hidden. This was impossible with a JDialog and certainly would've been impossible with a JInternalFrame as well. I begrudgingly changed it back to being separate JFrames for his sanity, but it taught me an important lesson.
Myth: Hard to code - This is not true in my experience. I don't see why it would be any easier to create a JInternalFrame than a JFrame. In fact, in my experience, JInternalFrames offer much less flexibility. I have developed a systematic way of handling the opening & closing of JFrames in my apps that really works well. I control the frame almost completely from within the frame's code itself; the creation of the new frame, SwingWorkers that control the retrieval of data on background threads and the GUI code on EDT, restoring/bringing to front the frame if the user tries to open it twice, etc. All you need to open my JFrames is call a public static method open() and the open method, combined with a windowClosing() event handles the rest (is the frame already open? is it not open, but loading? etc.) I made this approach a template so it's not difficult to implement for each frame.
Myth/Unproven: Resource Heavy - I'd like to see some facts behind this speculative statement. Although, perhaps, you could say a JFrame needs more space than a JInternalFrame, even if you open up 100 JFrames, how many more resources would you really be consuming? If your concern is memory leaks because of resources: calling dispose() frees all resources used by the frame for garbage collection (and, again I say, a JInternalFrame should invoke exactly the same concern).
I've written a lot and I feel like I could write more. Anyways, I hope I don't get down-voted simply because it's an unpopular opinion. The question is clearly a valuable one and I hope I've provided a valuable answer, even if it isn't the common opinion.
A great example of multiple frames/single document per frame (SDI) vs single frame/multiple documents per frame (MDI) is Microsoft Excel. Some of MDI benefits:
it is possible to have a few windows in non rectangular shape - so they don't hide desktop or other window from another process (e.g. web browser)
it is possible to open a window from another process over one Excel window while writing in second Excel window - with MDI, trying to write in one of internal windows will give focus to the entire Excel window, hence hiding window from another process
it is possible to have different documents on different screens, which is especially useful when screens do not have the same resolution
SDI (Single-Document Interface, i.e., every window can only have a single document):
MDI (Multiple-Document Interface, i.e., every window can have multiple documents):
I'd like to counter the "not user friendly" argument with an example that I have just been involved with.
In our application we have a main window where the users run various 'programs' as separate tabs. As much as possible we have tried to keep our application to this single window.
One of the 'programs' they run presents a list of reports that have been generated by the system, and the user can click on an icon on each line to pop open a report viewer dialog. This viewer is showing the equivalent of the portrait/landscape A4 page(s) of the report, so the users like this window to be quite big, almost filling their screens.
A few months ago we started getting requests from our customers to make these report viewer windows modeless, so that they could have multiple reports open at the same time.
For some time I resisted this request as I did not think this was a good solution. However, my mind was changed when I found out how the users were getting around this 'deficiency' of our system.
They were opening a viewer, using the 'Save As' facility to save the report as a PDF to a specific directory, using Acrobat Reader to open the PDF file, and then they would do the same with the next report. They would have multiple Acrobat Readers running with the various report outputs that they wanted to look at.
So I relented and made the viewer modeless. This means that each viewer has a task-bar icon.
When the latest version was released to them last week, the overwhelming response from them is that they LOVE it. It's been one of our most popular recent enhancements to the system.
So you go ahead and tell your users that what they want is bad, but ultimately it won't do you any favours.
SOME NOTES:
It seems to be best practice to use JDialog's for these modeless windows
Use the constructors that use the new ModalityType rather than the boolean modal argument. This is what gives these dialogs the task-bar icon.
For modeless dialogs, pass a null parent to the constructor, but locate them relative to their 'parent' window.
Version 6 of Java on Windows has a bug which means that your main window can become 'always on top' without you telling it. Upgrade to version 7 to fix this
Make an jInternalFrame into main frame and make it invisible. Then you can use it for further events.
jInternalFrame.setSize(300,150);
jInternalFrame.setVisible(true);
It's been a while since the last time i touch swing but in general is a bad practice to do this. Some of the main disadvantages that comes to mind:
It's more expensive: you will have to allocate way more resources to draw a JFrame that other kind of window container, such as Dialog or JInternalFrame.
Not user friendly: It is not easy to navigate into a bunch of JFrame stuck together, it will look like your application is a set of applications inconsistent and poorly design.
It's easy to use JInternalFrame This is kind of retorical, now it's way easier and other people smarter ( or with more spare time) than us have already think through the Desktop and JInternalFrame pattern, so I would recommend to use it.
Bad practice definitely. One reason is that it is not very 'user-friendly' for the fact that every JFrame shows a new taskbar icon. Controlling multiple JFrames will have you ripping your hair out.
Personally, I would use ONE JFrame for your kind of application. Methods of displaying multiple things is up to you, there are many. Canvases, JInternalFrame, CardLayout, even JPanels possibly.
Multiple JFrame objects = Pain, trouble, and problems.
I think using multiple Jframes is not a good idea.
Instead we can use JPanels more than one or more JPanel in the same JFrame.
Also we can switch between this JPanels. So it gives us freedom to display more than on thing in the JFrame.
For each JPanel we can design different things and all this JPanel can be displayed on the single JFrameone at a time.
To switch between this JPanels use JMenuBar with JMenuItems for each JPanelor 'JButtonfor eachJPanel`.
More than one JFrame is not a good practice, but there is nothing wrong if we want more than one JFrame.
But its better to change one JFrame for our different needs rather than having multiple JFrames.
If the frames are going to be the same size, why not create the frame and pass the frame then as a reference to it instead.
When you have passed the frame you can then decide how to populate it. It would be like having a method for calculating the average of a set of figures. Would you create the method over and over again?
It is not a good practice but even though you wish to use it you can use the singleton pattern as its good. I have used the singleton patterns in most of my project its good.
I'm developing a new application where I'll have some windows opened at the same time.
I'm currently trying to design the GUI and I'm struggling with two choices:
I could use a side navigation panel and using the center of the page to display the content of each panel. These panels would be stored according flyweight pattern and I would just hide/show them when navigation buttons are clicked (in order to save the content as is was when hidden, for example a user registration form).
I could use a front page displaying the menu all over it and use popups/new windows to show the content. These could be closed/minimized etc).
My problem is: What if all the panels are stored in my flyweight pattern? will it have a huge performance hit or will it still run smoothly with like 15 JPanels stored? (of course those JPanels will have sometimes lots of content in it such as forms etc).
What do you think would be the best easy-to-use/performance choice ?
Thank you :)
JTable rendering already uses the flyweight pattern, so a one column table is ideal for selection. A custom renderer can display an arbitrary thumbnail representation, while a ListSelectionListener can display arbitrary detail in an adjacent container. In the TableModel, consider an LRU cache if the individual data records are consuming too much memory.
As always with performance questions, prototype and profile.
As long as you don't attempt to hold more data than fits the heap reasonably, performance will be a non-issue nowadays (unless you do something exceptionally bad you will not notice any performance difference from the user perspective).
That said, unless you have pressing reason to hold on to GUI's you currently don't need - just let them get GC'd and recreate them as needed. The create-throw-away after one use approach is more flexible when the application needs to be modified and bears less opportunities for memory leaks.
As for the GUI design aspect, many people absolutely hate popups. They can also interfere with focus management/keyboard usage. But it still depends on which kind of control flow you need. Side menu bar is fine for many purposes.
I'd like to point out that the side menu is just a fancy reinvention of Tabbed Pane (which is a standard component you wouldn't need to implement yourself). Also, if things need to be done in a specific order - a Wizard like approach can also be a good choice (one Window that changes contents with each step completed).
I have the following requirement for a GUI, that the user will have a number of available actions to perform.
Currently, it is implemented a series of JButtons that the user presses.
But the actions are a lot, and in each version more "actions" would be possibly offered.
I am not sure how this is better presented/done in GUIs.
I have read that there are ways to form a gui describing relevant information in an xml file.
I am using Netbeans and swing. Is the xml a good idea, to describe the actions available and for example create the same number of buttons? If yes, how would I start on this?Additionally would a jtoobar be a good idea for the actions? I mean add as many buttons as needed in the Jtoolbar.
I guess this is a general question but I am not experienced in GUIs.
Any help would be appreciated!
Thank you.
There seems to be two separate issues involved:
How to describe and create a large number of actions?
How to represent a large number of actions in GUI?
#Tom's answer is for #1, and #Fabio's for #2.
You can use any textual format for #1, xml, csv, whatever you like. It's indeed a good idea to separate that from code. XML is great for hierarchical data, so it may be overkill if you just need a flat list:
<doc>
<action name="Action 1" id="ACT1" description="blah blah" icon="icon1.gif"/>
<action name="Action 2" id="ACT2" description="yada yada" icon="icon2.gif"/>
...
</doc>
But parsing such a simple XML is basically free, so you may as well just use it. You do not, however, need a full-featured XML GUI toolkit like SwiXML, unless you want to add many other GUI widgets with complex layout to your app.
Note the attributes I have in the above sample. id would map to a unique action command. You can display description and icon (I suppose you use icon already) any way you want. You could also have other properties like mnemonic, accelerator, etc., at which point using XML starts to pay off: you can add arbitrary attributes that you need.
One obvious omission in the XML is the actual actions themselves. I do not think you should put Java code in XML. It defeats the separation of concern. Instead you can define your action code in a generic way (e.g. extend AbstractAction) and map them with the action IDs. If you do use AbstractAction, you can trivially map your attributes to action property keys like Action.NAME, Action.LONG_DESCRIPTION, etc.
Now you have parsed the XML into a list of action objects, and here comes the second question: how do you display them?
JList (per #Fabio) is indeed the most efficient way. It's much more compact than a whole bunch of individual buttons, yet unlike JComboBox you can see many items at once, and you can easily add sort/search/filter.
But list is not very flexible. You could use a custom ListCellRenderer to display icon and tooltip (for description), but you'll start to stretch it when you want to group items.
I think the most flexible way would be a tree table, which allows you to have multi-level hierarchy. You can start with 2 columns, the first column showing action names hierarchically, the second column showing description.
You could put the table in a collapsible panel so that it can be hidden when user wants to focus on the results.
Now w.r.t. JToolBar, you're right that it's standard, however as Fabio's comment pointed out, it's bad usability when you have too many buttons on a toolbar (like M$ Word before ribbon).
What would be a great use of a toolbar, however, is to allow user to place actions of their choice onto the toolbar, like most popular desktop apps do. You could use a "Customize Toolbar" dialog, or simply let user drag-n-drop items from your list or table.
Unfortunately, many of the GUI constructs that I mentioned above are not available in JDK. You can find all of them (tree table, search/filter, collapsible panel, customizable toolbar, etc.) from the excellent commercial JIDE libraries (disclaimer: I don't work for them, though I sometimes wish I do), or you can find FOSS alternatives.
I don't know if i did understand your question well, but it seems to me that the JButton approach isn't the most efficient way to do such thing. Imagine that the number of actions starts to be really big, drawing too much buttons leads to an unintuitive and non-appealing interface. An alternative would be using a JComboBox or a JList, to list all the actions not requiring much space and having a single button "do!" to execute the action.
I hope it was useful ;)
Contrary to popular belief around a decade ago, XML is not usually a good idea. An appropriate language to express this "programming" in is Java.