pivot-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Superstring Media <superstring.me...@gmail.com>
Subject Re: Pivot, Scala, Gradle, Life, the Universe and Everything
Date Sun, 30 Jan 2011 02:49:50 GMT
Hi all,

I agree, the importance of keeping configuration and code separate has become VERY important
to me. This has lead me to having fewer objects that are capable of having more behaviours.
The objects are injected with rules which capture all the non local variables. The rules are
assembled into different configuration files (for graphic, sonic, tools, etc) which align
with different related objects (contexts) and an object (or many objects at once) can instantly
have their look, feel and behaviour changed just by activating different configuration/s.

I'm hoping that once these configurations are specified (a lot of work but at least they are
soft-wired!) they will be loaded by Pivot into a configuration manager which is likely based
on the Dictionary and binding components in the Pivot API. An important part of this is to
have the ability to de/serialize JSON files in and out of the configuration manager at anytime
(via user interaction). I'd be looking at a straight forward JSON API to help here or maybe
BXML, although it looks like BXML may be to inflexible. I can see the purpose in using BXML
to erect a UI or an object graph but then it seems unnatural to use it to update the erected
structure. I'm still looking into what possible API might be most useful for this.

The way the configuration manager (with its contexts) works is similar to CSS where they provide
rules that renderer objects in turn lookup by key selectors to change the graphic, sonic or
other behaviour of the application. The keys work like an indirect binding system between
the model and other objects and the rules they use. After working with music notation and
many other music related aspects this is the system I came up with, not sure if this type
of dependancy injection system has been developed elsewhere?

Here is a high level diagram of the core modules and their basic interaction:

To me what matters most is to define the app the way the features dictate, then if possible
find an API that thinks along the same lines. Onwards then!


On 2011-01-29, at 1:27 PM, calathus wrote:

> On Sat, Jan 29, 2011 at 1:44 AM, Philippe Lhoste <PhiLho@gmx.net> wrote:
> On 29/01/2011 10:26, calathus wrote:
> When we write GUI application in Java, the most important part is GUI
> application logic (description of user interaction), not layout.
> So we don't want to bother with layout in Java code level, also some GUI
> object should be determined by the data type used in the application.
> For instance, if type is boolean, we may want to map to check box etc.
> And if we want to change these data type, we should not have to modify
> the layout(most of case) file.
> I agree with most, but not all. I think all GUI should be described in separate files,
indeed, with no logic in it (or, at best/worst, only code pertaining to GUI logic).
> But the leafs must be part of this description: if the type is boolean, the GUI designer
can choose to implement it with radio buttons, combo box or even a list, if they need/want
it. It is not a concern of the code.
> I think some missing ingredient here was the systematic default specification mechanism
like CSS in HTML.
> If we start modifying layout for customized GUI object, the layout files are going to
depend on data type. 
> for instance, if the GUI object is specified as check box, and later the data type is
changed to String or enumerated type, such GUI object is no longer appropriate.  Or we may
need to go through all layout files to change to appropriate GUI object. 
> Also many cases, systematic use or default for bold or color is important to have nice
look and feel. if it has css like another file shared among several layout files, we can achieve
this easily. Definitely BXML can introduce such idea also(we may calll it BCSS).
> More concretely, CSS like pattern matching and some grouping by name('class' in CSS,
but confusing in programming language), identification with id  can be used here as well as
the structure based pattern if we map the structure in XML(but may not be so important).
> For instance if some <bxml:ref =abc /> is mapped to list from checkbox, it can
overwrite the mapping by:
> abc => checkbox
> groupA => checkbox
> Most of case, these mapping will be done based on associated data type, but it cab be
overridden by BCSS file.
> Basically, this will achieve the goal to eliminate data related information from layout,
and layout related information from application logic(Java).
> I agree fully with the concept of separating code and GUI, and there are several approaches
for that. Martin Fowler made a series of articles covering pros and cons of such approaches:
some designs are better suited to low level machinery (control design), others are better
for higher level GUI design, with one or the other allowing better testing (replacing with
mock objects), and so on.
> I wonder if Visage could be used for designing GUIs for Pivot. I haven't looked at its
design recently, if it needs a library bigger than Pivot, it might not be worth the effort...
> -- 
> Philippe Lhoste
> --  (near) Paris -- France
> --  http://Phi.Lho.free.fr
> --  --  --  --  --  --  --  --  --  --  --  --  --  --
> -- 
> Cheers,
> calathus

View raw message