From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e429176c9adb07b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-16 14:02:42 PST Message-ID: <3E500818.6C22A864@sympatico.ca> From: David Marceau X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17-10mdksmp i686) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: [OT] Best way to isolate a GUI? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 16 Feb 2003 16:52:24 -0500 NNTP-Posting-Host: 65.92.163.135 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1045432713 65.92.163.135 (Sun, 16 Feb 2003 16:58:33 EST) NNTP-Posting-Date: Sun, 16 Feb 2003 16:58:33 EST Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:34161 Date: 2003-02-16T16:52:24-05:00 List-Id: 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