Skip to Content
Last modified by Pascal Robert on 2007/09/03 20:53
From version 7.1
edited by Quinton Dolan
on 2007/08/28 18:00
Change comment: There is no comment for this version
To version 11.1
edited by smmccraw
on 2007/07/08 09:43
Change comment: There is no comment for this version

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.qdolan
1 +XWiki.smmccraw
Content
... ... @@ -10,7 +10,7 @@
10 10  
11 11  Additionally, the WO documentation has always pushed people erroneously towards component actions and away from direct actions. If you use 90% direct actions like I do in my application, (See my "WebObjects on Rails" post), you'll find that direct actions are simple to code in reality, and very much like Rails which basically doesn't have component actions at all.
12 12  
13 -//Which is to say, if you avoid much of the power of WO, and don't use component actions, ajax will be easier. If you do use component actions - and I have yet to work on a project that doesn't - then ajax use seems like it will blow your page cache, as described below. So it really is easy to use AJAX in WO. Really easy. It's just that it doesn't work.//
13 +//[[Which is to say, if you avoid much of the power of WO, and don't use component actions, ajax will be easier. If you do use component actions - and I have yet to work on a project that doesn't - then ajax use seems like it will blow your page cache, as described below. So it really is easy to use AJAX in WO. Really easy. It's just that it doesn't work]]//
14 14  
15 15  //[[mschrag: While I agree with the above commenter that component actions provide a huge amount of power in WO, it is NOT true that Ajax and component actions are incompatible. ~[Project Wonder's Ajax components>>Programming__WebObjects-Project_WONDER-Frameworks-Ajax]] directly addresses the use of component actions with Ajax in a way that does NOT blow the page cache. While it is true that the implementation of these capabilities inside of Wonder was non-trivial, it demonstrates that it is, in fact, possible, and if you use the PW components along with ERXSession, you will get this capability for free.]//
16 16  
... ... @@ -20,16 +20,16 @@
20 20  
21 21  Reality: Actually, what really happens is that if you DON'T have a name=value or id=value line for your TextArea in WebObjects, it will generate a unique one for you. But you're more than welcome to specify one in your .wod file, and WO will use that. It's then up to //you// to make sure its unique, so that you don't have multiple text area tags with the same name. In other words if you only have one textarea you wish to attach a Javascript WYSIWYG editor to, just add:
22 22  
23 -{{code}}
23 +{{panel}}
24 24  
25 -textarea: WOText
26 -{
27 - id='wysiwyg';
28 - name='wysiwyg';
29 - value=textValue;
30 -}
25 + textarea: WOText
26 + {
27 + id='wysiwyg';
28 + name='wysiwyg';
29 + value=textValue;
30 + }
31 31  
32 -{{/code}}
32 +{{/panel}}
33 33  
34 34  in your .wod file and you can use id with your Javascript just fine.
35 35  
... ... @@ -41,12 +41,12 @@
41 41  
42 42  We haven't used a lot of JavaScript at www.marketocracy.com, for a very simple reason: We don't have the testing staff to fire up 10 different browser variations to test the site. And lets face it, programming in JavaScript sucks.
43 43  
44 -Since someone invented that cool acronym though, that's changing. You would think it shouldn't matter that something has a name, but it does. I remember when the GoF Design Patterns book came out. There was nothing in there I hadn't figured out on my own, but now they had a name! I could say "Singleton" to my co-workers and they would know what I was talking about.
44 +Since someone invented that cool acronym though, that's changing. You would think it shouldn't matter that something has a name, but it does. I remember when the GoF Design Patterns book came out. There was nothing in there I hadn't figured out on my own, but now they had a name!//I//could//say//"Singleton"//to//my//co-workers//and//they//would//know//what//I//was//talking//about.//I//could//buy//a//junior//engineer//the//book,//and//he//would//soon//be//programming//at//a//much//higher//level.//
45 45  
46 -I could buy a junior engineer the book, and he would soon be programming at a much higher level.
47 -So having a name helped, and the result is that there are a lot of cool toolkits out there. Since someone else wrote the JavaScript, that means I don't need to test 10 different browser variations.
48 -Which means I can make the site much easier to use and more interactive. Huzzah!
46 +So//having//a//name//helped,//and//the//result//is//that//there//are//a//lot//of//cool//toolkits//out//there.//Since//someone//else//wrote//the//JavaScript,//that//means//I//don't//need//to//test//10//different//browser//variations.//
49 49  
48 +Which//means//I//can//make//the//site//much//easier//to//use//and//more//interactive.//Huzzah!
49 +
50 50  ==== Research ====
51 51  
52 52  So the first thing I did was that I'd heard that Rails was cool and made Ajax easy. I'd heard that before, but that was when the version number was 0.13... So I went out and bought the Rails books and you know what I found?
... ... @@ -53,24 +53,23 @@
53 53  
54 54  It's not that Rails rocks with Ajax, its that the Prototype Javascript library rocks. The documentation makes a big deal about doing Ajax with one line of code.
55 55  
56 -{{code value="xml"}}
56 +{{panel}}
57 57  
58 -<div id='<= posting.id'>
59 - <%= link_to_remote [div to update] [link options] -> %>
60 -</div>
58 + <div id='<= posting.id'>
59 + <%= link_to_remote [div to update] [link options] -> %>
60 + </div>
61 61  
62 -{{/code}}
62 +{{/panel}}
63 63  
64 64  The reality is that all Rails is doing is writing one line of JavaScript. From the Ajaxy "rating" code I've been adding to my app, look at the following:
65 65  
66 -{{code value="xml"}}
66 +{{panel}}
67 67  
68 -<div id='<WEBOBJECT name=postingID></WEBBOBJECT>'>
69 - <a href="#" onclick="new Ajax.Updater('<WEBOBJECT name=postingID></WEBBOBJECT>',
70 - '<WEBOBJECT name=ratePosting></WEBOBJECT>', {asynchronous:true, evalScripts:true}); return false;">1</a>
71 -</div>
68 + <div id='<WEBOBJECT name=postingID></WEBBOBJECT>'>
69 + <a href="#" onclick="new Ajax.Updater('<WEBOBJECT name=postingID></WEBBOBJECT>', '<WEBOBJECT name=ratePosting></WEBOBJECT>', {asynchronous:true, evalScripts:true}); return false;">1</a>
70 + </div>
72 72  
73 -{{/code}}
72 +{{/panel}}
74 74  
75 75  Ok, so lets break it down. The way Ajax.Updater works from the Prototype library is you give it the id of a DOM object and a URL, and it replaces the DOM object with that id with the contents of the URL. Usually, you specify the area to update with a div tag which I've shown for completeness. For ratings I would need 1 div tag to enclose all 5 rating stars: <div><a></a><a></a><a></a><a></a><a></a></div>. I would also use a WOGenericContainer to generate the div tag with the right id rather than using the id='<WEBOBJECT name=postingID></WEBBOBJECT>' line, but I wanted it to be obvious it was div tag.
76 76  
... ... @@ -78,67 +78,67 @@
78 78  
79 79  Here I have a manually built <a> tag with an onclick bit of javascript. That makes a single call out to the Prototype library, which has this cool call:
80 80  
81 -{{code}}
80 +{{panel}}
82 82  
83 -new Ajax.Updater( elementid, url, options)
82 + new Ajax.Updater( elementid, url, options)
84 84  
85 -{{/code}}
84 +{{/panel}}
86 86  
87 87  It does something very simple: It pulls the HTML from the specified URL, and replaces the element with the specified id with the downloaded HTML.
88 88  
89 89  The two WebObjects tags specify the element ID and the link, they're just a WOString and a WOActionURL:
90 90  
91 -{{code}}
90 +{{panel}}
92 92  
93 -postingID: WOString { currentPosting.primaryKeyString; }
94 -ratePosting: WOActionURL { see discussion }
92 + postingID: WOString { currentPosting.primaryKeyString; }
93 + ratePosting: WOActionURL { see discussion }
95 95  
96 -{{/code}}
95 +{{/panel}}
97 97  
98 98  Now in my case, I'm a direct action snob. So my WOActionURL would look like the following:
99 99  
100 -{{code}}
99 +{{panel}}
101 101  
102 -ratePosting :WOActionURL
103 -{
104 - directActionName="PostingRater";
105 - ?pkey=currentPosting.primaryKey;
106 - ?rating=cRating;
107 - ?wosid=NO;
108 -}
101 + ratePosting :WOActionURL
102 + {
103 + directActionName="PostingRater";
104 + ?pkey=currentPosting.primaryKey;
105 + ?rating=cRating;
106 + ?wosid=NO;
107 + }
109 109  
110 -{{/code}}
109 +{{/panel}}
111 111  
112 112  This produces a result similar to Rails, because in rails you have to define an action for each class of link. In my case I tie directactions to pages/components, so my "PostingRater" page would return component-level HTML (minus any HEAD/BODY tags) that matched the existing <div> definition. Since we're using WebObjects, that turns out to be trivially easy if we build the enclosing <div> tag with a component PostingRater can just look like:
113 113  
114 -{{code value="xml"}}
113 +{{panel}}
115 115  
116 -<WEBOBJECT name=RatingDiv></WEBOBJECT>
115 + <WEBOBJECT name=RatingDiv></WEBOBJECT>
117 117  
118 -{{/code}}
117 +{{/panel}}
119 119  
120 120  Using component actions, it could be even simpler:
121 121  
122 -{{code}}
121 +{{panel}}
123 123  
124 -ratePosting: WOActionURL { action=ratePosting;}
123 + ratePosting: WOActionURL { action=ratePosting;}
125 125  
126 -{{/code}}
125 +{{/panel}}
127 127  
128 128  Because WebObjects, unlike Rails can have stateful components, the RatingDiv component could actually have all the logic and return self as the result of the action:
129 129  
130 -{{code}}
129 +{{panel}}
131 131  
132 -public WOReponse ratePosting
133 -{
134 - currentPosting.ratePosting(currentRating);
135 - return self; // since this is called from JavaScript
136 - // return just myself, not self.page
137 - // this will tell WO to render only
138 - // this as a result.
139 -}
131 + public WOReponse ratePosting
132 + {
133 + currentPosting.ratePosting(currentRating);
134 + return self; // since this is called from JavaScript
135 + // return just myself, not self.page
136 + // this will tell WO to render only
137 + // this as a result.
138 + }
140 140  
141 -{{/code}}
140 +{{/panel}}
142 142  
143 143  That is, the link for the javascript would go into the RatingDiv component with everything already setup: the current posting, the current rating. Returning self then causes the div to regenerate.
144 144