Re: [OT] Best way to isolate a GUI?

[David Marceau <davidmarceau@sympatico.ca>]

Jano wrote:
> 
> Hello,
> 
> as for my (lately) frequent questions, you may be aware I'm starting a
> new project in Ada. Well, the matter is that I want the core
> functionality to be isolated from the GUI. And that's the question:
> how's the best mean to do that.
Define an api being a set of services which you promise not to change in
the future and will remain.
If ever there needs changing, your api will grow.  If a service needs
one more parameter, add a service with the same name but increment the
service name i.e. adaToBlahLANGUAGE(someAdaType, someBLAHLANGUAGETYPE)
has another similar service adaToBlahLANGUAGE2.
I am certainly not encouraging adding parameters to services.  The
number of parms should be kept to a minimum always to reduce service
complexity.
The api will do a few things:
1)convert data from ada to a destination language
2)convert data from a source language to ada
3)receive data from a source language 
4)send data to target language
5)in general other languages understand c types so usually that's the
target language and language type used to 
send and receive along with some other information.  i.e.  Ada to C to
TCL, or Ada to C to Java, Ada to XmlAda to AWS to XMLsocket to Flash
Actionscript, Ada to ming to swf to aws to web browser flash.
6)like file/socket apis, consider using a handle as the first parm for
all the services in the api itself.  Consider it as an escape mechanism
for using global vars in your api via some services to request the
global data when necessary.
7)As a rule of thumb two or three more parms is acceptable.  Getting
beyond that number is going to require a great deal of justification
IMHO.  For example setting and getting an object attribute requires a
handle, the object and a default/setValue.  Ideally after preparing an
object by setting some attributes you wish it to do something useful. 
That useful service ideally would have a return value somewhere as a
parameter or a real "return value" and that's it.  Keep in mind a return
value or a parameter for a service may be an object with many
attributes.  This object may even represent a tree object.  That is why
many parameters should not be necessary.  This will keep the api highly
maintainable.  This is an approach that can be used in any language.

This approach is absolutely necessary for backward compatibility in both
binaries and source.  If ever someone breaks this rule usually it shows
up with symptoms later on due to complexity and bugs :)

> 
> I've thought the following:
> 
> 1) Use AWS and let any browser do the rendering. That's not really
> isolating the GUI, because all the generating code would be inside the
> core (unless I also apply):
> 
> 2) Use sockets to communicate the two processes.
> 2.a) Use regular Ada streams to pass data types.
> 2.b) Use some other protocol, for example [compressed] XML.
> 
> 3) Your sugestions welcome.
> 
> I would want that the isolation be such any kind of GUI can be build on
> top. Maybe even made two of them run concurrently. For example, web
> reports via AWS and a control GUI with native look.
> 
> Any have prior experience? Some successful example on the wild to check?
> 
> Thanks in advance,
> 
> --
> -------------------------
> Jano
> 402450[at]cepsz.unizar.es
> -------------------------
How about:
1)get flash mx player
2)get ming sdk(flash file generator)
3)get aws(ada web server)
4)get example actionscript for flash mx.
5)Build a prototype in flash mx.
6)rewrite the prototype as c/ming code to generate swf.  Shove the
generated swf to the web browser on the client side creating the gui.
7)make whatever communication from the browser go to AWS via XMLsocket
in flash's actionscript which resembles javascript.
8)This doesn't imply an ada binding to ming however ideally it could.
9)This does imply some c code in the solution however if the ada
bindings existed it wouldn't have to.
10)Although this does imply embedded actionscript into ada/c code, it is
equivalent to the TCL/TASH approach IMHO :)

Keeping in mind you want two different kinds of gui structures:
1)get ada web server
2)explicitly require anybody connecting with your web browser download
the tcl plug-in to install in the web browser.
3)build a prototype in tclscript
4)shove the tclscript to the web browser on the client side creating the
gui.
5)communicate with sockets to AWS from the tclscript.(I don't know if
this is allowed since I have never used the tcl-plugin.)
I would imagine it should be possible.  Xml what the hell not that I am
a fan.
6)this implies embedded tclscript in the ada code to generate the
interface.


As you can see there are two guis served up by aws, flash and
tclscript.  Actually three if you count html forms :)
How you split up the tiers is up to you.  But I could imagine a few
layers:
1)tcl gui in ada(request and response)
2)flash gui in ada(request and response)
3)html gui in ada(request and response)

4)aws in ada

5)business rules in ada, prolog, clips...

6)data storage in ada, sql...

Keep in mind such a flash/ming/ada approach is not that bad considering
there are flash players for pdas, cellulars and computers.

> top. Maybe even made two of them run concurrently. For example, web
> reports via AWS and a control GUI with native look.
I'm not so sure a native look is anyone intentions.  I think you really
mean "intended look and feel".
IMHO We are more concerned the functionality and the look remain the
same on all platforms.
Keep in mind what we all want is that the GUI remain the same look and
feel as we intended where we built it.
That's why I think flash is extremely versatile.  IMHO it seems to
deliver a gui faithful to the intentions of the designer 
on all platforms flash runs on.  That said when you do make the gui IMHO
you have to keep in mind the lowest common denominator. 
i.e. When you scale down a gui to the device with the least pixel real
estate, will the gui be acceptable after the scaling down?
In order to avoid this, it is a good idea to make the gui with the
smallest pixel real estate first and then scale up :)
At least this way the resulting gui is guaranteed to display correctly
on all devices the first shot because the aspect ratio in Flash is
preserved.

Of course you could always choose to build a java gui and communicate
with sockets via your web browser.
Whatever language you use won't change the number of tiers in the
design.  Other factors will change your design which have less to do
with gui and more to do with overall performance.

I hope this helps.

Cheers,
David Marceau