Here's my second installment...=)

The object mapper is functional, but has left a lot of room for improvement:

1. Simple keyboard shortcuts would make a world of difference.

2. Option to specify default values for the null value support based on type. So if the mapper sees a string field, I can make it default to "return alternate on null" and an empty string.

3. Add custom/unbound fields to BOs

4. Add a checkbox to indicate the field is required. When checked, the field is added to the required fields collection

Howdy Kevin,



1. Yes, keyboard shortcuts would definitely be nice... and easy to implement.



2. Yes, we have this one on the books, as well as the ability to set a default specification for NULL support so you don't have to manually change each field separately.



3. Not sure, maybe I'm not thinking on the same lines as you, but you can create custom fields outside of the .designer.* file that are unbound. There's really no reason for us to do this in the BOMapper since you can easily do it in the main code file. We have a help topic on adding custom, bindable fields to a business object, and I believe there's another topic in the VB tutorial that goes over adding custom fields as well.



3a. Now, changing the names on fields is a completely different story, and is already on the list of enhancement requests (i.e.: you have a "Count" field in the database, and when the BOMapper creates the designer file, that Count field conflicts with the Count field already on the object).



4. This one would be slightly more difficult, and might not be worth the effort, since the required fields are managed through the Visual Studio code serialization mechanism rather than by us generating the code manually, but thanks for bringing it to our attention

3 (and 3a) I was actually thinking of a much broader picture when I was writing this and was going to elaborate with another point, but got distracted and forgot...

I was remembering how much I liked the editor in Deklarit. It's a dockable window that allows you to easily edit business objects right inside the IDE. This is nice because you can quickly go through each field in each object and modify properties, rules, relationships, etc without having to open the code window for each individual object.

If you did something like this, you could actaully combine the functionality of the DB designer (for the purpuse of creating strongly typed BO) and object mapper into one.

I realize this is a huge order which may not appeal to others...but it doesn't hurt to dream a little

4. I see your point here. I haven't had time to dig into how the BOs are created, so I assumed that each field had a set of properties, which included whether or not it was required...not realizing the BO simply had a collection of required fields.

You guys really have done an awesome job with SF. As you can probably tell by some of my questions, I am pretty new to the .NET way of thinking. I'm an old-school VB developer and SF has gone a long way to encapsulate many of the things I would have had to learn otherwise.

>> but it doesn't hurt to dream a little



That's right... you have not because you ask not, right



We're always looking for ways to improve the product, so, keep your opinions handy and let us know what you think.



Since the BOMapper is an AddIn rather than a separate application, it would allow us to create code windows within it that were part of the VB/C# vspackage file, thereby adding a code editor directly into the BOMapper, certainly not impossible, but to be honest, other requests have a higher priority.

While we're all dreaming, some things I would like to see added to Object Mapper are;

 

1. A ReadOnly check box and a drop down scope list for each field. While this can be done with custom code it would make life a lot easier, especially since you have to close object mapper before you can go back to your object and cut out another piece of code to paste into the custom code window.
    
2. A cut & paste context menu in the custom code window. 
   
3. This is not really an object mapper enhancement but it’s related to the custom field suggestion. You can write a custom fill method that allows you to join data from multiple tables. This is especially helpful when you want to display related information. The issue is that you cannot save the object. In order to save any changes you need to copy the data to another instance of the object that does not contain the added fields. It would be nice if Save only looked at the AllFieldsList instead of all columns in the data table. It may be that the new link class in version 1.4 addresses some cases where this feature would be desirable, but I still think it would make the framework more flexible.

-Larry

ooh..that reminds me of a couple other things. Making the object mapper window modeless would be helpful. There have been several times I needed to switch back and forth for one reason or another.

I would also like to see the custom type search window allow use for wildcards. I name all my enums EnumBlahValues. In the custom type window, it would be nice to just type "enum" and get a list of all my enums.

That we can do

Version 1.4 Rocks! I didn’t realize you guys had modified the framework to use the AllFieldsList instead of the column names when saving. I just happened to notice the change when I was looking at the source code. Now I can pull data from multiple tables for display and still save the object. That’s so much better than mucking around with multiple instances. Thanks!!!!!  The new debug option for the data layer is also a very useful addition.

 

On another subject, have you guys heard anything back from Infragistics on the legal aspects of adding a wrapper for their controls or do I need to drop an email to their sales department telling them I’m going to have to switch to Dev Express?

 

-Larry

 

 

No, we haven't heard anything from Infragistics on whether or not we can release a wrapper. We have, however, almost completed the DevExpress wrapper. Trent has all of the controls inherited, but I'm not sure how much more testing needs to be done before they can be released (shouldn't be much longer, because we're using them internally).



On the changes to 1.4... I almost forgot that you asked for that feature that we implemented; had I remembered, I would have pointed it out to you