Technologist Timothy Perrett rambling about technology

So here we are. The end finally happened. Lift in Action was sent to print last week, representing the conclusion of 20 months of work. Without doubt this has been one of the largest and most difficult projects i’ve ever undertaken. With this in mind I wanted to thank everyone who read the MEAP edition, contributed fixes, asked questions, issued pull requests and everyone who generally helped me with the project! Without your input the book wouldn’t be what it is, and I hope that it serves to be a useful reference for learning and making the most of Lift.

The print copies should be coming out in a week or so and depending where you purchased, your copy should be arriving in the coming weeks.

Thanks again for all the support and kind words during the writing; i’m now looking forward to getting my life back!

If you want to run SproutCore from within your Lift application there are a couple of configurations you need to ensure you apply within your Boot.scala in order to actually make it work as you might anticipate.

Firstly you need to ensure you set the HTML parser to use HTML5 and not XHTML, otherwise your templates will explode in extraordinary fashion when using the built template file as created by SproutCore build tools:

LiftRules.htmlProperties.default.set((r: Req) => 
  new Html5Properties(r.userAgent))

With that in place you need to do the equivalent of implementing a symlink for those setups that use the filesystem (a la PHP, Rails etc). Within Lift this is accomplished by using a stateless rewrite:

LiftRules.statelessRewrite.append {
  case RewriteRequest(ParsePath("index" :: Nil, "", true, false),_,_) => {
       RewriteResponse("static" :: "todos" :: "en" :: "1.0" :: "index" :: Nil)
  }
}

This code tells Lift to rewrite the root path (/) to /static/todos/en//index template. Also be sure to implement your SiteMap so that only / is accessible and not the full (direct) SproutCore template path. If I do much more stuff with SproutCore I may well end up making an SBT plugin that automatically builds the updated JS files and copies them to your src/main/webapp path… not sure yet, we’ll see. Eitherway, the rewriting is certainly a good candidate for stuffing into a LocParam and making it reusable based upon some project configuration. For example:

Menu("Home") / "index" << UsesSproutCore 

For more information like this checkout my book on Lift launching this quarter on Manning Publications.

Yesterday Jorge Ortiz invited me to join the team at scala-blogs.org – obviously I was delighted, and now I will be sharing my adventures in scala both through this blog, and on scala-blogs.

For my first article I’ll be writing about the PayPal integration I created with David Pollak for Lift.

Watch this space boys and girls, and dont forget to check out scala-blogs.org

I just came across this on DIGG. I wouldn’t usually blog about this type of thing, but its truly amazing… can you imagine if they massed produced these one day – we might be flying to work!

This is just a quick note; my apologies for the lack of posting lately – its not that I haven’t had anything to write about, quite the opposite… but right now im preparing for a server upgrade and I have already ported the blog data, so yes, Im being a bit lazy, but we should be all ported to the new servers in a couple of weeks.

So bear with me guys, Cheers

Whilst at Drupa I was lucky enough to get a back room showing of what Creo will be releasing in Q4 of 2008 and into 2009.

The first impressions are really great – the native UI (Cocoa on OSX and .NET windowing on WinTel) means that no matter what your platform you get widgets that you are familiar with and work seamlessly with the operating system. That really is quite a differentiator when compared to competing products, and one that I am sure a lot of people would welcome as even from personal experience, quite a number of other solutions are using SWNG, or, god forbid, AWT in Java which are clunky and just not up to the modern users expectations.

Plugins

One of the things that really is very good about Darwin is the plugin system they have devised. Whilst I currently have no information on what inner complexities one might face with implementing your own plugin, the architecture I was shown looked very open, and very friendly – which is a massive plus point in my eyes.

Performance

Darwin was awesomely quick too – speed and beauty in the same package! Eliot Harper has blogged some very nice performance testing between XMPie uDirect and Creo Darwin which can be found here

Integration

Creo have changed the way in which the Darwin working environment is persisted – its now a separate DVJ file. This means that when working with InSite, the system can automagically create the darwin files for you. I’d go out on a limb and say that if InSite is able to create those files, then any other system you might want to write would also be able to generate DVJ files – this could really create some interesting options for mash-up style workflows!

What About The Cons?

Ok, so all products have there cons – thats life – at the moment Darwin only supports flat file data-sources. Perhaps that will change over time, but we’ll see I guess. Release is quite some time off so who knows what those guys might come up with!

Kudos Creo , this really is great work.

Another interesting article about Darwin and InSite can be found here

This post is a bit off of the usual code focused articles I write, but having just arrived back from Drupa I feel that I just need to write a quick post about this as I really did think it was awesome!

The product in question is 3D Systems ProJet

No word of a lie, this machine can “print” 3D models of things via an InkJet process – it really is amazing the fine, granular control they have over how it works its magic. Like I said, very off topic, but freaking awesome at the same time!!

Of late ive been doing some investigation into extending InDesign with plugins and such. Traditional Adobe plugins needed to be written in C++ but now with the addition of the CS3 SDK its possible to write JSXB‘s from which you can extend the UI and all sorts of other good stuff!

I’ve been playing around with it, and true, its not as quick as C++, but its so much vastly more accessible the trade off does not seem like a major crime. If you want to try it for yourself, check out the SDK here