CslaGenFork 4.0 FAQ

General Interest

Why should I use a code generator?
You will find the answer here.

Why does CslaGenFork use GPL 2? Does it mean I must license the generated code as GPL?
CslaGenFork (CGF) uses version 2 because on Codeplex you can't use version 3. CGF use GPL because, just because it's an inheritance of the original developers of CslaGen. No matter the license of the code generator, the code you generate is your code and "you can license the generated code and generated stored procedures at your discretion". This is a legally binding statement meaning in plain english that you can do whatever you want with generated code.

As you can imagine, no member of the team eat or pay the house mortgage with CGF project revenues. But every member of the team needs to sell some programs to a few clients and this means closed source programs. GPL doesn't allow for re-use on closed source projects so GPL is out of the professional market.

GPL was all about an idyllic idea (John Lennon's Imagine lyrics springs to the mind) but you can't make a profession of using it. GPL is good only to do other GPL. The CGF team doesn't mind other people using the generated code to make money and neither can nor wishes to restrict the use of the generated code in any way.

How does the CGF handles Issue Tracker status?
Some definitions:
  • Issue - Most of the times, it's a defect. Generally speaking, it refers to an incorrect behaviour of the application that must be fixed. Sometimes it can be difficult to distinguish an issue from a feature as it all goes down to how one see's "correctness". If I use something in a given way and the program is generating code that forces me to do it another way, I will say this is an issue while the developer will tell me that other people need it the way it is and opens a feature to allow the behaviour to be configurable.
  • Feature - Some behaviour or use case the program doesn't support and that will widen the universe of things it can do or where it can be used.
  • Task - Something that needs to be done that isn't either an issue or a feature. Usually it's internal to the project, like restyling/refactoring the code or use a different component (read DLL). Although it shouldn't create issues, shit happens...
  • Proposed - Anyone signed in Codeplex can propose. It's up to the team to close down (reject) or change it to Active.
  • Active - Some member of the team is handling it but it isn't ready yet.
  • Fixed - The issue is solved or the feature is ready but it hasn't been published in the Source Control yet.
  • Closed - Fixed issues and feature are changed to Closed after publishing. Now you can SVN Update and get all the good stuff.

How should I go about code generating?
Have a look at the starters HOWTO

Can we load CslaGen projects in CslaGenFork?
Yes we can. But we can't do the other way around, We can't load CslaGenFork project files in plain CslaGen because there are a lot of new options and the XmlSerializer can't figure out what to do with them.

How will CslaGenFork handle the legacy issue?
Support the CSLA.NET 1.0 is already discontinued. I don't know if those templates run and I won't take time to test them.
I took some time to run 2.0 and 3.5 templates because I need them in order to compare the code they generated with the code generated by 4.0 templates. I think most old time CslaGen users will want to do the same thing.
Quite honestly, I plan to discontinue legacy support as soon as the stable version is out. After that the "Target Framework" combo box in the "Generation" tab of the "Project Properties" panel will go away and CslaGenFork will only generate code for CSLA.NET 4.0.
Why is that schedule? If the stable version is out, it means the product is stable and generates good code. So there is no need to compare it with code generated by older versions.
Why that radical decision? For three reasons:
  1. On one hand, if people want/need to generate/re-generate code for previous versions of CSLA, they can continue to use CslaGen. Anyway the interesting features of CslaGenFork are useful only if you have updated templates and they only exist for CSLA.NET 4.0. So you don't need CslaGenFork to generate code for older CSLA versions.
  2. On the other hand, keeping up the retro compatibility takes time that would otherwise be spent on new features. So instead of loosing time to test old templates and fix some problems, I'd rather do some new and very useful features and improvements like:
    1. Write more unit tests and functional test cases (to make sure eveything runs as it should)
    2. "Folderize" the project panel using the object namespace (make it easier to work in large projects with dozens of objects)
    3. Validate project before code generation (and avoid those un-informative compile time errors)
    4. Find/develop an alternative to CodeSmith DLL (and install on one single step)
    5. Support for separate DAL files on a separate project (make it easier to use a different SQL database provider)
    6. Support for parametrized queries instead of Stored Procedures
    7. Extend DBSchemaInfo to support other SQL database providers
  3. The support for legacy templates (CSLA.NET 1.0) means we have to keep hidden properties in the XML file format. Of course one could find a workaround, keep the compatibility and save on project load time. Of course this also means almost dead code.


This and that feature aren't working...
Most advanced features of CslaGenFork will only work if you are using C# code generation and target CSLA40. There won't be back porting of new features to legacy CSLA versions.

What's this FKConstraint thing?
Short answer: don't use it for now.
Long answer: This is supposed to help CslaGenFork figure out how to get that ValueProperty from the database. Most of the time you don't need it but sometimes it can be quite helpful. I won't present any of these usefulness scenarios at this time. I've done this some 2 years ago in my personal fork of an older version of CslaGen. Unfortunately I changed the XML too much and it's not straightforward to open those projects in CslaGenFork. I must find some time to do it so I can test this feature.

How do the Loading Scheme and Lazy Load options work?
Please refer to this discussion (read up to the end).
In a nutshell, these options specify where and when the child data is fetched. A "child" can be a collection or an object. There are three modes:
  • ParentLoad (must use LazyLoad=False) use this by default - a single stored procedure takes care of fetching parent and child data.
    • Note - Child data is fetched on parent instantiation.
  • SelfLoad and LazyLoad=False - use this when
    • the parent and child are in different databases and can't be fected by the same stored procedure that fetches the parent data or
    • the parent and the child use different LoadParameters (Example: parent "Inbox" uses current UserID and child "SentMessages" use SenderID; I only get messages where SenderID = UserID)
    • Note - Child data is also fetched on parent instantiation, although the end result might take longer than using ParentLoad.
  • SelfLoad and LazyLoad=True (aka LazyLoad) - use it when you want to defer the loading of child data until it is referenced (until the user clicks somewhere).
    • This may improve user experience since child load time doesn't impose a penalty on the initial loading time. This is specially true if the parent has several child collections and each of them is quite large. Loading all of them at the same time would take very long while defering the load and handling each one separately would be fast enough to be acceptable to the user.
    • Note - The different databases or LoadParameters for parent and child scenarios are also handled nicely.

LazyLoad option seems to generate no working code... BTW neither does SelfLoad!
Suppose you have this use case:
1) EditableRoot => 2) EditableChildCollection => 3) EditableChild

Usually you specify the "get" criteria on 1)
In fact, as per p. 281 of the VS2008 book, you need a DataPortal_Fetch() on 2).
So you must specify a get criteria on 2) also. On that criteria you must set the criteria property to the EditableChild ValueProperty that loads the EditableChildCollection (usually it matches the PK of the root object). Note this also applies for SelfLoad Loading Scheme.

What is the Object Relations Builder? What do I use it for? How do I use it?
Let's take just the N to N relation use case.
Suppose you have a PermissiveSociety application with BOY objects and GIRL objects. As the application name suggests, every BOY can have relations with any number of GIRL and likewise any GIRL can have relations with any number of BOY. In your database you need:
  • Boys table with a BoyID Primary Key
  • Girls table with a GirlID Primary Key
  • Couples table with a Primary Key composed of a Foreign Key reference to both Boys.BoyID and Girl.GirlID. Sometimes this "couple" entity is called the associative entity.
In CslaGenFork you should:
  1. Go to Schema panel
  2. Go to Schema Objects sub-panel
  3. Right click on Boys table, select "Create Editable Root". Now edit it renaming the object to Boy
  4. Repeat for Girls table, renaming it to Girl
  5. Go to CslaGen Project panel
  6. On Csla Objects sub-panel select both objects (click Boy, press Control and click Girl)
  7. Right click and select the "Add a new object relation" option. You can see that the Schema is out of the way and the Object Relations Builder panel is showing, open on the tab N to N Relations with "BoyGirl" selected.
  8. Click on the single black arrow to validate and build your new relation, accepting to add the suggested properties.

Fig. 7. Right click and select the "Add a new object relation" option

Fig. 8. Click on the single black arrow to validate and build your new relation,

CslaGenFork builds four objects:
  1. BoyGirlColl - EditableChildCollection with items BoyGirl
  2. BoyGirl - EditableChild
  3. GirlBoyColl - EditableChildCollection with items GirlBoy
  4. GirlBoy - EditableChild
To follow up what CslaGenFork did,
  1. Go to the Boy object and click on the Child Collection Properties
    1. You can see that there is a property named Girls of type BoyGirlColl
    2. Before closing this window, take a look at section 05. Options.
  2. Go to objects BoyGirlColl and BoyGirl and have a look at Csla Object Info panel:
    1. section 04. Child Object Options
    2. section 05. Collection Options
  3. Compare with options in the Object Relation Builder section 03. Primary Entity Options.

On the Girl object you can see the exact same thing, but as a mirror image. In the Object Relation Builder you should look at section 05. Secondary Entity Options.

Note all these objects are codegen ready. Just press F5 and have a look at the generated code. Notice also the class documentation.

Update - 2010-12-08

Last edited Mar 7, 2013 at 8:43 PM by tiago, version 67


No comments yet.