Changes for page Alternative Technologies-Ruby on Rails

Summary

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

Details

Page properties

Parent

...	...	@@ -1,1 +1,0 @@
1		-To classify

Content

...	...	@@ -8,11 +8,11 @@
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
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.
	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		-//[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[[doc: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	17	==== Myth: You can't assign the name or id value of tags in WebObjects. ====
18	18
...	...	@@ -41,11 +41,11 @@
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	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	50	==== Research ====
51	51
...	...	@@ -53,7 +53,7 @@
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 0="xml"}}
	56	+{{code value="xml"}}
57	57
58	58	<div id='<= posting.id'>
59	59	<%= link_to_remote [div to update] [link options] -> %>
...	...	@@ -63,7 +63,7 @@
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 0="xml"}}
	66	+{{code value="xml"}}
67	67
68	68	<div id='<WEBOBJECT name=postingID></WEBBOBJECT>'>
69	69	<a href="#" onclick="new Ajax.Updater('<WEBOBJECT name=postingID></WEBBOBJECT>',
...	...	@@ -111,7 +111,7 @@
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 0="xml"}}
	114	+{{code value="xml"}}
115	115
116	116	<WEBOBJECT name=RatingDiv></WEBOBJECT>
117	117
...	...	@@ -144,7 +144,7 @@
144	144
145	145	**However, there's a gotcha there, because component actions called from javascript count towards your backtracking count. Since someone might be going down through the page clicking rating after rating, that could be a problem. If your max backtracking count was 10, and you had 20 postings on a page, they wouldn't be able to rate the 11th page.**
146	146
147		-So where Rails has one line, I have two WOTags, but those could (and should) be easily combined by creating a WODynamicElement to generate the link directly. In essence, it would be pretty easy to create a "RemoteLink" WODynamicElement that did everything the Rails "link_to_remote" call did, namely take an id to update along with all the options WOActionURL takes.
	147	+So where Rails has one line, I have two WOTags, but those could (and should) be easily combined by creating a WODynamicElement to generate the link directly. In essence, it would be pretty easy to create a "RemoteLink" WODynamicElement that did everything the Rails "link//to//remote" call did, namely take an id to update along with all the options WOActionURL takes.
148	148
149	149	But additionally the WebObjects solution is superior in a number of ways to the Rails solution. Rails has support for both "partial pages" and "components" but the reality is that components are pretty heavyweight/slow and partials don't quite do what you think. So the WebObjects solution, by wrapping both the logic and state into a component ends up being more DRY (Don't Repeat Yourself) and better encapsulated than the typical Rails solution. In the page where you want the Ajax bit, you specify the component, and you put the ajax handling logic in the component itself.
150	150
...	...	@@ -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/>>url:http://developer.yahoo.com/yui/||shape="rect"]]
	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>>url:http://developer.yahoo.com/yui/container/dialog/index.html||shape="rect"]]
	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