hi all, curious about your input on this latest design experience i''ve had with camping. none of that developing a traditional html ui, a ruby backend, and ajax-ifying the application after being built. - i started straight off with a camping-based json api (for the model). - next step was writing the controller in pure js - no dom interactions here. - then finishing off with a view that''s generated onload by pure js. and hooks into the controller by observing relevant actions. camping allowed the complexity of the application to be pushed into the model on the server-side. putting the view and controller on the same side of the internet seems to make development and use of the application way more fun. how can we stretch and pull on this camping business to let the view and controller to live even closer? is there a prototype/camping perspective on rjs? perhaps bundling js hooks in markaby? anyone having a similar experience? -adam
Hi Adam, On 15/07/06, Adam Bouhenguel <adamb at mit.edu> wrote:> none of that developing a traditional html ui, a ruby backend, and > ajax-ifying the application after being built. > - i started straight off with a camping-based json api (for the model). > - next step was writing the controller in pure js - no dom interactions here. > - then finishing off with a view that''s generated onload by pure js. > and hooks into the controller by observing relevant actions.That looks interesting. Would you like to show some code ? Another question that comes to my mind : does the browser always stay on the same url ?> how can we stretch and pull on this camping business to let the view > and controller to live even closer? is there a prototype/camping > perspective on rjs? perhaps bundling js hooks in markaby? anyone > having a similar experience?I have some suggestions. To make the model available to the web, a kind of ActiveRessouce for Camping could be nice. A standardized way to access the model trough a RESTful API. I''ve already started to design something for my Equipment lib but it is not quite there yet. There is a generic part and a specialized one for Og. Maybe you want to work on the AR one ? The second would be to add content-type detection to Camping. I''ve heard Rails already has a similar mechanism. Actually I thinkt this can be done pretty easily by changing the render/method_missing method a little bit. The basics are pretty the same. I''ve put a small page in the wiki to show the differences : http://code.whytheluckystiff.net/camping/wiki/RespondTo Also, my personnal opinion on RJS is that it''s bad because you can''t recreate the whole language. I prefer putting efforts in making javascript easier to use. I particularly like the event-selectors javascript library to decouple the javascript in a separate page. http://encytemedia.com/event-selectors/ -- Cheers, zimbatm http://zimbatm.oree.ch
why the lucky stiff
2006-Jul-16 04:46 UTC
camping - inspiring new way to write applications
On Sat, Jul 15, 2006 at 12:27:21PM -0400, Adam Bouhenguel wrote:> how can we stretch and pull on this camping business to let the view > and controller to live even closer? is there a prototype/camping > perspective on rjs? perhaps bundling js hooks in markaby? anyone > having a similar experience?I use JQuery with Camping and it works just great. I''m not that great with JavaScript, though, and I never have any ideas for it, so I always overlook the possibilities. Doing all the controllers in JSON is a good one. I''ll bet there are some clever `service` overrides which could lead to `get_json`, `get_html`, `post_json` and that sort of thing. Or helpful conversion of objects returned from `get` or `post` to JSON, HTML, whatever''s in Accept. I don''t know, my ideas are pretty limited. I can''t wait to see what you all cook up, though. _why
On 16/07/06, why the lucky stiff <why at whytheluckystiff.net> wrote:> I use JQuery with Camping and it works just great. I''m not that great with > JavaScript, though, and I never have any ideas for it, so I always overlook > the possibilities.Yay, JQuery is very smart ! Thanks :-)> Doing all the controllers in JSON is a good one. I''ll bet there are some clever > `service` overrides which could lead to `get_json`, `get_html`, `post_json` and > that sort of thing. Or helpful conversion of objects returned from `get` or > `post` to JSON, HTML, whatever''s in Accept. > > I don''t know, my ideas are pretty limited. I can''t wait to see what you all > cook up, though.Content negociation is pretty hairy. At least apache''s one : http://httpd.apache.org/docs/2.0/content-negotiation.html Your get_#{ext} is a pretty good idea. It would allow external discovery of available content-types. I''ll try to implement this to see how it does. -- Cheers, zimbatm http://zimbatm.oree.ch
> > none of that developing a traditional html ui, a ruby backend, and > > ajax-ifying the application after being built. > > - i started straight off with a camping-based json api (for the model). > > - next step was writing the controller in pure js - no dom interactions here. > > - then finishing off with a view that''s generated onload by pure js. > > and hooks into the controller by observing relevant actions. > > That looks interesting. Would you like to show some code ? Another > question that comes to my mind : does the browser always stay on the > same url ?The code for this application is in a bit of an in-between state, but I''ll see what I can pull out. At the moment, yes - the browser does always stay on the same url. but that''s more a feature of this particular application than representative of the general method that i''m using.> I have some suggestions. > > To make the model available to the web, a kind of ActiveRessouce for > Camping could be nice. A standardized way to access the model trough a > RESTful API. I''ve already started to design something for my Equipment > lib but it is not quite there yet. There is a generic part and a > specialized one for Og. Maybe you want to work on the AR one ?Excellent idea - an AR binding for javascript would be a cool piece of work. You said there''s a general part of your lib? Is it extractable/sharable at the moment?> The second would be to add content-type detection to Camping. I''ve > heard Rails already has a similar mechanism. Actually I thinkt this > can be done pretty easily by changing the render/method_missing method > a little bit. The basics are pretty the same. I''ve put a small page in > the wiki to show the differences : > http://code.whytheluckystiff.net/camping/wiki/RespondTo > > Also, my personnal opinion on RJS is that it''s bad because you can''t > recreate the whole language. I prefer putting efforts in making > javascript easier to use. I particularly like the event-selectors > javascript library to decouple the javascript in a separate page. > http://encytemedia.com/event-selectors/I agree with the failings of rjs, though I was talking about some clever way of keeping all your js in the same file. if, as we''re suggesting, there''s a MVC relationship on top of the one camping provides, and parts of the controllers live in the browser, it would be nice to keep those bits in the camping file as well. best, adam
> > Doing all the controllers in JSON is a good one. I''ll bet there are some clever > > `service` overrides which could lead to `get_json`, `get_html`, `post_json` and > > that sort of thing. Or helpful conversion of objects returned from `get` or > > `post` to JSON, HTML, whatever''s in Accept. > > > > Your get_#{ext} is a pretty good idea. It would allow external > discovery of available content-types. I''ll try to implement this to > see how it does. >i like the idea of get_gist or get_auto, where whatever''s returned is converted via to_html, to_json, to_xml, etc. adam
On 16/07/06, Adam Bouhenguel <adamb at mit.edu> wrote:> > That looks interesting. Would you like to show some code ? Another > > question that comes to my mind : does the browser always stay on the > > same url ? > > The code for this application is in a bit of an in-between state, but > I''ll see what I can pull out. At the moment, yes - the browser does > always stay on the same url. but that''s more a feature of this > particular application than representative of the general method that > i''m using.Ok, let us know when it''s ready :-)> > To make the model available to the web, a kind of ActiveRessouce for > > Camping could be nice. A standardized way to access the model trough a > > RESTful API. I''ve already started to design something for my Equipment > > lib but it is not quite there yet. There is a generic part and a > > specialized one for Og. Maybe you want to work on the AR one ? > > Excellent idea - an AR binding for javascript would be a cool piece of > work. You said there''s a general part of your lib? Is it > extractable/sharable at the moment?I do have something, but it''s not quite finished. You can get equipment''s source with "svn checkout svn://rubyforge.org//var/svn/equipment/trunk". The file is in ext/ressource.rb> > The second would be to add content-type detection to Camping. I''ve > > heard Rails already has a similar mechanism. Actually I thinkt this > > can be done pretty easily by changing the render/method_missing method > > a little bit. The basics are pretty the same. I''ve put a small page in > > the wiki to show the differences : > > http://code.whytheluckystiff.net/camping/wiki/RespondTo > > > > Also, my personnal opinion on RJS is that it''s bad because you can''t > > recreate the whole language. I prefer putting efforts in making > > javascript easier to use. I particularly like the event-selectors > > javascript library to decouple the javascript in a separate page. > > http://encytemedia.com/event-selectors/ > I agree with the failings of rjs, though I was talking about some > clever way of keeping all your js in the same file. if, as we''re > suggesting, there''s a MVC relationship on top of the one camping > provides, and parts of the controllers live in the browser, it would > be nice to keep those bits in the camping file as well.JQuery looks really nice. You don''t have to put your javascript in the page since it loads the element asychronously. You can also look in ext/js_helpers.rb for joined scripts (to avoid IE loading order bug) -- Cheers, zimbatm http://zimbatm.oree.ch