I really enjoyed talking about Developing Ajax web applications with Castle Monorail yesterday at Skills Matter. It was great to see so many familiar faces — thanks for coming again and I hope that you enjoyed it as well. Here are the downloads and links that Dave and I promised to put online:
Downloads
- PPT slides
- Source code for the SuperPowers app (drag & drop, scriptaculous and prototype effects demo)
- Source code for the JSonDemo app (comparing the three options for ajax with monorail; requires castle trunk DLLs)
Links with more details on the stuff from our talk
- Hammett’s post about Generating JS commands from actions (option #1 from the PPT). For all available functions in $page helper, see the source code of PrototypeGenerator.cs and PrototypeElementGenerator.cs classes.
- Hammett’s post on JSON return binders (option #3 from the PPT)
- Video , links and slides from my earlier talk on agile web development with Castle and Monorail
- Castle-related articles on this web site including the demo app that explains how to develop monorail controllers and how to unit test them.
Some general links
- Monorail web site
- Hammett’s blog and Ayende’s blog are excellent resources for all stuff about Castle.
- Prototype JS library docs
- Scriptaculous JS library docs
|
|
Hi Gojko
Thanks for the talk – I found it really useful.
Maybe you remember me as somebody who asked a question about validation when developing Ajax applications. I wasn’t actually asking about client-side validation. For me, client-side validation is just a bit of sugar. The server-side is more important. What I am concerned about is how to keep the validation models DRY on the server side while developing applications in MonoRail that involve both normal form submissions (for example, to submit a form to create a new expense) and AJAX form submissions (for example, to edit the date of that expense, later). If databinding is used with each, you need two separate transport models for these two submissions, because you don’t want the validators of the whole form to be executed when you are just editing one field. So there is some repetition and the validation is no longer DRY. And every new AJAX action needs another transport model decorated with validation attributes.
I think RoR tries to solve this by specifying which controllers/actions a validator runs on, so you can reuse the original transport model but ‘turn off’ validators as necessary. Do you know if MonoRail tries to solve it?
It’s not a terrible thing if it can’t be solved – it just means I’ll have to use my copy and paste magic a bit more.
Anyway thanks again and I hope to see you at another talk!
Thanks
Danyal
Hi Danyal,
I’m not sure that I understand what you are getting at. Format validation is fairly cheap, so there is little harm in validating the whole object every time (and that will also make sure that any inter-field dependencies are validated as well). Having said that, if you use castle component validations, and you know which field you want to validate, then you can get the validation attribute on that actual property and execute the validation yourself.
See the source code for ValidationRunner.cs — that should help you with validating individual properties.
I enjoyed the slides. Can you tell me where the video is as the one at http://skillsmatter.com/podcast/open-source-dot-net/developing-ajax-web-applications-with-castle-monorail never plays?
Thanks.
Hi Rodney,
you can see the video also here: http://video.google.com/videoplay?docid=-383418991140556188