Changes for page ERPrototaculous

Last modified by Ravi Mendis on 2010/11/18 05:07

From version 168.1
edited by Ravi Mendis
on 2009/07/20 02:31
Change comment: add link to diva look page
To version 173.1
edited by Ravi Mendis
on 2009/07/17 03:41
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -24,11 +24,11 @@
24 24  
25 25  ==== Prototype WebObjects Elements ====
26 26  
27 -##Ajax.Updater## and ##Ajax.Request## have been implemented as WebObjects elements.
27 +##Ajax.Updater## and ##Ajax.Request## have been implemented as WebObjects dynamic elements.
28 28  
29 29  ===== Ajax.Updater =====
30 30  
31 -Support for Prototype's [[Ajax.Updater>>http://www.prototypejs.org/api/ajax/updater]] is in the form of three elements:
31 +Support for Prototype's [[Ajax.Updater>>http://www.prototypejs.org/api/ajax/updater]] is in the form of three components:
32 32  
33 33  * AjaxUpdaterLink
34 34  * AjaxUpdaterButton
... ... @@ -67,14 +67,14 @@
67 67  
68 68  Support for these widgets have been similarly implemented as **button** and **link** variants, depending whether it is used inside a form or not.
69 69  
70 -== Ajax Forms in ERPrototaculous ==
70 +== Forms in ERPrototaculous ==
71 71  
72 72  Differences from using forms in WebObjects. i.e ##WOForm##:
73 73  
74 -1. All ajax form controls must be named. This includes text fields, selects and buttons.
74 +1. All form controls must be named. This includes text fields, selects and buttons.
75 75  (WebObjects dynamically assigned names are not compatible with ERPrototaculous).
76 -1. All ajax forms in an ERPrototaculous app need to be instances of ##AjaxUpdaterForm##.
77 -1. Ajax form submit buttons can be a:
76 +1. All forms in an ERPrototaculous app are instances of ##AjaxUpdaterForm##.
77 +1. Form submit buttons can be the form of a:
78 78  
79 79  *
80 80  ** Static ##<button>##.
... ... @@ -85,32 +85,26 @@
85 85  So forms are different in Ajax.framework and ERPrototaculous.
86 86  
87 87  In ERPrototaculous you may still have typical WebObjects forms (i.e WOForm) as well as use ajax forms (i.e **AjaxUpdaterForm**).
88 -They behave differently in that an AjaxUpdaterForm will update the contents of a container as opposed to the entire page.
88 +They behave differently in that n AjaxUpdaterForm will update the contents of a container as opposed to the entire page.
89 89  
90 -== Ajax Response Handling in ERPrototaculous ==
90 +== Ajax Page Caching in ERPrototaculous ==
91 91  
92 -One notable difference between the ERPrototaculous and Ajax frameworks is in the way they handle ajax responses.
93 -In ERPrototaculous, updates and actions break with //The WebObjects Way// by being pseudo-stateless.
92 +One notable difference in the ERPrototaculous and Ajax.framework is in the ajax responses.
93 +In ERPrototaculous, updates and actions break with "The WebObjects Way" by being pseudo-stateless.
94 94  
95 95  WebObjects typically vends a fresh response for each and every action. With ajax, this is not necessary.
96 96  
97 97  In a typical WebObjects application, when a user clicks on the back button and clicks on a link in on that page in the browser history, WebObjects needs to remember how to handle that action and to return the correct page. This is no longer true for ajax.
98 98  The reason is a user never travels backwards or forwards through the ajax application history.
99 -(i.e there is no forward/back buttons in a 100% ajax app - as there aren't in desktop apps).
99 +(i.e there is no forward/back buttons in a 100% ajax app - as there isn't in desktop app).
100 100  
101 101  So for ajax, the current state of the page fragment component is all that is necessary.
102 102  
103 -{{info title="No More"}}
103 +== Actions in ERPrototaculous ==
104 104  
105 -A 100% ajax WO-app (like an [ERDivaLook|ERDivaLook] app) will no longer be plagued by the well known _limitation_ of WebObjects - the browser *backtrack problem*.
106 -
107 -{{/info}}
108 -
109 -== Ajax Actions in ERPrototaculous ==
110 -
111 111  Typically, in a WebObjects application, an action would return the contents of the entire page.
112 112  
113 -Ajax responses are mostly page fragments or just part of a page.
107 +Ajax responses are typically page fragments or part of a page.
114 114  So you should make sure the actions in ERPrototaculous (or AjaxUpdaterButton and AjaxRequestButton) return the proper page fragment as opposed to the entire page.
115 115  This breaks with WO-tradition, so this is where you need to be careful.
116 116  
... ... @@ -126,6 +126,4 @@
126 126  
127 127  Perhaps the only real similarity to Ajax.framework is the ajax update container.
128 128  **WXGenericContainer** is the ERPrototaculous update container.
129 -It is similar to an AjaxUpdateContainer when it has the binding ##ajax = true##, otherwise it's pretty much like **WOGenericContainer**.
130 -
131 -It has been implemented as a utility or //convenience// for Prototype's ##Ajax.Updater##.
123 +It will behave like an AjaxUpdateContainer when it has the binding ##ajax = true;##, otherwise it acts like **WOGenericContainer**.