Extending Builders: Layout Builders

[Tom Schindl]

Am 29.11.12 17:38, schrieb Richard Bair:
>> Coming back to this I think the easiest solution would be to:
>> a) have constraint objects (HBoxConstraint, ....)
>> b) haveing $layoutPane$.add(Node,Constraint)
>> c) having Node#setLayoutConstraint(Constraint)
>>
>> This makes b) simply a convenience method for c).
>>
>> Why do we need c) well I don't see how we can provide all the different
>> list operations (e.g. bulk operation) with the API Tom E is proposing
>> (List.addAll, List.set, List.add).
>>
>> It would have the advantage that FXML does not have to be changed
>> because it is still the serialized object graph.
>>
>> Drawback: we'd have to have this layoutConstraint-Property in an area of
>> the framework that doesn't really know about layouts but is dealing
>> generic scenegraph/graphic stuff which might the original reason why
>> static stuff got introduced because at its heart JavaFX is not a widget
>> libary but a graphics framework.
> 
> Actually, every node already has properties on it to support layout -- isResizable, layoutBounds, and so on. So having the constraints on the Node fits right in (and in fact is how we had done it previously). The bigger concern (if I remember correctly), is what is the *type* of this constraints object? Do all layout containers have to cast this and perform an instance of check? Having to do an instance of is distasteful, as is having a base class type that really isn't overly useful (you are likely to fail in finding a least-common-denominator for all constraints types).
> 
> Further, one advantage to having the layout constraints in the dynamic properties map is that you can have the constraints for two different layout managers at the same time. Niche, but the idea is that you could move a node from one layout container to another and it would just have the right settings. I don't think that is really all that important, but it is a use case.
> 

Correct and but what if they by chance use the same key for different
values, then you hit an even worse problem today ;-)

> It really is one of those situations where having a nice dynamic language would have been slick.
> 
> So the question I have here is, what is the type of the layoutConstraints (Object? LayoutConstraint?)? How does a layout container implement getting a constraint -- instance of and casting?

One way of thinking could be that Constraint is a map like construct
because then the layout containers access their information through the
same means they do today and don't have to cast to anything

class Constraint {
  private Map<String,Object> data;

  protected void set(String key, Object value) {
     data.put(key,value);
  }

  public <O> get(String key) {
     return data.get(key);
  }
}

And then you have concrete subclasses e.g.

class HBoxConstraint extends Constraint {
  public void setHgrow(Priority priority) {
    set(key,priority);
  }

  public Priority getHgrow() {
    return get(key);
  }
}

So that users have a type-safe API.

Tom

-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834