Imported from previous forum
New local ATDL requirements will employ control widgets that are lined up vertically in four columns, and will also require continuous horizontal line separators that cross all four of these columns.
It is not clear to me how to reconcile these two different requirements in one piece of ATDL.
In other mark-up languages, there are <span> concepts that allow a widget to span two or more columns, and pre-prepared widgets for a horizontal line separator.
I don’t see any such concepts in the FPL FIXatdl v 1.1 specification document.
Has anyone come across similar concepts in ATDL before? How would this requirement be implemented in ATDL?
I had a similar problem, too. I think that ATDL does not cover the part of how to lay out components within a panel, other then via orientation. It is up to the implementation to use a border like layout, or a grid one etc.
As a workaround, I suggest you define your ATDL layout as a big panel with vertical orientation, and within it:
- a panel with horizontal orientation, containing the controls
- a panel with horizontal orientation, containing the line separator
- etc.
I'd go with the workaround proposed by Dragos. However, there is no line separator control defined inATDL. At the time we defined the standard we felt that controls of that type would encroach on the look-and-feel of the OMS and that some would simply ignore them. The controls defined in ATDL are pretty basic and are provider mainly for user input. We had an effort (in early 2012?) to add funtionality and new controls to the layout schema. But that has lingered.
-Greg
Thanks Guys.
I've gone with Dragos' workaround for now, though it definitely is not pretty and makes for some unfortunately fragile markup.
It would be just great to have ATDL updated to provide real mark-up when a real look and feel representation of some kind is required, rather than merely an implementation guide, but maybe this is out of the scope that the ATDL maintainers would like to define.
An ability to define the orientation of a label [with respect to the input field] would also be wonderful. As it is I am left with the feeling that rather too many compromises have been made with the original user requirements.
Andrew