This project has moved and is read-only. For the latest updates, please go here.

New year intentions - request for comment

Jan 6, 2011 at 12:52 AM
Edited Jan 8, 2011 at 6:11 PM

Happy new year to everyone!

I just commited the first post CTP2 corrections and improvements. I'm reading the Csla 4 books. A lot of concepts get clear and some ideas for CGF improvements take form. Let me make a clear statement concerning the last buzz word of NET developement: I like Silverlight, I think Silverlight 4 is at last a serious proposition but I don't intend to drop support of other UI technologies like WindowsForms or WPF. So the path is clear and leads to a code generator that is capable of generate three different breeds of code:

  • no Silverlight support at all
  • Silverlight only
  • dual mode, Silverlight or no Silverlight according to compiler directives

This intention is clear on the latest Work Items you can find under the Issue Tracker tab. I grab this opportunity to say that I like to communicate to the users using the Issue tracker.

You may know Jonny Bekkum from Norway was deeply involved in Csla 4 release. It looks like things are getting back to normal and Jonny - that is also CSLA.NET Contrib ( coordinator released in late December a version 4 of parts of CslaContrib library including some business and validation rules. It happens that this goes according to my plans as I think CslaGenFork shouldn't generate rules but should use rules from a library,

Under the new rule system, rules are no longer methods of business objects but must be classes on their own. This means we have a very flexible system that almost forces reusable rules. So it's not possible to use the old rules inside BOs. The new problem is that developers "could" use a library of rules. My plans for CGF is that allow the use of rule classes from the following sources:

  • CSLA.NET CommonRules
  • rule classes defined in the same project
  • rule classes on a DLL

The later case would be nicer to use if you could supply the DLL to CGF and let CGF find and list the available rules for you to choose with mouse clicks. But as those DLL must be .NET 4 DLL, CGF must migrate to VS 2010.

VS 2010 wasn't very stable when it was first released. Some coworkers experienced several crashes a day, high memory consumption, etc. I was complaining about two issues:
- Find & Replace panel got wider every time it was reopen
- context menu was forcing me to scroll it even when there was plenty of screen space above or below it

Microsoft released fixes to those issues as well as fixes for a lot of other problems. Now VS2010 SP1 Beta is out. I don't really need it as VS2010 is much more usable, now that I applied the fixes for the two problems above. So I'm planning to move CslaGenFork to VS 2010 and fulfil the import rules from DLL requirement as well as the allow business object to inherit from CSLA.NET 4 BO. requirement. The thing is CSLA.NET 4 is .NET 4 only and programs compiled for previous versions of the framework can't read .NET 4 DLLs.

I can keep a VS2008 solution file in the project for as long as it doesn't clash with .NET 4 features. But I don't have the time resources to maintain a buildable VS2008 solution beyond that point.


Tiago Freitas Leal

Jan 22, 2011 at 9:50 AM

Happy new year Tiago!

I believe that CSLA for Silverlight code generation will become really popular. Especially as sliverlight gains ground. The part where we could choose rules from a list of rules is really exciting. Especially when we get to use our own library. Really cool stuff for a generator.

Mar 7, 2011 at 2:34 PM

Would be nice to see a standard rule set DLL - I found that the rules shipped with CSLA (Required/MinValue etc) are limited in that you can only provide your own resource strings for the messages. From a user interface perspective I would rather have a default, but the option to supply my own message for the rule depending on the context of the rule (e.g. you may want it to say 'Please ensure that you have filled xxxx field' rather than 'xxxx is required', especially since you might not want to show the field name or even the friendly name for the field

Mar 9, 2011 at 12:09 AM

I agree. Please see this post in Csla forum and my answer.