Ajax applications can contain much more client-side code than a standard web application, and hence benefit much more from the order that patterns and refactoring bring. Chapter 4 of Manning's Ajax in Action is the first of three chapters that apply refactoring and patterns to the client-side codebase. You won't see much of the asynchronous requests that give Ajax its name in this chapter, but the style of programming that we're discussing here is a direct consequence of being able to make asynchronous requests.
This chapter is about structuring Ajax applications. It provides examples of how the well-established Model-View-Controller pattern can be used to provide that structure. This first installment of Chapter 4 covers the display aspects of the application, and shows how normal JavaScript code can be refactored into a robust view component.
Check out Chapter 4, Part 1
-
Excerpt: Ajax in Action, The Page as an Application (32 messages)
- Posted by: Joseph Ottinger
- Posted on: August 17 2005 07:35 EDT
Threaded Messages (32)
- Excerpt: Ajax in Action, The Page as an Application by Abhay Bakshi on August 26 2005 15:22 EDT
- Ajax by shawn spencer on August 27 2005 19:09 EDT
- Deja Vu by David Haynes on August 28 2005 10:58 EDT
-
Swing too Hard? by Jon Kofal on August 28 2005 03:58 EDT
- Swing too Hard? by mark lybarger on August 29 2005 07:38 EDT
- Swing too Hard? YES by urddd urddd on August 29 2005 09:50 EDT
- Swing too Hard? by Jing Xue on August 29 2005 11:40 EDT
-
Swing too Hard? by Jon Kofal on August 28 2005 03:58 EDT
- Add Smart, Rich to the mix by Matthew Perrins on August 28 2005 18:19 EDT
-
Is it worth it? by Jay Patel on August 30 2005 12:16 EDT
-
Is it worth it? by dave crane on August 31 2005 07:34 EDT
-
Is it worth it? by Henrique Steckelberg on August 31 2005 08:05 EDT
-
Is it worth it? by dave crane on August 31 2005 08:54 EDT
-
Is it worth it? by Henrique Steckelberg on August 31 2005 09:28 EDT
-
Is it worth it? by Henrique Steckelberg on August 31 2005 10:32 EDT
-
broken link by dave crane on September 01 2005 05:27 EDT
- broken link by Henrique Steckelberg on September 01 2005 07:48 EDT
-
broken link by dave crane on September 01 2005 05:27 EDT
-
Is it worth it? by Henrique Steckelberg on August 31 2005 10:32 EDT
-
Is it worth it? by Henrique Steckelberg on August 31 2005 09:28 EDT
-
Is it worth it? by dave crane on August 31 2005 08:54 EDT
-
Is it worth it? by Henrique Steckelberg on August 31 2005 08:05 EDT
-
Is it worth it? by dave crane on August 31 2005 07:34 EDT
-
Is it worth it? by Jay Patel on August 30 2005 12:16 EDT
- Deja Vu by David Haynes on August 28 2005 10:58 EDT
- OT:Swing by Werner Punz on August 29 2005 05:09 EDT
- AJAX made easy with Echo2 framework by Rauf Issa on August 29 2005 23:44 EDT
- AJAX made easy with Echo2 framework by Timur Evdokimov on August 30 2005 01:55 EDT
- A wind of change by Reg Whitton on August 30 2005 03:48 EDT
- What a crappy chapter to pick as the representative! by Benjamin Leo on August 30 2005 12:23 EDT
- What a crappy chapter to pick as the representative! by Henrique Steckelberg on August 30 2005 12:42 EDT
-
What a crappy chapter to pick as the representative! by Benjamin Leo on August 30 2005 01:01 EDT
- What a crappy chapter to pick as the representative! by Henrique Steckelberg on August 30 2005 01:36 EDT
-
Patterns, Refactoring and Ajax by dave crane on August 31 2005 07:24 EDT
-
Patterns, Refactoring and Ajax by Greg Kerdemelidis on September 01 2005 08:19 EDT
- AJAX app to replace native GUI app for the Enterprise by Ket Yung Chee on September 24 2005 11:49 EDT
-
Patterns, Refactoring and Ajax by Greg Kerdemelidis on September 01 2005 08:19 EDT
-
What a crappy chapter to pick as the representative! by Benjamin Leo on August 30 2005 01:01 EDT
- What a crappy chapter to pick as the representative! by Henrique Steckelberg on August 30 2005 12:42 EDT
-
Excerpt: Ajax in Action, The Page as an Application[ Go to top ]
- Posted by: Abhay Bakshi
- Posted on: August 26 2005 15:22 EDT
- in response to Joseph Ottinger
Thank you, Joe and Manning.
It will be interesting to review this book before it goes out to press. AJAX is a new technology (or being newly used with this new name, whatever!) - no book can be complete without reaching out to >many< real people working on real projects.
Public reviews were started on TSS by Ed Roman. His "Mastering EJB" got more famous that way.
Joe, can you request Manning for a public review of this book? -
Ajax[ Go to top ]
- Posted by: shawn spencer
- Posted on: August 27 2005 19:09 EDT
- in response to Joseph Ottinger
It was thin (dumb) clients in 70's(mainframe), then the thick clients in 80's to late 90's (c++, VB, powerbuilder) and then the thin browsers in 90's till date and now back to thick browser clients with ajax :) -
Deja Vu[ Go to top ]
- Posted by: David Haynes
- Posted on: August 28 2005 10:58 EDT
- in response to shawn spencer
Sometimes I feel we are doomed to re-impliment 3270/5250 protocol forever... -
Swing too Hard?[ Go to top ]
- Posted by: Jon Kofal
- Posted on: August 28 2005 15:58 EDT
- in response to David Haynes
Applets, Swing, Java Web Start - I guess it's just too hard for some people to master.
I mean look at IBM, they had to develop SWT because Swing was too hard to learn, and of course we all know that the performance of Swing is disasterous ;-) -
Swing too Hard?[ Go to top ]
- Posted by: mark lybarger
- Posted on: August 29 2005 07:38 EDT
- in response to Jon Kofal
swing isn't too hard, and gives a much better look-n-feel than the web controls provide. the major problem is if the user can run swing applications from their browser.
from what i hear, there are version of windows released that may not even have java capabilities from ie. and i also hear that many (all?) windows version have only legacy java capabilities (awt).
out of the box swing is not available on the most common operating system deployed to the desktop. thus, if your target audience is at all outside of your technical support's control, you can fairly safely assume the user has modern IE 5.x+, and has javascript/cookies turned on.
would/has sun given microsoft the rights to deploy sun's jvm on their desktop? what java is expected to ship with vista? it would be interesting to see the comparision of number of users who have flash installed compared to those who can run swing applets in the browser. -
Modern?[ Go to top ]
- Posted by: Patrick Linskey
- Posted on: August 29 2005 17:09 EDT
- in response to mark lybarger
you can fairly safely assume the user has modern IE 5.x+
Ahem. I wouldn't say that IE 5 is all that modern -- the state of the art has moved along quite a bit since 1998, after all. I mean, it doesn't even do tabbed browsing, a feature I've been using in one form or fashion for six years or so.
Hopefully, MS will do some innovating (or at least catching-up) with IE7. We shall see.
-Patrick
--
Patrick Linskey
http://solarmetric.com -
Modern?[ Go to top ]
- Posted by: Mark N
- Posted on: August 30 2005 07:39 EDT
- in response to Patrick Linskey
opefully, MS will do some innovating (or at least catching-up) with IE7. We shall see.
Like maybe remove it? :)
Honestly (as I have speculated in the past), I can see them "dumbing down" the traditional browser aspect of IE (ie. removing JavaScript support) due to all the viruses, etc making it just an html viewer - And replacing it with their own, better, safer technology (some sort of XHTML) that integrates better with Windows. This all will provide a better user and developer experience. ;) -
Modern?[ Go to top ]
- Posted by: Mark N
- Posted on: August 31 2005 09:00 EDT
- in response to Mark N
Just saw this - http://www.crn.com/sections/breakingnews/dailyarchives.jhtml?articleId=170101800opefully, MS will do some innovating (or at least catching-up) with IE7. We shall see.
Like maybe remove it? :)Honestly (as I have speculated in the past), I can see them "dumbing down" the traditional browser aspect of IE (ie. removing JavaScript support) due to all the viruses, etc making it just an html viewer - And replacing it with their own, better, safer technology (some sort of XHTML) that integrates better with Windows. This all will provide a better user and developer experience. ;) -
Swing too Hard? YES[ Go to top ]
- Posted by: urddd urddd
- Posted on: August 29 2005 09:50 EDT
- in response to Jon Kofal
Yes it is! Swing is too hard, too confusing.
But people that master it don't see any problem with it (thus it will stay like it is forever).
Great power, good performance they say.
That doesn't help people like me who think swing is too hard but have no problem understanding the simpler model which is css+dom+javascript.
Relativly few people write swing code. It doesn't matter how good Swing is if it is too hard.
css+dom+javascript is not the panacea. The browsers are not the panacea because of varying support of different things on different browser (not WORA).
I'm just waiting for the next thing that will take the best of all. -
Swing too Hard?[ Go to top ]
- Posted by: Jing Xue
- Posted on: August 29 2005 11:40 EDT
- in response to Jon Kofal
Applets, Swing, Java Web Start - I guess it's just too hard for some people to master.I mean look at IBM, they had to develop SWT because Swing was too hard to learn, and of course we all know that the performance of Swing is disasterous ;-)
The problem with thick Java clients, even deployed through Web Start, is that a JVM must be (usually manually) installed to each and every client machine before any of the Web Start magic can happen. This can be a big, big, pain in an enterprise. Throwing in different Web Started applications requiring different JVM versions, you have some ready-to-serve nightmare. To avoid the nightmare, enterprise architects have been taking the obvious alternate - keep the client thin, i.e., in a browser.
Well now we have AJAX - or more accurately, we have most major browsers allowing AJAX in a compatible way. We don't necessarily have to stick to the thin client approach any more. After all, the usability with thin clients simply sucks.
P.S., I don't think IBM invented SWT because Swing was hard to learn, but rather because of Swing's disastrous performance _back then_. -
too Hard?[ Go to top ]
- Posted by: Jon Kofal
- Posted on: August 30 2005 03:40 EDT
- in response to Jing Xue
The problem with thick Java clients, even deployed through Web Start, is that a JVM must be (usually manually) installed to each and every client machine before any of the Web Start magic can happen. This can be a big, big, pain in an enterprise. Throwing in different Web Started applications requiring different JVM versions, you have some ready-to-serve nightmare.
I guess you could substitute "Browser" for "JVM", and make the same arguments. FYI, you can deliver a JRE with JWS, and in an Enterprise, and install a compliant JRE with an Applet. There's also this concept of backwards-compatibility that for the most part exists in Swing.
Like I sarcastically pointed out in my original post, it's "too hard" - for people to switch paradigms.I don't think IBM invented SWT because Swing was hard to learn, but rather because of Swing's disastrous performance _back then_.
One could speculate about a NIH mindset at IBM, but as I recall IBM had a jdk1.1.8 compatible GUI development library that <conjecture>probably served as the basis for SWT</conjecture>.
AJAX is pushing HTML to the limits, and not starting to scratch the surface of what a Swing client can achieve. -
too Hard?[ Go to top ]
- Posted by: Jing Xue
- Posted on: August 30 2005 18:42 EDT
- in response to Jon Kofal
I guess you could substitute "Browser" for "JVM", and make the same arguments.
Of course not. How about this - I give you one buck for each computer still in use that does not have any browser installed, and you give me one buck for each one that doesn't have any JVM installed?FYI, you can deliver a JRE with JWS, and in an Enterprise, and install a compliant JRE with an Applet.
If you are referring to the download link generation, it's not exactly the same as "deliver a JRE with JWS". The auto-install part is close, but officially it only works in Windows. You can probably work around to do it in an applet, but then the user would still have to accept the scary perspective of letting a web page initiating a local software installation.Like I sarcastically pointed out in my original post, it's "too hard" - for people to switch paradigms.
...
AJAX is pushing HTML to the limits, and not starting to scratch the surface of what a Swing client can achieve.
Don't get me wrong. I just got off from a Swing project, and am working on one that still involves Swing. So this isn't a religious war. Nobody is saying AJAX can do what Swing does. It's all about trade-offs and the right tool for the right user. -
Add Smart, Rich to the mix[ Go to top ]
- Posted by: Matthew Perrins
- Posted on: August 28 2005 18:19 EDT
- in response to shawn spencer
Then add a few Smart Clients and maybe a few Rich ones,in fact I want to be a Smart Rich Client :-)
Seriously, is the effort to support and maintain this level of code in the client going to be worth the effort to develop. I accept that Google Maps etc is doing a great job at extending the browser. DHTML and CSS was always designed to do this stuff even back in the late 90's. Apps with a lot of usage can justify the effort to make them perform. Not so sure the apps for the smaller user base will and can afford the developer skills needed to build them.We need to be working towards simplication will AJAX do this ?
Matt Perrins
IBM -
Is it worth it?[ Go to top ]
- Posted by: Jay Patel
- Posted on: August 30 2005 12:16 EDT
- in response to Matthew Perrins
Seriously, is the effort to support and maintain this level of code in the client going to be worth the effort to develop. I accept that Google Maps etc is doing a great job at extending the browser. DHTML and CSS was always designed to do this stuff even back in the late 90's. ... Not so sure the apps for the smaller user base will and can afford the developer skills needed to build them.We need to be working towards simplication will AJAX do this ?
This is where third-party/opensource tools can fill the gap and provide 'easy to use' ways to implement ajax so even 'smaller user base apps' can take advantage of it. -
Is it worth it?[ Go to top ]
- Posted by: dave crane
- Posted on: August 31 2005 07:34 EDT
- in response to Jay Patel
Seriously, is the effort to support and maintain this level of code in the client going to be worth the effort to develop. I accept that Google Maps etc is doing a great job at extending the browser. DHTML and CSS was always designed to do this stuff even back in the late 90's. ... Not so sure the apps for the smaller user base will and can afford the developer skills needed to build them.We need to be working towards simplication will AJAX do this ?
This is where third-party/opensource tools can fill the gap and provide 'easy to use' ways to implement ajax so even 'smaller user base apps' can take advantage of it.
Exactly, Jay,
Ajax toolkits are emerging, that will simplify the development of Ajax. There seem to be two main types at present - those that generate Ajax front-ends automatically from server-side models (e.g. Echo2, JSF), and client-side frameworks providing a higher level of abstraction for hand-coded javascript (e.g. Prototype, Scriptaculous, Rico, qooxdoo).
We cover a few of these in the book, but also spend a lot of time on the underlying technologies, because we're still in the early adopter stage where most Ajax projects will still need some hand-coding to complement the gaps in the current round of frameworks.
Regards,
Dave Crane -
Is it worth it?[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: August 31 2005 08:05 EDT
- in response to dave crane
There seem to be two main types at present - those that generate Ajax front-ends automatically from server-side models (e.g. Echo2, JSF), and client-side frameworks providing a higher level of abstraction for hand-coded javascript (e.g. Prototype, Scriptaculous, Rico, qooxdoo).
AFAIK, some projects are trying to bridge both types, for example I know some wicket framework (which is component oriented a la Echo2 & JSF) developers are playing with Scriptaculous & DOJO right now. My hope is that there is going to be just a minimum or even none handwritten Javascript code in such situation (component oriented server-side framework + high-level abstraction AJAX framework at the client-side), plus all the known benefits we get from each approach.
Regards,
Henrique Steckelberg -
Is it worth it?[ Go to top ]
- Posted by: dave crane
- Posted on: August 31 2005 08:54 EDT
- in response to Henrique Steckelberg
AFAIK, some projects are trying to bridge both types, for example I know some wicket framework (which is component oriented a la Echo2 & JSF) developers are playing with Scriptaculous & DOJO right now.
Thanksd for the link. I knew about Wicket, but not the ajax integration. Interesting stuff, I'll keep an eye out.My hope is that there is going to be just a minimum or even none handwritten Javascript code in such situation (component oriented server-side framework + high-level abstraction AJAX framework at the client-side), plus all the known benefits we get from each approach.
I don't agree with you here. Server-side solutions are essentially code generation, and therefore add complexity and limit the type opf code that can be created. (Not that I'm against code generation per se, I think it's a fine thing if its done properly, in the right context.) In many cases, auto-generating a smart form is good enough, but sometimes one needs a bespoke component (e.g. Google Maps). Moving solely towards server-generated JS would stifle inovation IMO.
I suppose that's a challenge for server-based frameworks - how easily can one create a new component type?
Regards,
Dave Crane -
Is it worth it?[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: August 31 2005 09:28 EDT
- in response to dave crane
From what I know, once one creates a new component with all its server-side code + client-side code + template, it is just a matter of developers dropping it in the UI, set some parameters and code its server-side behaviour, the rest should be automated, or so I wish ;).
Further more, in my (limited) understanding this is the only way for this mix to work, since component-oriented web frameworks must keep UI state control all the time, and having handwritten client-side JS code messing up with UI state without server-side knowledge would mean things breaking up. One option would be for component developer to create some specific hooks where client-side code should interact with the component, anything else should remain under server-side framework control. But all this can be better addressed by actual AJAX component developers, which I am not. ;)
Regards,
Henrique Steckelberg -
Is it worth it?[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: August 31 2005 10:32 EDT
- in response to Henrique Steckelberg
Here's a blog entry regarding Wicket + Scriptaculous autocomplete text component at work:
http://jroller.com/trackback/wireframe/Weblog/autocomplete_more_than_just_text. If you look at the example code, there's nothing besides the inclusion of the ajax component, setting its parameters and coding its server-side behaviour for it to work. No handwritten client-side JS at all. I expect most ajax components to behave like this when being used. Of course some clint-side JS code may be needed when _creating_ new AJAX components, but already existing component usage shouldn't depend on component user coding JS, or at least that should be minimal.
I am aware that right now all this is highly experimental in Wicket, but in case this approach proves feasible, IMO this would mean we'll get the best of both worlds.
Regards,
Henrique Steckelberg -
broken link[ Go to top ]
- Posted by: dave crane
- Posted on: September 01 2005 05:27 EDT
- in response to Henrique Steckelberg
Henrique,
The link sounds interesting, but it sems to be broken. Could you check it out pleae?
Many thanks,
Dave Crane -
broken link[ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: September 01 2005 07:48 EDT
- in response to dave crane
Oops, sorry, there it goes:
http://jroller.com/page/wireframe/?anchor=autocomplete_more_than_just_text
Regards,
Henrique Steckelberg -
OT:Swing[ Go to top ]
- Posted by: Werner Punz
- Posted on: August 29 2005 05:09 EDT
- in response to Joseph Ottinger
Ahem... performance of Swing was disastrous... ;-)
Swt on many platforms nowadays is slower than Swing, for instance Linux is one example, the Mac another one... -
AJAX made easy with Echo2 framework[ Go to top ]
- Posted by: Rauf Issa
- Posted on: August 29 2005 23:44 EDT
- in response to Joseph Ottinger
If you want to use a web application framework that that is thin client (no browser plugin required) and supports AJAX and gets you as close as you can get to a swing/swt API then you have got to check out echo2.
http://nextapp.com/products/echo2
It is opensource and very reliable. -
AJAX made easy with Echo2 framework[ Go to top ]
- Posted by: Timur Evdokimov
- Posted on: August 30 2005 01:55 EDT
- in response to Rauf Issa
Echo2 looks great indeed but looking at it in the light of application's target audiences, it seems to sit in a very narrow niche.
When I need just a few 'convenience' tricks like look-ahead of the names and on-the-fly form validations (looks cool indeed) for otherwise 'normal' browser applications, I'd rather use one of those thin AJAX libraries (script.aculo.us, DWR...)
But when the application really starts looking like complicated, I'd seriously consider building it as an applet or WebStart app (unless you are Google building GMail, of course) In either case, learning from experience I'd like to keep tight control on the communication between the presentation layer and business logics, to save myself trouble later in the project. -
A wind of change[ Go to top ]
- Posted by: Reg Whitton
- Posted on: August 30 2005 03:48 EDT
- in response to Joseph Ottinger
I detect a change in perception. For years I have been using some pretty fancy JavaScript. But the powers that be have always been told me to avoid using JavaScript unless absolutely necessary (it's a question of bad practice you know). However, it has nearly always been absolutely necessary given what these people ask me to build. Now I see that using fancy JavaScript has a name, I feel the time is coming where I will be asked to whole heartedly embrace AJAX.
I think I will be ready :-) -
What a crappy chapter to pick as the representative![ Go to top ]
- Posted by: Benjamin Leo
- Posted on: August 30 2005 12:23 EDT
- in response to Joseph Ottinger
First of all, how come not a single comment on this thread addresses the subject at hand: Manning's "Ajax in Action."
Why do all of your comments immediately digress into a theist discussion having nothing to do with the post you're commenting on. What is this, Slashdot?
Now, moving along, did anyone else notice that this is an utterly crappy chapter which has next-to-nothing to do with so-called 'AJAX' technology. This chapter could *easily* be part of a book called Jumpin' Javascript, Delightful DOM, or Cunning css. It has nothing to do with the AJAXy part, i.e. the interaction of these client-side technologies with the cool innovative bits that sneak out to the server without refreshing the page.
That makes it a crappy chapter to pick as a sample.
Furthermore, did anyone stop to question this opening sentence:
"Ajax applications can contain much more client-side code than a standard web application, and hence benefit much more from the order that patterns and refactoring bring."
WTF?? How bafflingly false! What the heck does this even mean? Didja stop to think about it, or just swallow it, head-noddingly, as dogma.
Boo if ya want, ya know I'm right.
Spreading love and joy,
Benjamin Leo
http://www.anti313.com -
What a crappy chapter to pick as the representative![ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: August 30 2005 12:42 EDT
- in response to Benjamin Leo
What the heck does this even mean?
As I understand it, it means AJAX apps are supposed to have lotsa Javascript code and libraries at the client-side in order to make all that "magic" work, much more than the usual web apps we see today, some of which go as far as proposing their apps should have no javascript at all. Besides, not long ago most people regarded Javascript as a Bad Thing (TM), so this change in mind could really mean new ideas and concepts being adopted at the client-side, or at least I hope so if indeed AJAX is here to stay (Unit tests for AJAX, refactoring for AJAX, etc.), unlike XUL which didn't quite catch on.
Regards,
Henrique Steckelberg -
What a crappy chapter to pick as the representative![ Go to top ]
- Posted by: Benjamin Leo
- Posted on: August 30 2005 13:01 EDT
- in response to Henrique Steckelberg
You would make a great manager at my current company.
I understand why AJAX applications have more client-side code than a standard web application. (Wait! Don't stop reading the message and reply just yet!)
What I don't understand is why that should mean that they benefit much more from the order that patterns and refactoring bring.
Spreading love and joy,
Benjamin Leo
http://www.anti313.com -
What a crappy chapter to pick as the representative![ Go to top ]
- Posted by: Henrique Steckelberg
- Posted on: August 30 2005 13:36 EDT
- in response to Benjamin Leo
You would make a great manager at my current company.
Thanks! Though I am sure my company's managers wouldn't ever talk like that, anyway... ;)I understand why AJAX applications have more client-side code than a standard web application. (Wait! Don't stop reading the message and reply just yet!)What I don't understand is why that should mean that they benefit much more from the order that patterns and refactoring bring.
Well, I wouldn't think of applying refactoring/patterns to a 6 LOC system... ;)
Regards,
Henrique Steckelberg -
Patterns, Refactoring and Ajax[ Go to top ]
- Posted by: dave crane
- Posted on: August 31 2005 07:24 EDT
- in response to Benjamin Leo
What I don't understand is why that should mean that they benefit much more from the order that patterns and refactoring bring.
Hi Benjamin,
What I meant by that was that the client-side code is bigger and more complicated in an Ajax app than in a traditional web app, where all the clever stuff takes place on the server.
Design patterns and refactoring are both tools for increasing the orderliness of a codebase. I've found them to be very useful when working with Ajax code, just as I do with my server code. Well-factored code is easier to look after in the long term, and any serious application development contains a good deal of looking after existing code, as well as developing new stuff. If you've worked on large-scale software projects in any language, you'll probably recognize this.
This is based on my own experience, looking after large banking applications containing around one hundred hand-written javascript files, on top of script that we generate dynamically from the J2EE back-end. That's bigger than your average Ajax project, I'll grant, but smaller projects can get real benefits from these too.
We lay down all the groundwork for refactoring and design tools in chapter 3 of the book, so I didn't give it much of a drumroll in chapter 4.
Hope that's clearer for you now.
Dave Crane -
Patterns, Refactoring and Ajax[ Go to top ]
- Posted by: Greg Kerdemelidis
- Posted on: September 01 2005 20:19 EDT
- in response to dave crane
Thanks Dave. Anyone who has put an app that is heavy on the client-side into production knows that it can (and probably will) get very hairy in there very fast.
There is a tendency for developers to just "include that .js", and when they need more functions, tack them on the end as globals. This way leads to madness.
We've adopted the practice of making all js in client-side apps objects, stored in a class-per-file adhering to the java conventions. Throw JSUnit in there and you have something that is at the very least more maintainable and robust.
I think the main problem is that people have only started to write "good" code in javascript recently - its heritage over the past few years has just been simple validation and the like.
There's no reason for your Good Developer hat to fall off just because you're writing js.
Regards,
Greg Kerdemelidis -
AJAX app to replace native GUI app for the Enterprise[ Go to top ]
- Posted by: Ket Yung Chee
- Posted on: September 24 2005 11:49 EDT
- in response to Greg Kerdemelidis
This is a sample AJAX application, which is done in a JSP/servlet/JavaBean framework. The database layer is handled by normal JavaBean, that handles the insert,update, find, delete and a servlet request handler, which dispatches actions to this JavaBean for different user's action. The web form is JSP and some rich UI taglib.
Try it out here http://rhae.dunco.com.my/examples/lppbap/jsp/
You can use hot key (short cut key) for actions such as, save, query, and navigate thru records, instead of using mouse clicking, please read the help, it works almost like Oracle developer forms and it is all handled by AJAX....
The above application was generated by an ASP version of tool, which is located at http://rhae.dunco.com.my/tools/LoginFormServlet, all the web forms, JS for AJAX, request & action handler Java classes, db transaction/queru handling JavaBean are all generated. A working, data-entry applications can be deployed within minutes. You only need to focus on coding complex business logic, such as calculation of tax, deduction etc for an online accounting application system
Would like to seek for publiv comment, and try it out