Direct Ajax - Goodbye to Ajax Deadly Sins

[rose]

October 2008


Deadly Sins of Rich Internet Application!
Let me begin with a story about my friend, a tech lead at a small business company. He was assigned to enrich his company's "Expense Claim" application with Ajax technologies. At first, he planned to deliver the application in 3 months, but it wound up taking him 6 months. Here are some of Ajax deadly sins that delayed his project:

Browser Incompatibility Firstly, he decided to develop in-house JavaScript codes for the UI, the first draft of which took his team 2 months to finish. Then he discovered that the layout was a mess on different browsers. Due to a lack of JavaScript knowledge, he then decided to adopt an off-the-shelf Ajax widgets framework along with a Java-to-JavaScript framework in order to overcome this browser incompatibility issue; that, of course, meant re-building the UI from scratch.

Tedious Client Server Communication Codes Just when it appeared that his team had escaped from the nightmare of JavaScript, there came an even bigger challenge related to integration between the UI and the back-end. The Java-to-JavaScript framework required RPC calls to get data from the server, and handle the returned data manually. It produced numerous files to communicate between the client and the server. Though developing in pure Java, his team spent a few more months finishing the integration.

Slow Performance During testing by their users, it was discovered that the performance was unacceptable; users had to wait for more than 10 seconds for 10,000 records to be loaded. Even worse, some old computers actually stalled. Unfortunately, they had to implement load-on-demand to improve the performance issue. But, load-on-demand was never an easy job. It required determining the visible area at the client side, prompting required data from the server side, and rendering the data on the browsers. To fulfill this requirement, his team had to delay the project a few additional months.

Maintenance Headache Later in the project cycle, he was informed that extra fields would be added to the data model. This was really a nightmare for his team since they not only had to modify the back-end codes, but also the associated client codes. They spent another month on maintaining the consistency of business logic between client and server codes.

....
http://www.theserverside.com/tt/article ... DirectAjax

_____________
ZK framework http://www.zkoss.org/

[cyberpython]

Δε λέω οτι έχει άδικο, όμως τα πράγματα ΔΕΝ είναι τόσο "μαύρα" όσο τα παρουσιάζει (π.χ. προφανώς όταν έχεις φθάσει σε ένα προχωρημένο στάδιο της υλοποίησης και οι προδιαγραφές αλλάζουν, όποια τεχνολογία και να έχεις χρησιμοποιήσει δεν υπάρχει περίπτωση να μην αντιμετωπίσεις προβλήματα και καθυστερήσεις...)

Επίσης, ενδιαφέρον έχει και ποιος υπογράφει το συγκεκριμένο κείμενο:

Robbie Cheng is the author of, ZK: Ajax without the Javascript Framework, from Potix Corporation.

Δεν είναι περίεργο που το προϊόν του (ΖΚ framework) πληρεί όλες τις προϋποθέσεις για Direct Ajax (εν.ω π.χ. το GWT μόλις μία - που δεν είναι και από τις βασικές);

[rose]

Βασικά ο τύπος δεν λέει τπτ καινούργιο, ειναι γνωστό το concept separation of responsibilities, πολύ απλά και πρακτικά λέει οτι οκ εισαι application developer, άσε σε εμένα κάθε έννοια που δεν σχετίζεται με την εφαρμογή και εσύ ανεμπόδιστα μπορείς να επικεντρωθείς καθαρά στο business logic. Οπότε ναι ειναι γεγονός, λιγότερες αρμοδιότητες, ευκολότερη ζωή.

Τώρα για το μοντέλο που προτείνει νομίζω έχει παρεξηγηθεί λίγο (στο serverSide Forum) απλα μιλάει για προϋποθέσεις( Direct Database Access ) οχι για best practices - software patterns.

Οπότε στο παράδειγμα Direct Database Access, θα προσθέταμε ενα extra business layer, που αυτό και μόνο θα είχε απευθείας πρόσβαση στη βάση - best practice.

Code: Select all

 
Hi. <label id="name"/>
<button>
  <attribute name="onClick">
  User usr = Database.getUserById(1);     //  invoke business layer ---> UserManagerEJB.getUserById(1);      
  name.setValue(usr.getName());
  </attribute>
</button>

[redlabel]

Βασικά ο τύπος δεν λέει τπτ καινούργιο, ειναι γνωστό το concept separation of responsibilities, πολύ απλά και πρακτικά λέει οτι οκ εισαι application developer, άσε σε εμένα κάθε έννοια που δεν σχετίζεται με την εφαρμογή και εσύ ανεμπόδιστα μπορείς να επικεντρωθείς καθαρά στο business logic. Οπότε ναι ειναι γεγονός, λιγότερες αρμοδιότητες, ευκολότερη ζωή.

Από την άλλη πλευρά, όλα τα αξιόλογα προβλήματα απαιτούν ευρύτερες οπτικές για να επιλυθούν αποδοτικά, οπότε το focus στο business logic δεν επαρκεί. Οπότε, λιγότερες αρμοδιότητες, χαμηλότερη απόδοση. A kind of chicken-and-egg thing...

Δ. Γκρ.

[rose]

Βασικά ο τύπος δεν λέει τπτ καινούργιο, ειναι γνωστό το concept separation of responsibilities, πολύ απλά και πρακτικά λέει οτι οκ εισαι application developer, άσε σε εμένα κάθε έννοια που δεν σχετίζεται με την εφαρμογή και εσύ ανεμπόδιστα μπορείς να επικεντρωθείς καθαρά στο business logic. Οπότε ναι ειναι γεγονός, λιγότερες αρμοδιότητες, ευκολότερη ζωή.

Από την άλλη πλευρά, όλα τα αξιόλογα προβλήματα απαιτούν ευρύτερες οπτικές για να επιλυθούν αποδοτικά, οπότε το focus στο business logic δεν επαρκεί. Οπότε, λιγότερες αρμοδιότητες, χαμηλότερη απόδοση. A kind of chicken-and-egg thing...

Δ. Γκρ.

Γενική απάντηση, δεν διαφωνώ αλλα αναφέρομαι σε υπηρεσίες (transparent ajax) και οχι στη λύση. Για παράδειγμα αν πρέπει να υπάρξει μια λύση για το χ πρόβλημα, γιατί ταυτόχρονα πρέπει να σε απασχολούν και low level ajax μηχανισμοί;