This project has moved. For the latest updates, please go here.

A few suggestions

Mar 7, 2011 at 12:06 PM

Hi all,

CSLAGen/Fork is a useful tool, and for getting simple business objects working it's invaluable - however, there are a few things which I think could be improved upon

Missing features:

Implements/Attributes

No "implements/attributes" section for child collection and non-collection properties - I often use attributes to decorate my child properties for my CSLA projects as part of my assistant framework. I can't add attributes to properties and therefore I'm required to move the code from the .designer file so that my attributes don't get overwritten

Suggestions:

Change the way templates are generated to allow more control

I don't know how useful this would be to other people and it might be a good bit of work, but I was thinking that taking each discreet operation that a business object can perform and allowing a user to determine whether it is generated, which file it is generated to, etc - with a preview window showing the generated code - would be very useful.

This means that if a user wishes, they can move all of the dataportal code into one file, and put business properties and factory methods in another (useful for Silverlight where you need a separate server dll and a shared client/server dll). This also means that you could potentially split each particular method up into a separate codesmith template file, making the maintenance of the templates easier (yes there would be more files, but it would be infinitely more readable and maintainable when you only need to edit one file)

I think this would give so much control to the user

Make the Csla object pane a tree view

The object pane does not show the relationship between CSLA objects. I do realise that it's possible to have a child belong to multiple parents - in this case why not just show the object twice? A tree view would solve this issue, giving better visibility of the object graph. I know there has been some work on the object relations builder and this could also be taken into account in the tree view.

Allow multiple parents for children either by interface or by multi-parent dataportal methods

If this is already done by the object relation builder, then I apologise as I've not really got to grips with it yet.

Nobody likes creating multiple objects which do the same thing - take for example a 'notes' collection which takes two keys 'ID' and 'Area'. The best way I can get CSLAGenFork to represent my objects correctly is to add an interface as an object and then create my child 'notes' collection which has the interface as it's parent. It's a hack but it works. When this is done, all you need to do is add a new child collection property to your objects and make sure it's of the correct type (childnotecollection), and also make sure the object implements the interface.

 

I also have Silverlight versions of the CSLA 4 c# templates - they aren't 100% complete and there are a couple of minor issues - and they are messy when generated with lots of compiler directives but they mostly work. They also generate sync and async factory methods for Silverlight (using the default property loading for async new). Is it worth posting these or are there more complete ones in the pipeline?

 

Thanks,

Charleh

Coordinator
Mar 8, 2011 at 10:13 AM
Edited Mar 17, 2011 at 10:46 PM

Hi Charleh,

Great post. I'll try to address each issue but it can't be done on a single post.

1) Implement attributes - workitem scheduled to the next release

2) Make Csla object pane a treeview of object hierarchy

For a not so small project, the Csla object pane isn't very user friendly. Since I forked CslaGen I added shortcuts ([CTRL] up and down) to physicaly move objects in the list and implemented moving more than one object at a time. I was planning for an optional tree view centered around the namespace concern: each folder would be a namespace with the respective member objects as leaves. Your proposal is complimentary: at the first level show only the root objects, and show child, grand-child hierarchy as branches. It's a very good idea as it gives a clear view of the project structure. I think this should be the main view and the flat view approach would be kept as alternate view. This direction raises some issues and related features:

2.1) What about malformed project structure like parent and child on different namespaces?

CGF would start building the tree by the top: namespace => root => child => etc. A child on a namespace other than its parent namespace would show with an error mark.

2.2) Filterig isn't a problem on a namespace centered view (the one I was planning). When you go to an object hierarchy view, it's not useful to show only the matching objects and hide their hierarchy (up and down hierarchy). So the view should show the full hierarchy of any matching object.

2.3) Since we have a nice tree view and a mouse pointer, it would be really nice to have a feature like "add an object on this namespace" and even nicer to have a feature "add a child to this object".

The other issues will be answered in another post. I must go now.

Coordinator
Mar 8, 2011 at 10:15 AM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Mar 8, 2011 at 3:05 PM

Concerning the other points of your post

3) Allow multiple parents for children

Moved to its own thread.

4) Silverlight templates

I'm following Rocky's Using CSLA 4 ebook series and have postponed Silverlight support until I get the full picture with all the details. As far as I can see it, the UI technology question involves several issues:

BindingList vs ObservableCollection - WindowsForms vs all the other UI technologies

Synchronous vs Asynchronous methods - this issue might concern all UI technologies

Silverlight specific requisites - Silverlight specific asynchronous methods and public PropertyInfo

As a side note, the plan is to redo the whole template area in order to support generation of Encapsulated Invocation. CGF only supports Encapsulated Implementation and this is a bit short for serious projects where you wont a separate DAL in order to allow for mocking, using other DB servers, etc. Refer to http://cslagenfork.codeplex.com/discussions/244812 on this issue. I can add that a new question is whether to support DTOs.

Back to the Silverlight template issue, I think conditional compile directives might be "dirty" by usual C# standards but they work all right. You can see the code all in one place and make sure everything is all right for all UI platforms. It's becoming more and more common since Silverlight saw the light and I think they are here to stay.

5) Split the generated code on multiple files

As I said before, the template/code generation area is about to change a lot. This would be a good time to introduce this kind of changes. The point is I'm not so sure what should be changed and how. One of the features that is on the table is to allow a per object specification of methods that shouldn't be generated. This avoid colisions with custom implementations that might be included in custom partial class files.

The preview of generated code isn't easy to do as the generation process is far from simple. In fact you would have to actually generate the code in order to preview it, meaning in order to preview the code for a given object you would have to actually generate the code for that particular object.

As for the other changes, I would say that the changes needed for Silverlight support and Encapsulated Invocation support might be enough to solve most problems. If not, further changes will be needed. We'll see.