Skip to Content
Last modified by Pascal Robert on 2007/09/03 20:53
From version 9.1
edited by Marc Guenther
on 2007/08/28 08:59
Change comment: small reformat to make more readable
To version 12.1
edited by Pascal Robert
on 2007/09/03 20:53
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Programming__WebObjects-Alternative Technologies-Ruby on Rails
1 +Alternative Technologies-Ruby on Rails
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.marc
1 +XWiki.probert
Content
... ... @@ -1,10 +1,10 @@
1 -=== Pierce T. Wetter III ===
1 +=== Pierce T. Wetter III ===
2 2  
3 -==== Myth: Rails is a better framework for Ajax than WO. ====
3 +==== Myth: Rails is a better framework for Ajax than WO. ====
4 4  
5 5  Reality: WebObjects is actually a better framework for use with Ajax libraries than Rails because it has a better component system than Rails. You spend a lot of time coding little tiny XML and HTML generators when doing Ajax and WO's component system makes that very DRY (Don't Repeat Yourself).
6 6  
7 -==== Myth: WebObjects is hard to use with Ajax. ====
7 +==== Myth: WebObjects is hard to use with Ajax. ====
8 8  
9 9  Reality: WebObjects is easy to use with Ajax, it's just that there is only one known library for Ajax-WO support, and its not well documented. Even then the library only goes so far in that it just provides new components to wrap a few script.aculo.us tags. I think its more of a documentation gap, not a code gap.
10 10  
... ... @@ -12,9 +12,9 @@
12 12  
13 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 -//[[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.]//
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  
17 -==== Myth: You can't assign the name or id value of tags in WebObjects. ====
17 +==== Myth: You can't assign the name or id value of tags in WebObjects. ====
18 18  
19 19  I'm mentioning this one explicitly, because I had someone ask me about this recently, because they were trying to assign a WYSIWYG JavaScript editor to a text area.
20 20  
... ... @@ -22,53 +22,53 @@
22 22  
23 23  {{code}}
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 32  {{/code}}
33 33  
34 34  in your .wod file and you can use id with your Javascript just fine.
35 35  
36 -==== Myth: WebObjects generates HTML ====
36 +==== Myth: WebObjects generates HTML ====
37 37  
38 38  Reality: Just because the components of your .wo file are .html and .wod doesn't mean WebObjects can only generate HTML. WebObjects is really at heart, a very, very, very, complicated printf. The result of a component can be HTML, XML, JavaScript, or even binary data. You can actually put whatever you want in the .HTML and treat WebObjects like a giant merge engine. For instance, you could generate PDF files using WebObjects; they're just text, and you could substitute text into the middle of the PDF boilerplate pretty easily.
39 39  
40 -==== Background ====
40 +==== Background ====
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.//I//could//buy//a//junior//engineer//the//book,//and//he//would//soon//be//programming//at//a//much//higher//level.//
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 -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.//
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.
47 47  
48 -Which//means//I//can//make//the//site//much//easier//to//use//and//more//interactive.//Huzzah!
48 +Which means I can make the site much easier to use and more interactive. Huzzah
49 49  
50 -==== Research ====
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 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}}
56 +{{code value="xml"}}
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 62  {{/code}}
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}}
66 +{{code value="xml"}}
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>',
70 + '<WEBOBJECT name=ratePosting></WEBOBJECT>', {asynchronous:true, evalScripts:true}); return false;">1</a>
71 +</div>
72 72  
73 73  {{/code}}
74 74  
... ... @@ -80,7 +80,7 @@
80 80  
81 81  {{code}}
82 82  
83 - new Ajax.Updater( elementid, url, options)
83 +new Ajax.Updater( elementid, url, options)
84 84  
85 85  {{/code}}
86 86  
... ... @@ -90,8 +90,8 @@
90 90  
91 91  {{code}}
92 92  
93 - postingID: WOString { currentPosting.primaryKeyString; }
94 - ratePosting: WOActionURL { see discussion }
93 +postingID: WOString { currentPosting.primaryKeyString; }
94 +ratePosting: WOActionURL { see discussion }
95 95  
96 96  {{/code}}
97 97  
... ... @@ -99,21 +99,21 @@
99 99  
100 100  {{code}}
101 101  
102 - ratePosting :WOActionURL
103 - {
104 - directActionName="PostingRater";
105 - ?pkey=currentPosting.primaryKey;
106 - ?rating=cRating;
107 - ?wosid=NO;
108 - }
102 +ratePosting :WOActionURL
103 +{
104 + directActionName="PostingRater";
105 + ?pkey=currentPosting.primaryKey;
106 + ?rating=cRating;
107 + ?wosid=NO;
108 +}
109 109  
110 110  {{/code}}
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}}
114 +{{code value="xml"}}
115 115  
116 - <WEBOBJECT name=RatingDiv></WEBOBJECT>
116 +<WEBOBJECT name=RatingDiv></WEBOBJECT>
117 117  
118 118  {{/code}}
119 119  
... ... @@ -121,7 +121,7 @@
121 121  
122 122  {{code}}
123 123  
124 - ratePosting: WOActionURL { action=ratePosting;}
124 +ratePosting: WOActionURL { action=ratePosting;}
125 125  
126 126  {{/code}}
127 127  
... ... @@ -129,14 +129,14 @@
129 129  
130 130  {{code}}
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 - }
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 +}
140 140  
141 141  {{/code}}
142 142  
... ... @@ -154,11 +154,11 @@
154 154  
155 155  I also think, that from this example, dojo is a bit weak as a Javascript toolkit. You'll spend a lot of time wiring stuff up in Javascript with Dojo compared to Prototype. Or contrast dojo with the Yahoo UI library:
156 156  
157 -http:~/~/developer.yahoo.com/yui/
157 +[[http://developer.yahoo.com/yui/]]
158 158  
159 159  The whole "Dialog" thing in yui is cool:
160 160  
161 -http:~/~/developer.yahoo.com/yui/container/dialog/index.html
161 +[[http://developer.yahoo.com/yui/container/dialog/index.html]]
162 162  
163 163  And would lend itself quite readily to the model WO has of building pages out of pieces.
164 164  
... ... @@ -165,5 +165,3 @@
165 165  Then again, dojo is only at version 0.3. The WYSIWYG editor is nice, but I really don't want to have to define my dialog boxes in yet another tag language. HTML is good enough for me.
166 166  
167 167  So exactly what problems are you having with dojo/wo? Consider that the problem may be dojo, not WO in particular. You could easily create a WODynamicElement for every new dojo tag, collect them in components, and have something much easier to use than straight dojo.
168 -
169 -Category:WebObjects