Let's look at the GroupLayout example from the Swing tutorial:
The GroupLayout code required to accomplish this is Find.javaThe equivalent Java Builder YAML file to accomplish this using MigLayout is a lot easier to understand and less verbose:
JFrame:
name: myFrame
title: Frame
content:
- JPanel:
name: groupLayoutPanel
content:
- JLabel: {name: label, text: "Find What:"}
- JTextField: {name: textField}
- JCheckBox: {name: caseCheckBox, text: Match Case}
- JCheckBox: {name: wholeCheckBox, text: Whole Words}
- JCheckBox: {name: wrapCheckBox, text: Wrap Around}
- JCheckBox: {name: searchBackwardsCheckBox, text: Search Backwards}
- JButton: {name: findButton, text: Find}
- JButton: {name: cancelButton, text: Cancel}
MigLayout:
constraints:
- label: cell 0 0
- textField: cell 1 0 4 1, grow
- caseCheckBox: cell 1 1
- wholeCheckBox: cell 2 1
- wrapCheckBox: cell 1 2
- searchBackwardsCheckBox: cell 2 2
- findButton: cell 5 0, grow
- cancelButton: cell 5 1, grow
With this, I have decided to take the project more seriously and create a proper URL for it.
From now on javabuilders.org will point to the standard Google Code site.
No code released publicly yet, but I hope to have a 0.1 release by end of this month.
P.S. I am still torn on the design of the layout manager...to keep the control constraints separate under the layout manager node, or allow entering them at the control level. Here's an alternate version of the layout above with the constraints embedded at the control level:
JFrame:
name: myFrame
title: Frame
content:
- JPanel:
name: groupLayoutPanel
content:
- JLabel: {name: label, text: "Find What:", constraint: cell 0 0}
- JTextField: {name: textField, constraint: "cell 1 0 4 1, grow"}
- JCheckBox: {name: caseCheckBox, text: Match Case, constraint: "cell 1 1"}
- JCheckBox: {name: wholeCheckBox, text: Whole Words, constraint: cell 2 1}
- JCheckBox: {name: wrapCheckBox, text: Wrap Around, constraint: cell 1 2}
- JCheckBox: {name: searchBackwardsCheckBox, text: Search Backwards, constraint: cell 2 2}
- JButton: {name: findButton, text: Find, constraint: "cell 5 0, grow"}
- JButton: {name: cancelButton, text: Cancel, constraint: "cell 5 1, grow"}
MigLayout
This is less verbose, but I find it is also less clear..and some different layout managers have more complex constraints than just pure text (e.g. GridBagLayout). Plus, in this case multiple MigLayout constraints that are comma-separated need to be escaped in quotes, since comma is a reserved character in YAML.
Any opinions on this?
7 comments:
Your second snippet looks awfully familiar to Groovy's SwingBuilder ;-)
yeah, well...that is the goal somewhat :-)
But I like the first approach more. Keep the base control definition separate and the layout constraints separate.
maybe it is a bit more verbose, but I find it a lot more clear and easier to maintain when you have to update the layout later.
I want to make sure my approach handles long-term maintainability well...
I also prefer the first approach. It follows separation-of-concerns principal.
It's also similar to HTML + CSS where you describe content using HTML and describe layout (constraints) using CSS.
I actually decided to allow both, most likely.
On large layouts, first approach is nicer. But after experimenting with layouts where you may have nested JPanels, it's less verbose to use the second option.
Being able to match both of them, depending on the scenario is probably the best option.
But I'm not 100% decided yet...
I like the second approach much better because it allows you to keep all the information about a single control together in the same place, but I think supporting both approaches would be even better.
If the constraints were longer, you could allow three syntaxes (Syntaxi? Syntax?)
Aside from the two you listed, you could have one where the constraints sit as indented items (nodes) directly under the definition instead of attributes)
As long as we're talking about flexibility, I'd like to be able to feed it from a file or code (although a string in the code might have trouble keeping the YML indentation correct)
This has the advantages of not spawning another file and allowing some programmatic adjustment of the text at run-time.
A really nice way to implement this might be to have one function that reads and parses the YML into a DOM object, then another that takes a DOM object and builds the panel.
This way we could create the DOM object on our own, or progmatically modify the document to suit our runtime needs.
Of course, a helper would take the name of the file and generate the screen straight-away... don't want to make things more complex.
runescape money
runescape gold
runescape money
runescape gold
You do not need any skills and more necessary rohan crone for a regular attack, but it still looks like you are using a skill. The armors and weapons which we can use our own rohan gold to buy our favorite is looking very nice. In some places you can not understand what you are doing and sometimes you did not know why and where need to spend the expensive and more rohan online crone. You can bring your own rohan money to buy Still Scroll from shop and use it on someone who you think might use bots in game. If he is confirmed to use bots later, you will get 3 equipments and some rohan online gold from him.
Post a Comment