Tag Archives: Cuyahoga

Cuyahoga 2.0 revisited

There is a new Alpha version of Cuyahoga 2! Read the official announcement here.

image

Cuyahoga 2.0 Alpha released

Just a little post to let you know that I released the first Alpha of the next generation of the Cuyahoga CMS yesterday. For the people who don’t know Cuyahoga: it’s a .NET CMS that uses lots of Open Source components like NHibernate, Castle Windsor and Lucene.NET. Although not as polished as Umbraco or Dotnetnuke, I think it still shines when doing custom module and template development.

Development has been a long journey. Already back in 2006 we started development for the 2.0 version. In that time most of the work was done by Max Gaerber. He did a fantastic job in the design of the generic handling of content items.

Then somewhere in 2007 we started the new admin with Castle Monorail, did a spike with the first ASP.NET MVC, changed back to Monorail and finally changed to ASP.NET MVC again. The switch from ASP.NET WebForms to MVC for the site admin allowed us to do some pretty advanced AJAX stuff. The result is still a little rough around the edges, but it’s usable for experimental purposes.

Download it at http://sourceforge.net/projects/cuyahoga/files/.

New adventures under medium trust

Many web hosting companies only allow ASP.NET applications to run under medium trust. This has been a major drawback for Cuyahoga because it required full trust (or better: some libraries require full trust). This has already caused some nasty surprises when people deployed their site to the host to find out it would not run.

Well, I can finally say that Cuyahoga 2.0 will work under medium trust!

Castle DynamicProxy

Last week, someone mentioned on the Castle users list that DynamicProxy was supposed to work under medium trust and this immediately triggered me. DynamicProxy had always been the key part that prevented Cuyahoga, NHibernate, and lots of other software from running under medium trust because it generates assemblies on the fly and that’s not allowed (at least pre-NET 2.0 SP1).

So, I checked out a fresh version of the Castle trunk, built it with AllowPartiallyTrustedCallers and copied the assemblies to Cuyahoga that was set to run under medium trust.
Unfortunately, still no luck. The dreaded SecurityException showed its yellow screen, but instead of giving up immediately, I took a deep breath and started digging the DynamicProxy sources. The solution was a simple one: DynamicProxy calls AssemblyBuilder.DefineDynamicModule and used the overload that generates debug symbols. Changing that to not generate the debug symbols anymore made it work under medium trust! I send a patch to the Castle guys and lets hope it can be incorporated. This allows NHibernate to run under medium trust without turning off lazy-load on class mappings or using a special proxy generator.

One caveat: the Castle trunk requires .NET 3.5, so we can’t fix it for the 1.6.x branch of Cuyahoga which is .NET 2.0.

Lucene.Net

Second, Lucene.Net didn’t work under medium trust and boy, that was easy to fix: a single call was made to a relative file path, which is not allowed. Changed that to use the full path and it worked. Submitted a patch and I hope they will accept it.

Cuyahoga

So, with the libraries working under medium trust, I was ready to roll, at least I thought so. It appeared however that Cuyahoga also did some nasty things that are not allowed under medium trust, such as requesting a HttpModule instance from the appdomain and some file access outside the application root. Fortunately these were easy fixes and now I have everything working just fine under medium trust.

I think, I’ll leave medium trust turned on in the development version to signal issues in an early state.

Useful Cuyahoga Modules – The Flash module

Last weeks, I’ve been working on a project that uses Cuyahoga as the CMS. For this occasion, I’ve (temporarily) turned from Cuyahoga framework developer to a Cuyahoga consumer. In this role I’ve learned to appreciate some contributed modules that I didn’t really know that well, but appeared to be very valuable.

Today, I’d like to pay some attention to the Flash module that comes with Cuyahoga 1.6.0. It allows to embed Flash content in your site, but it also gives you some nice extra’s:

  • Optionally add a text representation of the Flash content for search engines or users that don’t have Flash installed;
  • It uses swfobject.js for automatic plugin detection and prohibiting the nasty ‘Click to activate’ message in IE;
  • It allows adding Flash parameters and FlashVars per section.

With the last option, you can for example embed a Flash movie player (the .swf file) and then point it to a .flv movie via FlashVars. Even with the absence of a cool media module in Cuyahoga, you can still dynamically add media content to your site this way.

Very nice!

Validation in ASP.NET MVC – part 3: client-side validation with jquery validation

This is part 3 of a series of posts. See also:

In the first two parts, I showed how you can perform validation on the server side with Castle Validation attributes and extend that model with custom validation logic. With this, we have everything we need to properly validate our model.

For a better user experience though, it would also be nice that we could re-use (part of) our validation logic on the client-side. Luckily, lots of others have already looked into this and the only thing I had to do was to throw everything together and stir it a little bit :) .

The ingredients are:

How it works

client-side-validation-1

  1. The client-side validation is called via an HtmlHelper extension method ClientSideValidation:
    <%= Html.ClientSideValidation(ViewData.Model, “my_form_id”)%>;
  2. The HtmlHelper extension requests an instance of a BrowserValidationEngine that returns the client script for validation;
  3. BrowserValidationEngine has a reference to an IValidatorRegistry instance that returns all (Castle) validators for the given model;
  4. For each validator, the referenced IBrowserValidatorProvider generates the appropriate client script;
  5. Finally, all generated client script code is combined and sent to the browser in a single javascript block.

The existing Monorail codebase proved to be of great value and could be used almost seamlessly. The only difference is the way the client code is generated. Originally, the validators generated css class attributes for the Monorail form helpers, but we don’t have those with ASP.NET MVC, so all client code is generated as jQuery validation rules.

Below, you can see the output of the validation helper for the new user form in Cuyahoga:

<script type="text/javascript">
$(document).ready(function() {
    jQuery.validator.addMethod('notEqualTo', function(value, element, param) { return value != jQuery(param).val(); }, 'Must not be equal to {0}.' );
    jQuery.validator.addMethod('greaterThan', function(value, element, param) { return ( IsNaN( value ) && IsNaN( jQuery(param).val() ) ) || ( value > jQuery(param).val() ); }, 'Must be greater than {0}.' );
    jQuery.validator.addMethod('lesserThan', function(value, element, param) { return ( IsNaN( value ) && IsNaN( jQuery(param).val() ) ) || ( value < jQuery(param).val() ); }, 'Must be lesser than {0}.' );
    jQuery.validator.addMethod('numberNative', function(value, element, param) { return this.optional(element) || /^-?(?:\d+|\d{1,3}(?:\.\d{3})+)(?:\,\d+)?$/.test(value); }, 'Not a valid number.' );
    jQuery.validator.addMethod('simpleDate', function(value, element, param) { return this.optional(element) || /^\d{1,2}\-\d{1,2}\-\d{4}$/.test(value); }, 'Not a valid date.' );
    $("#userform").validate({
        rules : {
            UserName: {  rangelength: [1, 50] , required: true },
            Password: {   required: true , rangelength: [5, 50] , equalTo: "#PasswordConfirmation" },
            PasswordConfirmation: {   equalTo: "#Password" , rangelength: [5, 50] , required: true },
            FirstName: { rangelength: [1, 100] },
            LastName: { rangelength: [1, 100] },
            Email: {   required: true , rangelength: [1, 100] , email: true },
            Website: { rangelength: [1, 100] }
        },
        messages : {
            UserName: {  rangelength: "The username must be between 1 and 50 characters" , required: "The username may not be empty" },
            Password: {   required: "The password may not be empty" , rangelength: "The password must contain at least 5 characters" , equalTo: "The password must be the same as the confirmation password" },
            PasswordConfirmation: {   equalTo: "The password must be the same as the confirmation password" , rangelength: "The password must contain at least 5 characters" , required: "The password confirmation may not be empty" },
            FirstName: { rangelength: "The firstname must be between 1 and 100 characters" },
            LastName: { rangelength: "The lastname must be between 1 and 100 characters" },
            Email: {   required: "E-mail address may not be empty" , rangelength: "E-mail address must be between 1 and 100 characters" , email: "Invalid e-mail address" },
            Website: { rangelength: "The website url must be between 1 and 100 characters" }
        }
    });
});
</script>

which results in this:

client-side-validation-2

Summarizing validation

In this series of posts, I showed how we deal with validation in Cuyahoga and ASP.NET MVC. Personally, I think the nicest part of it is that we have our validation rules centralized and we only have to add one line of code to the view to enable client-side validation.

The code can be found in Cuyahoga SVN and more specifically in the validation sections and the ASP.NET MVC manager. I’ll try to make a standalone sample project with all the validation stuff somewhere in the near future.