> We could even have extensions for things like ajax, so you could add onclick > properties with proc values, such that an ajax call back to the server (or > websockets or whatever) lets the server do stuff and mutate the dom or > replace the page entirely.
I really like this idea, but don't you risk getting into a situation where you're maintaining all your application logic in a view? In an ajax-heavy app you'd end up with a couple of controllers and then heaps of code in your view. I suppose elements could support a property like that's basically like the R() method for building link hrefs, but with semantics that specifically make them useful for defining AJAX handlers. One problem for me with this stuff in any web framework is that the distinction between standard handlers and AJAX ones is (necessarily) foggy. I wonder if there's a clear solution to this that doesn't involve uncomfortably shoehorning handlers into one category of the other. On Sunday, 18 December 2011 at 10:42 AM, Jenna Fox wrote: > Markaby is kind of bad though. It has problems, like it doesn't cope well > with boolean attributes (last I looked anyway), and it's totes out of date > with HTML5 and all that. Could we take this opportunity to start a new > project, with Markaby compatible syntax (at least optionally) based around > modern web standards, with direct straight forward support for html5 syntax, > modern tags and attributes, better validation (perhaps by scanning the actual > validator files produced by the html5 working group, or at least a format > programatically derived from it so we need not maintain tedious lists?), and > an explicit widgeting system where you can define your own virtual tags, > which emit tags and code to do higher level jobs - for instance a blueprint > module, supporting the twitter blueprint framework with nice APIs, allowing > it's use almost akin to a desktop windowing toolkit. We could even have > extensions for things like ajax, so you could add onclick properties with > proc values, such that an ajax call back to the server (or websockets or > whatever) lets the server do stuff and mutate the dom or replace the page > entirely. Native support for eventsource could be enabled with Shoes-like > animate tags, where the server would run code from time to time and stream > out updates to the viewer. > > When Why made the original Hackety Hack atop web tech, the web was immature > and buggy for writing apps, and the project failed from a mix of Gecko being > really nasty, and the web being a bad platform for that sort of software. I > think we have a chance for a do-over. These days it's easy to do things like > script a textarea in to being a richly formatted text or code editor (without > needing to fuss around with the horrible contentEditable), or use a canvas > tag or svg to render fun shapes and animations, or play sounds and videos. > CSS can run animations and transitions at a C level, and can do hardware 3d > transforms. WebGL is nearing too, and could potentially be interfaced via a > websocket, the same way linux apps interface with an X11 server today. > > Doesn't that sound like a cool thing? > > > — > Jenna Fox > > > On Sunday, 18 December 2011 at 9:33 AM, Magnus Holm wrote: > > > Okay, we might have a slight problem: > > > > It doesn't seem that Markaby ever had a specific license. This means > > that it's currently "Copyright © _why" and we might not have the right > > to re-distribute (or contribute to) it. > > > > So first of all: if you've ever seen a LICENSE/COPYING-file (or > > something else that explicitly says the license) related to Markaby, > > please let us know! > > > > If not, I'm wondering what we should do. I don't think that _why would > > really care if people brought his libraries forward, but I kinda get > > an uneasy feeling about this. > > > > // Magnus Holm > > _______________________________________________ > > Camping-list mailing list > > Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) > > http://rubyforge.org/mailman/listinfo/camping-list > > > > > > > > > _______________________________________________ > Camping-list mailing list > Camping-list@rubyforge.org (mailto:Camping-list@rubyforge.org) > http://rubyforge.org/mailman/listinfo/camping-list > >
_______________________________________________ Camping-list mailing list Camping-list@rubyforge.org http://rubyforge.org/mailman/listinfo/camping-list
