Changes for page ERPrototaculous

Summary

• Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

...	...	@@ -9,7 +9,7 @@
9	9	* 'Organic' support for Prototype and Scriptaculous in WebObjects.
10	10	** Light-weight dynamic elements to support Prototype
11	11	** No custom patches to Prototype
12		-** Sans extensions to Prototype
	12	+** Sans the need to extend Prototype
13	13	* Use of [[Unobtrusive Javascript>>http://en.wikipedia.org/wiki/Unobtrusive_JavaScript]].
14	14	* Pseudo-stateless ajax responses
15	15	* A set of widgets in the Prototype + Scriptaculous family.
...	...	@@ -18,7 +18,7 @@
18	18
19	19	Unobtrusive javascript is used in contrast to on-demand style of ajax programming.
20	20	By including Javascript as well as CSS globally in the page wrapper, CSS and Javascript don't have to load inside each and every ajax requests.
21		-This keeps the ajax responses compact and simple.
	21	+This keeps the ajax responses compact and granular.
22	22
23	23	The result is **faster** and more **reliable** ajax in WebObjects.
24	24
...	...	@@ -34,11 +34,12 @@
34	34	* AjaxUpdaterButton
35	35	* AjaxUpdaterForm (with ##onsubmit## for ajax form submission)
36	36
37		-These components will update //any// **container** on the page:
	37	+These components will update a **container** on the page.
	38	+Note that this container can be //any// element in the DOM. Unlike Ajax.framework it doesn't need to be an //AjaxUpdateContainer//:
38	38
39	39	{{code value="javascript"}}
40	40
41		-new Ajax.Updater('container', url, {options});
	42	+ new Ajax.Updater('container', url, {options});
42	42
43	43	{{/code}}
44	44
...	...	@@ -53,7 +53,7 @@
53	53
54	54	{{code value="javascript"}}
55	55
56		-new Ajax.Request(url, {options});
	57	+ new Ajax.Request(url, {options});
57	57
58	58	{{/code}}
59	59
...	...	@@ -75,11 +75,13 @@
75	75	(WebObjects dynamically assigned names are not compatible with ERPrototaculous).
76	76	1. All ajax forms in an ERPrototaculous app need to be instances of ##AjaxUpdaterForm##.
77	77	1. Ajax form submit buttons can be a:
78		-1*. Static ##<button>##.
79		-1*. WOSubmitButton (if the result is to update whole page/app).
80		-1*. AjaxUpdaterButton (to update a **container**). Or
81		-1*. AjaxRequestButton (for a **background** ajax request).
82	82
	80	+*
	81	+** Static ##<button>##.
	82	+** WOSubmitButton (if the result is to update whole page/app).
	83	+** AjaxUpdaterButton (to update a **container**). Or
	84	+** AjaxRequestButton (for a **background** ajax request).
	85	+
83	83	So forms are different in Ajax.framework and ERPrototaculous.
84	84
85	85	In ERPrototaculous you may still have typical WebObjects forms (i.e WOForm) as well as use ajax forms (i.e **AjaxUpdaterForm**).
...	...	@@ -96,16 +96,17 @@
96	96	One notable difference between the ERPrototaculous and Ajax frameworks is in the way they handle ajax responses.
97	97	In ERPrototaculous, updates and actions break with //The WebObjects Way// by being pseudo-stateless.
98	98
99		-In a typical WebObjects application, when a user navigates to the previous page using the browser back button and subsequently clicks on a link in on that page, WebObjects needs to remember how to handle that action and to return the correct page. This is no longer necessary for ajax.
	102	+WebObjects typically vends a fresh response for each and every action. With ajax, this is not necessary.
100	100
101		-A user never travels backwards or forwards through the ajax application history.
102		-(i.e there is no forward/back buttons for ajax requests - just as there aren't forward/back buttons on desktop apps).
	104	+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.
	105	+The reason is a user never travels backwards or forwards through the ajax application history.
	106	+(i.e there is no forward/back buttons in a 100% ajax app - as there aren't in desktop apps).
103	103
104	104	So for ajax, the current state of the page fragment component is all that is necessary.
105	105
106	106	{{info title="No More"}}
107	107
108		-A 100% ajax WO-app (like an [ERDivaLook|ERDivaLook] app) is no longer plagued by the well known _limitation_ of WebObjects - the browser *backtrack problem*.
	112	+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*.
109	109
110	110	{{/info}}
111	111
...	...	@@ -114,8 +114,8 @@
114	114	Typically, in a WebObjects application, an action would return the contents of the entire page.
115	115
116	116	Ajax responses are mostly page fragments or just part of a page.
117		-So you should make sure the actions in ERPrototaculous (or AjaxUpdaterButton and AjaxRequestButton) return the proper page fragment as opposed to the entire page.
118		-This breaks with WO-tradition (again), so this is where you need to be careful.
	121	+So you should make sure the actions in ERPrototaculous (or AjaxUpdaterButton and AjaxRequestButton) return the proper page fragment as opposed to the entire page.
	122	+This breaks with WO-tradition, so this is where you need to be careful.
119	119
120	120	{{note title="Note"}}
121	121
...	...	@@ -132,4 +132,3 @@
132	132	It is similar to an AjaxUpdateContainer when it has the binding ##ajax = true##, otherwise it's pretty much like **WOGenericContainer**.
133	133
134	134	It has been implemented as a utility or //convenience// for Prototype's ##Ajax.Updater##.
135		-That is it can be used to update from a DOM //event// like popup //onchange//, or from a Prototype //callback// like //onComplete//, etc.