Just A Summary : Rails 2.0 and the Future of Typo

Comment on Rails 2.0 and the Future of Typo by Rodger

Mon, 17 Dec 2007 01:56:08 -0600

To be honest, the rich client is one of the things that drew me to typo in the first place. I’d be a sad panda if Typo-NG threw it away.

Comment on Rails 2.0 and the Future of Typo by Piers Cawley

Mon, 17 Dec 2007 19:05:42 -0600

I doubt if it’d be going away for good; Frederic’s done sterling work on the admin interface recently, and there’s no reason we can’t make that interface, or something like it, play well with APP. The thing is, because APP is pretty well defined, it we needn’t be the only interface – there’s already an APP plugin for Firefox, for instance, and there will be more, I’m sure.

Comment on Rails 2.0 and the Future of Typo by Christopher Goodrich

Thu, 20 Dec 2007 10:39:45 -0600

Piers,

Love Typo, but have a question. You’ve stated that you really are trying to get the engine slimmed down so that it can offload the processing work to the client, but are you considering that the basics of the existing engine is all server based? Offloading presentation to the client through JavaScript really doesn’t help very much and in today’s web technology, doesn’t CSS perform almost everything that you’d want to do in presentation anyway? Why even bother with JavaScript?

Consider this. Write the basic application in Ruby on Rails, then shove the content and presentation to the client using xhtml and css only. Since these are flat files, you improve on the speed of delivery and rendering at the browser level without the headache of using another interpreted language. This has an added benefit of being easier to learn on the user side, plus if they actually want to use JavaScript, they still can.

Comment on Rails 2.0 and the Future of Typo by Piers Cawley

Fri, 21 Dec 2007 12:44:47 -0600

For the basic article display, you’re absolutely correct, and the aim of the game is to have a situation where the blog is mostly flat files in a directory structure that reflects the blog. Where I’m talking about using Javascript is in sidebars. Several of our currently sidebar plugins are dynamic and can’t be cached – when these are rendered within the page proper, it means that we can’t cache the page – no fun at all. If we limit sidebars to static text and force them to use javascript to fetch dynamic content we can continue to do page caching of the main content, but sidebars can be more dynamic by making AJAX requests.

I also plan to try and nail down the HTML as much as possible, at least for the vital elements of each page like the articles or comments with the aim of implementing chunks of the administration interface as ‘direct manipulation’ javascript, inspired by things like Seaside’s halos. So, an admin user would see handles on things like articles and use ‘click to edit’ semantics to modify anything, writing changes back to the server using APP semantics. There would still be an admin console, if only for batch work, but for ‘quick’ changes, I’m rather keen on a HUD/WYSIWYG model.

The other client side processing I’m thinking about is spam processing. If we add an arbitrary ‘state’ field, controlled by the client through APP, we can write a client that consumes the /feedback.atom?state=pending feed, does spam classification and writes them back to the collection with a state of presumed_ham or presumed_spam, it becomes relatively easy to write different clients for different spam protection strategies, something which has proved problematic with the current typo implementation, where spam protection measures can tie the server process up for embarrassing amounts of time.