pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From calathus <calat...@gmail.com>
Subject Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Date Fri, 28 Jan 2011 23:45:57 GMT
On Fri, Jan 28, 2011 at 3:30 PM, Greg Brown <gk_brown@verizon.net> wrote:

> > I think using BXML like layout language separated from programming
> language would make sense.
> > But the current BXML is almost full programming language like JSP.
> That is not correct. BXML is primarily for UI construction. Scripting is
> optional (and unrelated to the actual markup).
> > From my experience using Pivot one month, I feel it would be better to
> have more concise layout language than BXML, which is dedicated to only for
> layout information. For instance boxpane/tab/split pane etc are layuout
> object. on the other hand, radio button/TextInoput etc are information
> receptor which should be part of Programming language (Java/Scala).
> BoxPane etc. are used for layout but they are also Components (like
> RadioButton, etc.). Further, they are all beans, which makes them valid
> elements for use in BXML.

Whether it is component or not are not matter here like block is expression
or not. In other word it matters whether it is terminal element or not.
These TextInput class etc are sort of terminal element. And often they are
associated with some data used from programming language. And from
programming point of view, what kind of GUI representation are used is not
 important. Just we need to get/set data. So if these GUI class class
implements such API, it is much easier to access the data. right now if we
map some data to some GUI element, we need to cast concrete GUI class, and
getText and convert data each time. Another way to achieve this is to use
some adaptor which implement this API in order to wrap these GUI 'terminal'

> > And from programming point of view,  the GUI aspect should be hidden from
> API level. That means they should just look like some String to some type
> converter. It should be associated with these type information, and provide
> some getter/setter to access user input data.
> That sounds really abstract (i.e. difficult to use and understand).

> G


View raw message