@atomix said:
Now back to the implementation and focus in efficient code side...
What is so painful in Nifty i’ve remember @toolforger once said is the String parameters… just don’t use it too much. Overhead of parsing simple and basic strings again and again can be quite a lot. Parsing a String based composed parameter like MigLayout constrainst in other hand are worth the performance cost you have a parser to slurp fast in the string.
Note that Layout data is a “special tiny little lovely” kind of Data that only we will care 'bout if we have to deal with Layouting. More over its Builder will be fine without Bean convention…, so what’s the point of set, get when you actually made it from a Builder.
Now if you can simply put aside some verbose convention of Bean object, and some BuilderPattern as i said above.
so why
[java]
element.getLayoutHint().setFillX(40).setFillXType(Unit.Percentage).setFillY(40).setFillYType(Unit.Percentage)
[/java]
but not
[java]
$(element).fillX(40,Unit.Percentage).fillY(40,Unit.Percentage)
[/java]
or even
[java]
$(element).fill(40,Unit.Per,40,Unit.Per)
$(element).fill(40,Unit.Pix,40,Unit.Pix)
[/java]
also
I repeated the “$” symbol here as is actually quite an interesting and bright idea from JQuery (compatible with Java) to cut down the length of your code when you need to type them fast, and to deal with Layouting and GUI is one solid case.
Later… what will be more awesome than using the same simple to traveling around screen element trees and add behaviours with the same syntax.
[java]
$(screen)._find(“button*”).onClick(new Runnable(){ });
$(screen)._find(“button”)._relateTo()._find(“label”).onClick(new Function<Element,Element>(){
public Element apply(Element label){
label.setText("HelloWorld);
}
});
[/java]
I’ve been considering this and I think that the option for setting params will likely provide both methods. When I say both, I mean the set.set.set portion of the Builder pattern, as well as the string params.
It will, however be up to the Layout implementation to provide these individually… meaning that casting would be involved.
The String params will be a bit smarter than must follow syntax… so for instance:
“[.3][.3[.4]”
“[30%][30%[40%]”
“cols [30%][30%[40%]”
“columns [.3][.3][.4]”
“.3,.3,.4”
“30%,30%,40%”
“cols .3, .3, .4”
columns 30%,30%,40%"
“[30%][30%][]"
"[30%][][40%]”
etc, etc…
would all produce the same results.
The layout would likely be flagged for update, meaning it will only parse once unless some parameter is changed.
The individual component params are separate, and only need to be parsed individually if one changes… and only parsed once for each change.
The params will be converted to a generic LayoutParam that has a ParamType, UnitType and <T> Value (which has a Type and Value associated with it), as an individual LayoutParam might contain more than one value.
LayoutHints will now store a List of LayoutParams so there will really be no need to create individual implementations of LayoutHints per Layout.
I believe that the backing should be generic enough to support both approaches that you and @rockfire have discussed, as I like portions of both… but no matter what I decide to do as a final, will be open enough to allow (as a for instance) you to implement the a JQuery type interface over.