 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
| HomeDiscussion GroupsGeneralPHPASPPerlColdFusionFlashHTML, CSS, ScriptsBrowsers |
Webmaster Forum / HTML, CSS, Scripts / JavaScript / September 2007AJAJS - thin client web app using mainly XMLHTTPRequest and eval()
I was wandering what the Javascript/Ajax community think of a rather unusual method I am using to develop my new web app. At least I think it is unusual because I have not yet found much about this exact method on the internet. My web app uses no HTML templates and neither does it use any CSS files. It is totally JS/Ajax driven, and there are totally no page fetches/ reloads (single page interface). My initial page looks a bit like this (the only html code in my whole app!): <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> <title></title> <script type="text/javascript" src="./js/init.js"></script> </head> <body> </body> <html> The init.js is a small script that starts it all up. It does a XMLHTTPRequest to a server-side application that only outputs JS code. ALL returned content is passed into eval() (I actually do not need to call eval() directly because the Content-type is "text/javascript"). The first JS code that is returned builds up the whole page, loads some simple libraries, and registers some events to observe. From then on, ALL events (except for simple things like resizing) are sent to my server application which then outputs more JS code that get executed back on the client. For example, a user clicks on a button, the request is sent to the server which then returns some JS code to build a message dialog and register the corresponding message handlers, and so on. Therefore, for every event, the browser "asks" the server what to do, and the server tells the browser directly what to do with a snippet of Javascript. This has great advantages for me as I now have all my layout, model, business logic, etc. in one place. It is like "lazy loading", but an extreme form. One might think that it could run quite slow because it connects to the server for every user-action, but the returned pieces of code are small pieces of code, so the speed is actually quite impressive. This setup results in an extremely thin-client. I am very pleased with the first results, and it makes the whole development experience much like my original profession: building client/server desktop applications. This is probably a sort of controversial method because I noticed that there are mixed opinions about using the eval() function to execute code. Ofcourse, the returned code comes from my own server (same origin policy), so no major reasons for concern. Another point of criticism is possibly the fact that I do not use any (X)HTML templates or CSS files. This aspect is something I actually like very much, as I can now build and position all components with code, instead of looking all these things up in HTML and CSS files (great for website design, but not for desktop-like application development). So, my questions to you all are: - what do you think of this strategy? - If this strategy has already been discussed before, then what is it called? (I am calling it AJAJS for the time being (not AJAJ which is JSON oriented)). - Where can I find more information about this? - Are there already existing frameworks based on this? - Do you think that browsers will continue to support eval(), and not depreciate it in the future for security reasons? (Oops, sorry for the messy layout of my message. I now know that I should not wrap the texts myself when posting here.) On 26 Sep, 15:21, timsamshuij...@gmail.com wrote: > I was wandering what the Javascript/Ajax community think of a rather > unusual [quoted text clipped - 90 lines] > depreciate > it in the future for security reasons? This strategy looks very similar to XAJAX and also to the way that Google Mail works. Hi, On Sep 26, 7:21 am, timsamshuij...@gmail.com wrote: > I was wandering what the Javascript/Ajax community think of a rather > unusual [quoted text clipped - 19 lines] > </body> > <html> On request, I'm writing one of these sort of pages now (and it is a lot of fun!) It is for a back-end tool that requires login for IE6+/ FF2+/O9+/S2+ only with images, CSS, and JavaScript enabled. The page I am writing is _not_ something for general Web consumption where users may/may not have images/CSS/JavaScript and may have various levels of support for each of these. > The init.js is a small script that starts it all up. It does a > XMLHTTPRequest > to a server-side application that only outputs JS code. This means the JS code is probably not cachable. That's bad for performance. Better to have a build system that just puts the JavaScript init.js call directly in init.js itself. Then you can play caching games like name the file init-23456436.js where the number is a timestamp of the last build. You can have the server set far-future cache expiration. > ALL returned > content > is passed into eval() (I actually do not need to call eval() directly > because > the Content-type is "text/javascript"). Ajax doesn't autatically call eval() if the Content-type is "text/ javascript". Who calls eval() for you? Are you using a JavaScirpt Ajax library like Prototype? If so that is something to change pronto. > The first JS code that is > returned [quoted text clipped - 10 lines] > a message dialog and register the corresponding message handlers, and > so on. This sounds like Rails RJS. This style is fine for some applications but some folks here will say that this tight coupling by using language response is bad and a data response is better. If the server never reuses the templates that build up the JavaScript response, then it may be more flexible to send the data back to the client and the client decides what to do with that data. > Therefore, for every event, the browser "asks" the server what to do, > and the > server tells the browser directly what to do with a snippet of > Javascript. If these events need to interact with the database then you must contact the server. Only pester the server if there is the event handler needs some information you can't reasonably load into the browser. Looking up phone number, for example. You can't load the phone book into the browser in a reasonable time period. > This has great advantages for me as I now have all my layout, model, > business > logic, etc. in one place. "One place" isn't the important concept in the DRY principle. If you write your server-side in JavaScript then you can share code with the client, have a thicker client and still be DRY. This is what I'm shooting for eventually. > It is like "lazy loading", but an extreme > form. [quoted text clipped - 9 lines] > building > client/server desktop applications. With caching tricks you can make the second load of the page very fast. I wouldn't worry so much about how thick the client is because even a relatively thick client like GMail loads sufficiently fast for me given how long I keep the application open. > This is probably a sort of controversial method because I noticed that > there > are mixed opinions about using the eval() function to execute code. A lot of fuss is made here about that. The recent comp.lang.javascript archives are full of discussions. Search for "Randy Webb script insertion" or similar. > Ofcourse, > the returned code comes from my own server (same origin policy), so no > major > reasons for concern. Another point of criticism is possibly the fact > that I > do not use any (X)HTML templates or CSS files. Don't use XHTML for the Web if Internet Explorer is involved. http://www.thewebcreator.net/2007/04/16/why-you-should-be-using-html-401-instead -of-xhtml/ http://www.webdevout.net/articles/beware-of-xhtml > This aspect is > something I [quoted text clipped - 7 lines] > > - what do you think of this strategy? I think having empty body tags and building the whole thing with JavaScript is fine. I only transmit data to and from the server. Make sure you take advantage of browser caching to make second page loads fast. Use JavaScript on the server-side so you can share code and stay DRY. Using JavaScript server-side is something I'm just starting to explore now. > - If this strategy has already been discussed before, then what is it > called? > (I am calling it AJAJS for the time being (not AJAJ which is JSON > oriented)). > - Where can I find more information about this? > - Are there already existing frameworks based on this? In the Rails world it is RJS. Also search google for "Dan Webb ejs". > - Do you think that browsers will continue to support eval(), and not > depreciate > it in the future for security reasons? I'd guess eval() is not going away since it is part of the ECMAScript standard. There are other options that you'll find in the "Randy Webb" threads. Peter On Sep 26, 10:21 am, timsamshuij...@gmail.com wrote: > I was wandering what the Javascript/Ajax community think of a rather > unusual > method I am using to develop my new web app. At least I think it is > unusual It is unusual. > because I have not yet found much about this exact method on the > internet. > My web app uses no HTML templates and neither does it use any CSS > files. That's an odd approach for a Web-based application. > It is totally JS/Ajax driven, and there are totally no page fetches/ > reloads But lots of script fetches. > (single page interface). My initial page looks a bit like this (the > only html [quoted text clipped - 9 lines] > </body> > <html> I assume that last line is actually </html>. Anyway, a user without scripting enabled will see nothing. I understand that your app requires scripting, but you need an explicit disclaimer in the page. > The init.js is a small script that starts it all up. It does a > XMLHTTPRequest [quoted text clipped - 3 lines] > because > the Content-type is "text/javascript"). The first JS code that I don't know what you mean by that. The script doesn't evaluate itself. Is Prototype or the like mixed up in this thing? is > returned > builds up the whole page, loads some simple libraries, and registers > some > events to observe. From then on, ALL events (except for simple Why wouldn't this code be in init.js? things > like > resizing) are sent to my server application which then outputs more JS [quoted text clipped - 5 lines] > a message dialog and register the corresponding message handlers, and > so on. You've turned browsers into dumb terminals. > Therefore, for every event, the browser "asks" the server what to do, > and the > server tells the browser directly what to do with a snippet of > Javascript. You shouldn't query the server unless you need data from the server. The presentation logic should be downloaded once and run on the client. > This has great advantages for me as I now have all my layout, model, > business > logic, etc. in one place. It is like "lazy loading", but an Why would you want your business rules mixed up in your presentation layer. Whether you mean logically or physically in one place, this makes no sense to me. extreme > form. > One might think that it could run quite slow because it connects to > the server > for every user-action, but the returned pieces of code are small > pieces of > code, so the speed is actually quite impressive. This setup Not nearly as impressive as it would be with the presentation logic running on the client. results in > an > extremely thin-client. I am very pleased with the first An extremely thin client makes sense for an app that runs on a cell phone, but is wasteful on a PC. Why not leverage the power of PC browsers instead of turning them into dumb terminals? results, and > it makes > the whole development experience much like my original profession: > building > client/server desktop applications. Don't take this the wrong way, but what decade was this in? > This is probably a sort of controversial method because I noticed that > there > are mixed opinions about using the eval() function to execute code. Not really. It leads to all sorts of headaches and is practically never needed. Why invite trouble? > Ofcourse, > the returned code comes from my own server (same origin policy), so no [quoted text clipped - 8 lines] > (great > for website design, but not for desktop-like application development). Why not use CSS files? Why would you want to lump appearance in with business rules and presentation logic. If you need to change the appearance of your app, you modify your CSS file(s). If you need to change your business rules you modify your server-side scripts. If you need to modify your presentation logic, you modify your client- side scripts. This would seem a lot easier than having everything in one place. > So, my questions to you all are: > > - what do you think of this strategy? Not much. > - If this strategy has already been discussed before, then what is it > called? > (I am calling it AJAJS for the time being (not AJAJ which is JSON > oriented)). > - Where can I find more information about this? Google for "thin client", "dumb terminal", "mainframe computers", etc. > - Are there already existing frameworks based on this? Probably, but that doesn't make it a good idea. > - Do you think that browsers will continue to support eval(), and not > depreciate > it in the future for security reasons? As for depreciation, it's already been written off for general use, but it isn't likely to be deprecated as it is occasionally useful. Thank you all for your comments. They are most usefull. I will use this in evaluating the current architecture. Maybe I will eventually choose to make the client a bit "thicker", I am not sure yet. It depends on the limitations I will encounter during development. For the time being I like the idea of the thin client, and that the server "knows" what the client is doing. As for database connections, at the moment the database connections are handled by my server app, and the results are returned as a set of JS instructions that show the results in the browser. No problems there. And for those commenting on "Content-type text/javascript", yes I indeed use Prototype (which I did not show in the HTML code of my first post). It was quite a useless piece of information I gave there that is not related to this subject. (BTW. In the meantime I have switched back to a simple eval(). ) Cheers, Tim On Sep 27, 1:30 am, timsamshuij...@gmail.com wrote: > Thank you all for your comments. They are most usefull. I will use > this in evaluating the current architecture. Maybe I will eventually [quoted text clipped - 12 lines] > that is not related to this subject. (BTW. In the meantime I have > switched back to a simple eval(). ) It doesn't matter if you do the eval() or Prototype does the eval(). It is the same eval(). What matters is you get Prototype out of your program all together. Read the comp.lang.javascript archives for many reasons why Prototype is regarded as poor quality and will lead to headaches. Peter > ...What matters is you get Prototype out of your > program all together. Read the comp.lang.javascript archives for many > reasons why Prototype is regarded as poor quality and will lead to > headaches. I understand from many posts that Prototype.js is not the preferred library. I would however like to make use of some kind of (basic) library (for DOM/Ajax/Events) to save me a lot of boring work in making functions that work in most browsers. It is a shame that many people here say that they have not found a very good library for general use. Do I understand correctly that Yahoo!'s YUI is the better choice (if any)? Thanks in advance for any advice. Tim On Sep 28, 7:56 am, timsamshuij...@gmail.com wrote: > > ...What matters is you get Prototype out of your > > program all together. Read the comp.lang.javascript archives for many [quoted text clipped - 5 lines] > library (for DOM/Ajax/Events) to save me a lot of boring work in > making functions that work in most browsers. It is a shame that many I am currently working on just that. More like DOM || Events || Ajax, etc. as applications don't always need all three. > people here say that they have not found a very good library for > general use. Do I understand correctly that Yahoo!'s YUI is the better > choice (if any)? Thanks in advance for any advice. Better in what way? I haven't looked too deeply into it, but it seems to be better code than Prototype, jQuery and the like (which isn't saying much.) However, it looks like overkill for basic Web applications. I got busy today and wrote my own library for DOM || Events || Ajax. quirksmode.org was a very useful reference while making this. Writing the functionality for the events was the most work (passing on "object scope" by means of binding, etc.) and it eventually turned out nice and compact. This version makes it much easier to remove/detach the events than with Prototype. I am quite pleased with the result and it was a very educational experience. My app now runs without any other libraries and I aim to keep it that way (except for maybe a WYSIWYG editor). The next sub-project will be to make a GUI lib. If anyone is interested in the code for the event stuff, just let me know and I will post it here. Thanks again for the good advice. Tim > I got busy today and wrote my own library for DOM || Events || Ajax. Wheel model 42. PointedEars  Signature"Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.)" -- from <http://www.vortex-webdesign.com/help/hidesource.htm> On Sep 28, 4:27 pm, timsamshuij...@gmail.com wrote: > I got busy today and wrote my own library for DOM || Events || Ajax. Good idea. > quirksmode.org was a very useful reference while making this. Yes, that site is very helpful. Writing > the functionality for the events was the most work (passing on "object > scope" by means of binding, etc.) and it eventually turned out nice > and compact. This version makes it much easier to remove/detach the > events than with Prototype. I am quite pleased with the result and it The trouble with event processing in most of the libs out there is inefficiency. This is most easily observed when using features built atop them like drag and drop. > was a very educational experience. My app now runs without any other > libraries and I aim to keep it that way (except for maybe a WYSIWYG I've looked at lots of WYSIWYG editor scripts and couldn't recommend a single one. > editor). The next sub-project will be to make a GUI lib. The biggest pain in writing a framework for widgets is positioning. The second biggest is sizing. The quirksmode site has a lot of good information on these subjects, but it is just raw data. Drawing meaningful conclusions and implementing reliable feature tests is a time-consuming and often agonizing process. > The biggest pain in writing a framework for widgets is positioning. > The second biggest is sizing. I am not experiencing any difficulties here yet. This is probably because I am not writing any general widgets that can be used anywhere. My widgets are used in my app environment where all elements are positioned absolute. My sizing, resizing, and drag routines are working fine, no pain yet. Or maybe you are referring to some difficulties that I have not yet encountered. On Sep 29, 2:38 am, Peter Michaux <petermich...@gmail.com> wrote: > I started with the YUI libraries and tried to fix at least everything > that was wrong/less than optimal in my eyes. > > http://forkjavascript.org > > Peter I had a look at your code - great stuff! I had a look at your event routines to check whether my code is up to scratch (I am new to JS). I actually found your code "quite" similar to mine, which serves as a confirmation to me that I am on the right track. If I would have looked at your code previously then it would have saved me quite some work yesterday ;-) On the other had, in my opinion it is good to have written such stuff totally from scratch so that one fully understands the issues involved. For those interested, here is my (stripped) version of a simple event handler: (Comments, questions and suggestions are welcome) var TVSEvent = { Handlers: [], IndexOfHandler: function(aHandler) { var hidx = -1; for(var i = 0, length = this.Handlers.length; i < length; i++) { var hob = this.Handlers[i]; if((hob.Handler == aHandler) || (hob.DOMHandler == aHandler)) { hidx = i; break; } } return hidx; }, Add: function(aNode, aType, aHandler, aScope) { var domh = aHandler; if(arguments.length >= 4) { domh = function() { return aHandler.apply(aScope, arguments); } } this.Handlers[this.Handlers.length] = { Handler: aHandler, DOMHandler: domh } if(aNode.addEventListener) { aNode.addEventListener(aType, domh, false); } else if(aNode.attachEvent) { aNode.attachEvent('on' + aType, domh); } return domh; }, Remove: function(aNode, aType, aHandler) { var domh = aHandler; var eidx = this.IndexOfHandler(domh); if(eidx >= 0) { domh = this.Handlers[eidx].DOMHandler; this.Handlers.splice(eidx, 1); } if(aNode.removeEventListener) { aNode.removeEventListener(aType, domh, false); } else if(aNode.detachEvent) { aNode.detachEvent('on' + aType, domh); } } } timsamshuijzen@gmail.com said the following on 9/29/2007 5:43 AM: >> The biggest pain in writing a framework for widgets is positioning. >> The second biggest is sizing. > > I am not experiencing any difficulties here yet. Are you using wheel model 42 or wheel model 43? <URL:http://www.ajaxtoolbox.com> SignatureRandy Chance Favors The Prepared Mind comp.lang.javascript FAQ - http://jibbering.com/faq/index.html Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/ > Are you using wheel model 42 or wheel model 43? > > <URL:http://www.ajaxtoolbox.com> Wheel model 3.000 (My wheel is currently six-sided, but while the version is iterating toward Pi my wheel is getting rounder and rounder.) On Sep 29, 2:43 am, timsamshuij...@gmail.com wrote: > > The biggest pain in writing a framework for widgets is positioning. > > The second biggest is sizing. [quoted text clipped - 24 lines] > the issues > involved. Yes it is good to know all the issues involved. > For those interested, here is my (stripped) version of a simple event > handler: [quoted text clipped - 46 lines] > > } It looks like you don't need to "prevent default" for click and double click events in Safari. That restriction removes a mighty ugly workaround I've included in my code. Peter On Sep 29, 5:43 am, timsamshuij...@gmail.com wrote: > > The biggest pain in writing a framework for widgets is positioning. > > The second biggest is sizing. [quoted text clipped - 5 lines] > working fine, no pain yet. Or maybe you are referring to some > difficulties that I have not yet encountered. Try adding borders to the body or html elements. To compound the problem, add margins to the html element. Then try to compute the position of an absolute element in just the major browsers in standards mode. I imagine you will need the viewport rectangle at some point as well. Have fun with that. > On Sep 29, 2:38 am, Peter Michaux <petermich...@gmail.com> wrote: > [quoted text clipped - 63 lines] > } > } You should feature detect once and be done with it. And if you are going to write a wrapper for event handling, you should smooth out the basic differences between the two models. It doesn't make sense to normalize everything for every event (like most libs do), but at least pass along the event object and fix "this" handling for IE. On Sep 28, 4:56 am, timsamshuij...@gmail.com wrote: > > ...What matters is you get Prototype out of your > > program all together. Read the comp.lang.javascript archives for many [quoted text clipped - 8 lines] > general use. Do I understand correctly that Yahoo!'s YUI is the better > choice (if any)? Thanks in advance for any advice. I started with the YUI libraries and tried to fix at least everything that was wrong/less than optimal in my eyes. http://forkjavascript.org Peter Hi David, > You shouldn't query the server unless you need data from the server. > The presentation logic should be downloaded once and run on the [quoted text clipped - 15 lines] > > Don't take this the wrong way, but what decade was this in? I agree with all of the above but to be fair to the OP hasn't technology such as AJAX, in some ways, turned the clock back and created a hybrid by merging the web and client/server paradigms? There are people, certainly within this group, who'll contend that if it doesn't have a SUBMIT button then it's not a browser application. Others, myself included, can see browsers as the run-time environment for a genre of "new" lightweight client/server applications. Anyway FWIW here is how I'd do it (HTTP is great for serving up web-pages and images, but is it really the best tool in the box for a secure, high-performance, middleware communications back-bone? The browser *is* the GUI, but is a Web-Server really an Application Server?) http://manson.vistech.net/t3$examples/demo_client_web.html All of the HTML, Javascript, and Java Applet sources can be viewed at: - http://manson.vistech.net/t3$examples/ To see the example sucessfully you will need:- 1) Javascript enabled 2) Java Applets enabled 3) Can't be behind a Firewall that forbids all unknown outgoing connections (otherwise open-up 5255) 4) Must be running SUN's JRE 1.4.2_13 or later (1.6 is advised) 5) Must be running Internet Explorer (6 or later) or Firefox (Haven't tested other browsers) I'm told it works with Safari Version 2.0.4 (419.3) Java Plug-in 1.5.0 Using JRE version 1.5.0_07 Java HotSpot(TM) Client VM. All things being equal you should then be prompted (via Java modal dialogue box) for:- Username: TIER3_DEMO Password: QUEUE Here's some of the functionality-catwalk highlights from the example: - 1) Full, one-time, context-specific, VMS User Authentication. No Cookies, Session IDs, Password Caching or generic Work-Station or Browser credentials! When you load the demo_client_web.html page into your browser, a Java Applet is automatically activated that prompts the user for their VMS Username and Password via a modal dialogue box. If authorization fails, the "Access Denied" page will be displayed and VMS Intrusion Detection (in accordance with the policy set out by your System Manager) will be enforced, and Login-Failures is incremented in SYSUAF. Alternatively, if authorization is successful (and you left the "Display Logon Confirmation" box ticked) then a Welcome dialog box will be displayed detailing last login times and the number of unsuccessful login attempts (if any). Login-Failures is now set to zero and last non-interactive login time is set to the current time. If you refresh this page, or move to a different page, then the server connection is broken and you must be re-authorised before continuing to access the Demo Queue Manager application. 2) A Hot-Abort button! After you have pressed the "Get Job Info" button you'll notice that the "Abort Request" button becomes active and turns red. (Actually you probably won't notice 'cos this query completes too quickly :-) You can edit the DEMO_UARS.COB code and change the value of the DEBUG_DELAY field if you want to see your 3GL Interrupt routine in action.) In this case the cancel-flag I've set in the AST routine is picked up in the mainline code, resulting in the graceful termination of the loop that controls "next queue" (or "next row") retrieval. Also, if you look at the getResponse() function in query_lookup.html, you will see how the chan.setTimeout() method has been deployed to provide an erstwhile "blocking" socket Read with the ability to surrender the event-thread for things like processing the Abort button and ticking over the clock. (all of this, and much more, "infrastructure-code" is already there and doesn't have to be re-invented) 3) Predictive text on the Queue Name field so that all matching VMS queues are retrieved on-demand as the user types. As is now common-place with many websites, a drop down select list of matching options is automatically retrieved from the server and made available for the user to select from. 4) Result-set drill-down. Many database queries return a result-set of rows for the user to scan through and possibly drill-down into for more detail. I've provided a reasonably generic example of this, where all matching Job Entries have been populated into a dynamic HTML select list. Once again the user was able to see the select-list grow, the scroll-bar diminish, and "Jobs Found" field tick over in real-time, whilst continually being empowered (by the Abort button) to curtail the results at any time! If you click on an entry in the Select List then the <frame> changes and the entry_details.html page appears. See the parent.entry_details.getReady() call in queue_lookup.html to see how the handover to the new frame takes place. (Also see goBack() in entry_details.html to see how simply that operation is reversed.) The user is now free to move forward, back, first, last, refresh, and delete queue entries, or return to the previous frame. (Thanks to the deployment of the VMS Persona functionality, the user is only permitted to see those queue entries that the Username they signed in under is permitted to see. They can also *only* delete those entries that this username is allowed to delete.) 5) Floating <div>s. You'll see that any queue names are highlighted in bold and italics; if you mouseover any of these fields when they are not blank then the current status information for that queue will be retrieved from the server and displayed in a quasi-popup DIV. 6) Local Result-Set Sort. If you click on the "header" or "first" row in the Select List of queues, you will get a popup prompting you for a sort key. If you select one, the contents of the Select List are sorted in the chosen order. (Try enter "*" for the Queue Name and then clicking "Get Job Info" to get some data worth sorting) Regards Richard Maher PS. The server code can be in any 3GL but, for this example, I chose COBOL; "What century are we in" :-) > On Sep 26, 10:21 am, timsamshuij...@gmail.com wrote: > > I was wandering what the Javascript/Ajax community think of a rather [quoted text clipped - 163 lines] > As for depreciation, it's already been written off for general use, > but it isn't likely to be deprecated as it is occasionally useful. On Sep 29, 7:42 pm, "Richard Maher" <maher...@hotspamnotmail.com> wrote: > Hi David, [snip] > I agree with all of the above but to be fair to the OP hasn't technology > such as AJAX, in some ways, turned the clock back and created a hybrid by > merging the web and client/server paradigms? There are people, certainly > within this group, who'll contend that if it doesn't have a SUBMIT button > then it's not a browser application. Others, myself I'm not sure I follow, but a form without a submit button is a bad idea. included, can see > browsers as the run-time environment for a genre of "new" lightweight > client/server applications. Yes, but light is relative. The OP proposal is too light, wasting the capabilities of the browser and PC. > Anyway FWIW here is how I'd do it (HTTP is great for serving up web-pages > and images, but is it really the best tool in the box for a secure, > high-performance, middleware communications back-bone? The browser *is* the > GUI, but is a Web-Server really an Application Server?) The Web server is just a conveyance between the presentation and middleware layers. > http://manson.vistech.net/t3$examples/demo_client_web.html That didn't work too hot for me in IE7. I got a message saying the Java runtime environment couldn't be loaded (and little else.) I don't think your app caused the error, but it didn't recover from it very gracefully. In other words, it degraded to a virtually blank and unusable page. > All of the HTML, Javascript, and Java Applet sources can be viewed at: - > [quoted text clipped - 3 lines] > > 1) Javascript enabled Check. > 2) Java Applets enabled Check. > 3) Can't be behind a Firewall that forbids all unknown outgoing connections Check. > (otherwise open-up 5255) > 4) Must be running SUN's JRE 1.4.2_13 or later (1.6 is advised) No idea. > 5) Must be running Internet Explorer (6 or later) or Firefox (Haven't tested > other browsers) I'm told it works with Safari Version 2.0.4 (419.3) Java [quoted text clipped - 5 lines] > Username: TIER3_DEMO > Password: QUEUE Never got this far. > Here's some of the functionality-catwalk highlights from the example: - > [quoted text clipped - 14 lines] > connection is broken and you must be re-authorised before continuing to > access the Demo Queue Manager application. Right. I take it it's one application per page. [snip] Clearly Ajax isn't appropriate this application, so Java is required. But what sort of practical Web application would you build with this? I guess it would make sense if you need remote access to a mainframe. > Regards Richard Maher > > PS. The server code can be in any 3GL but, for this example, I chose COBOL; Since I didn't see the example, I really can't comment on it, other than to say that COBOL is an odd choice. Thanks for sharing. > On Sep 29, 7:42 pm, "Richard Maher" <maher...@hotspamnotmail.com> > > I agree with all of the above but to be fair to the OP hasn't technology > > such as AJAX, in some ways, turned the clock back and created a hybrid by [quoted text clipped - 4 lines] > I'm not sure I follow, but a form without a submit button is a bad > idea. Are you sure it is *always* a bad idea? > included, can see > [quoted text clipped - 3 lines] > Yes, but light is relative. The OP proposal is too light, wasting the > capabilities of the browser and PC. Ironically, "too" light is also relative. I'm not sure how you can make such categorical statements with such confidence. Different situations require different approaches and to throw away options a priori seems like a less-than-optimal choice. Peter > > On Sep 29, 7:42 pm, "Richard Maher" <maher...@hotspamnotmail.com> > > > I agree with all of the above but to be fair to the OP hasn't technology [quoted text clipped - 7 lines] > > Are you sure it is *always* a bad idea? Unless it isn't really a form (eg input elements that never submit anything), in which case you can remove the form element, or if the form is hidden for use with Ajax, IFrames, etc. I was talking about forms that are used as forms by users. No submit button means that some browsers will never submit the data (no matter how many times you hit the enter key.) > > included, can see > [quoted text clipped - 5 lines] > > Ironically, "too" light is also relative. That's the point. The method described is relatively lighter than Ajax applications. > I'm not sure how you can make such categorical statements with such > confidence. Different situations require different approaches and to > throw away options a priori seems like a less-than-optimal choice. What occasion requires turning a browser into a dumb terminal? Makes no sense to me. Most of the world threw away dumb terminals decades ago. Hi David, > I'm not sure I follow, but a form without a submit button is a bad > idea. Not if you never submit anything. > Yes, but light is relative. The OP proposal is too light, wasting the > capabilities of the browser and PC. I would agree with you here, but others may be happy with it. > The Web server is just a conveyance between the presentation and > middleware layers. Yes it is convenient and ubiquitous - and (I contend) demonstrably a square peg in the middleware hole. > > (otherwise open-up 5255) > > 4) Must be running SUN's JRE 1.4.2_13 or later (1.6 is advised) > > No idea. As Microsoft does not support a JVM for recent versions of Windows you need to install a copy of SUN's JRE which can be downloaded from http://java.sun.com/javase/downloads/index.jsp To see what (if any) version you've currently got installed you should look for "Java Plug-In" in your Control Panel. > Right. I take it it's one application per page. Currently I use Framesets and load new page(s) into an off-screen and then "grow" it when it's ready. Having said that, it would be extremely easy to have the Socket survive page transitions but I haven't had the time to test whether that Socket could then be the subject of a Socket-Hijacking attack as much as Session-Hijacking is a gaping hole in other architectures. Therefore I currently tear it down via the Applet's (CornuCopiae.java) destroy() method which calls the Socket's (Tier3Socket.java) close() method. > But what sort of practical Web application would you build with this? Any and all! OK, it may not be for your normal shopping-trolley web-app or usual Web-Browser look and feel, but just think of rolling out new versions of an organizations internal application(s) without having to upgrade the software on the client PCs. Pretty much all "known user" applications such as branch-office to head-office, bank customer access, or travel agent to wholesaler etc etc > I guess it would make sense if you need remote access to a mainframe. Exactly! High-performance, secure, context-rich client access to your mainframe resources. > than to say that COBOL is an odd choice. As I said, it could be any 3GL that can produce a Shareable Image/DLL. > Thanks for sharing. Thanks for giving it a go! I hope you get the time to download the JRE and give it another go. IMHO, It's definitely worth the few minutes effort and having a recent JVM on your box is always handy! Cheers Richard Maher > On Sep 29, 7:42 pm, "Richard Maher" <maher...@hotspamnotmail.com> > wrote: [quoted text clipped - 104 lines] > > Thanks for sharing. |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.