I am just getting into EF. For the past 2 years I have been coding database code by hand and finally got fed up with it. I am having one issue when it comes to using enums with E.F. All my previously coded enums used display attributes so that when bound in xaml to a data form or any other control, would display friendly names instead of code names. EX display "Light Brown" instead of "LightBrown or light_brown" etc. All the enum designer allows is to set values and names. Is there a way to get these auto enums to show a different name when bound to?
[Display(Name="Light Brown")]
Light_Brown,
Edit
I am not looking how to convert enum names into friendlier names. I already know how to do that. My issues is accessing the auto generated code for enumerations that are automatically generated using the entity framework designer. It seems there is a way to reference an external code file so I am going to look into this.
Found a question and answer here on stack. You can circumvent this issue by using the "Reference External Type" option in the designer. This is only a solution in the event you are using the database first design of Entity Framework and not the model first design.
Entity Framework 5 Enums with Description attribute using Database First
The author answered his own question under the comments of his question.
Try using
[Description("Light Brown")]
Light_Brown,
Check out this answer you might need to add a converter.
Related
Generating early bound entity classes for CRM Entities is fairly simple. Generating the Enums for the OptionSets is fairly simple as well. Generating the OptionSet Enum properties for entities that are typed to the correct Enum is not so simple, and not currently supported by the CrmSrvUtil.exe. If you want to be able to use the enums for populating the option set values, you have to continually write code that looks like this:
contact.Address1_AddressTypeCode = new OptionSetValue((int)contact_address1_addresstypecode.Home);
How do I generate Enum specific properties for OptionSetValues, so I can write code like this:
contact.Address1_AddressTypeCode = contact_address1_addresstypecode.Home;
and so Address1_AddressTypeCode's type is contact_address1_addresstypecode?
My previous answer sucked... Use the Early Bound Generator in the XrmToolBox Disclamer: I wrote it as well (the EBG, not the XTB).
I've created an Entity OptionSet Enum Mapper Utility to auto-generate Enum specific typed properties for early-bound entities. You can download both the source and executables here:
Programmatically Generating Properties for OptionSet Enums
It basically runs as part of a pre-build event during the build of your standard option set / enum dll, generating a .cs file that contains partial classes for any class that needs to have Enum properties generated for it.
I am new to SharePoint developement and have a few startup problems which I hope you will help me with.
I am trying to make a custom field type and I am using WPS builder to create the project. Right now I have the following files which are all compiling just fine :)
SuperLookup3.cs
SuperLookup3Control.cs
SuperLookup3FieldEditor.cs
SuperLookup3FieldEditor.ascx (controltemplate)
fldtypes_SuperLookup3.xml (XML)
I have tried look at this example but I just can't get it to work.
My questions
How is the relationsships between the files?
I can see an override of UpdateFieldValueInItem() which is setting the value to the selected item of a dropdown list. But this method is never called (when debugging). How can this be?
Some general advice would be to post this question to the SharePoint Stack Exchange site (if this answer is unsatisfactory), since there are a lot more SharePoint developers there.
From what I understand of that example, it seems to be quite a complex Custom Field Type to start with (given that it has multiple values). There's a good straightforward and pretty well explained tutorial on MSDN that you might want to try out: Walkthrough: Creating a Custom Field Type
Here's a brief explanation of your files (and the classes they contain):
This is the main class of your field, which derives from the SharePoint field base class (SPField). Your naming seems to indicate you're creating a lookup derivative; if so, you may wish to derived from SPFieldLookup.
This is the class the creates the form control displayed on a list item's New, Edit, and Display forms (but not the List View). It's a go-between for the forms and the item's value for this field.
&
This is the section displayed on the Add/Edit Column page. I would expect 3. to have the ending '.ascx.cs' instead of '.cs', since it is the code-behind for 4.; which may be the cause of your problem. This control sets up your field; associating the class in 1. to the list.
This is the field declaration. It says to SharePoint "Hey, I've created my own field; go look here to find it.", and directs SharePoint to the class in 1., which makes the field available on the Add Column page.
I am tacking a large refactor of a project, and I had asked this question to confirm/understand the direction I should go in and I think I got the answer that I wanted, which is not to throw away years worth of code. So, now begins the challenge of refactoring the code. I've been reading Martine Fowler and Martin Feathers' books, and they have a lot of insight, but I am looking for advice on the ultimate goal of where I want the application to be.
So to reiterate the application a little bit, its a dynamic forms system, with lots of validation logic and data logic between the fields. The main record that gets inserted is the set of form fields that is on the page. Another part of it is 'Actions' that you can do for a person. These 'Actions' can differ client by client, and there are hundreds of 'Actions'. There is also talk that we can somehow make an engine that can eventually take on other similar areas, where a 'person' can be something else (such as student, or employee). So I want to build something very de-coupled. We have one codebase, but different DBs for different clients. The set of form fields on the page are dynamic, but the DB is not - it is translated into the specific DB table via stored procs. So, the generic set of fields are sent to the stored proc and the stored proc then decides what to do with the fields (figure out which table it needs to go to). These tables in fact are pretty static, meaning that they are not really dynamic, and there is a certain structure to it.
What I'm struggling specifically is how to setup a good way to do the dynamic form control page. It seems majority of the logic will be in code on the UI/aspx.cs page, because its loading controls onto the webpage. Is there some way I can do this, so it is done in a streamlined fashion, so the aspx.cs page isn't 5000 lines long? I have a 'FORM' object, and one of the properties is its' 'FIELDS'. So this object is loaded up in the business layer and the Data layer, but now on the fron end, it has to loop through the FIELDS and output the controls onto the page. Also, someway to be able to control the placement would be useful, too - not sure how do get that into this model....
Also, from another point of view - how can I 'really' get this into an object-oriented-structure? Because technically, they can create forms of anything. And those form fields can represent any object. So, for example, today they can create a set of form fields, that represent a 'person' - tomorrow they can create a set of form fields that represent a 'furniture'. How can I possibly translate this to to a person or a furniture object (or should I even be trying to?). And I don't really have controls over the form fields, because they can create whatever....
Any thought process would be really helpful - thanks!
How can I possibly translate this to to a person or a furniture object
(or should I even be trying to?)
If I understand you correctly, you probably shouldn't try to convert these fields to specific objects since the nature of your application is so dynamic. If the stored procedures are capable of figuring out which combination of fields belongs to which tables, then great.
If you can change the DB schema, I would suggest coming up with something much more dynamic. Rather than have a single table for each type of dynamic object, I would create the following schema:
Object {
ID
Name
... (clientID, etc.) ...
}
Property {
ID
ObjectID
Name
DBType (int, string, object-id, etc.)
FormType ( textbox, checkbox, etc.)
[FormValidationRegex] <== optional, could be used by field controls
Value
}
If you can't change the database schema, you can still apply the following to the old system using the stored procedures and fixed tables:
Then when you read in a specific object from the database, you can loop through each of the properties and get the form type and simple add the appropriate generic form type to the page:
foreach(Property p in Object.Properties)
{
switch(p.FormType)
{
case FormType.CheckBox:
PageForm.AddField(new CheckboxFormField(p.Name, p.Value));
break;
case FormType.Email:
PageForm.AddField(new EmailFormField(p.Name, p.Value));
break;
case FormType.etc:
...
break;
}
}
Of course, I threw in a PageForm object, as well as CheckboxFormField and EmailFormField objects. The PageForm object could simply be a placeholder, and the CheckboxFormField and EmailFormField could be UserControls or ServerControls.
I would not recommend trying to control placement. Just list off each field one by one vertically. This is becoming more and more popular anyway, even with static forms who's layout can be controlled completely. Most signup forms, for example, follow this convention.
I hope that helps. If I understood your question wrong, or if you'd like further explanations, let me know.
Not sure I understand the question. But there's two toolboxes suitable for writing generic code. It's generics, and it's reflection - typically in combination.
I don't think I really understand what you're trying to do, but a method using relfection to identify all the properties of an object might look like this:
using System.Reflection;
(...)
public void VisitProperties(object subject)
{
Type subjectType = subject.GetType();
foreach (PropertyInfo info in subjectType.GetProperties()
{
object value = info.GetValue(subject, null);
Console.WriteLine("The name of the property is " + info.Name);
Console.WriteLine("The value is " + value.ToString());
}
}
You can also check out an entry on my blog where I discuss using attributes on objects in conjunction with reflection. It's actually discussing how this can be utilized to write generic UI. Not exactly what you want, but at least the same principles could be used.
http://codepatrol.wordpress.com/2011/08/19/129/
This means that you could create your own custom attributes, or use those that already exists within the .NET framework already, to describe your types. Attributes to specify rules for validation, field label, even field placement could be used.
public class Person
{
[FieldLabel("First name")]
[ValidationRules(Rules.NotEmpty | Rules.OnlyCharacters)]
[FormColumn(1)]
[FormRow(1)]
public string FirstName{get;set;}
[FieldLabel("Last name")]
[ValidationRules(Rules.NotEmpty | Rules.OnlyCharacters)]
[FormColumn(2)]
[FormRow(1)]
public string LastName{get;set;}
}
Then you'd use the method described in my blog to identify these attributes and take the apropriate action - e.g. placing them in the proper row, giving the correct label, and so forth. I won't propose how to solve these things, but at least reflection is a great and simple tool to get descriptive information about an unknown type.
I found xml invaluable for this same situation. You can build an object graph in your code to represent the form easily enough. This object graph can again be loaded/saved from a db easily.
You can turn your object graph into xml & use xslt to generate the html for display. You now also have the benefit of customising this transform for differnetn clients/versions/etc. I also store the xml in the database for performance & to give me a publish function.
You need some specific code to deal with the incoming data, as you're going to be accessing the raw request post. You need to validate the incoming data against what you think you was shown. That stops people spoofing/meddling with your forms.
I hope that all makes sense.
I'm not really sure what tags should be on this sort of question so feel free to give me some suggestions if you think some others are more suited.
I have a dynamic object with an unknown number or properties on it, it's from a sort of dynamic self describing data model that lets the user build the data model at runtime. However because all of the fields holding relevant information to the user are in dynamic properties, it's difficult to determine what should be the human readable identifier, so it's left up to the administrator. (Don't think it matters but this is an ASP.NET MVC3 Application). To help during debugging I had started decorating some classes with DebuggerDisplayAttribute to make it easier to debug. This allow me to do things like
[DebuggerDisplay(#"\{Description = {Description}}")]
public class Group
to get a better picture of what a specific instance of an object is. And this sort of setup would be perfect but I can't seem to find the implementation of this flexibility. This is especially useful on my dynamic objects because the string value of the DebuggerDisplayAttribute is resolved by the .NET framework and I have implementations of TryGetMember on my base object class to handle the dynamic aspect. But this only makes it easier for development. So I've added a field on what part of my object is still strongly typed and called it Title, and I'd like to let the administer set the implementation using their own format, so to speak. So for example they might build out a very simplistic rental tracking system to show rentals and they might specify a format string along the lines of
"{MovieTitle} (Due: {DueDate})"
I would like that when they save the record to add some logic to first update the Title property by resolving the format string to substitute each place holder with the value of the appropriate property on the dynamic object. So this might resolve to a title of
"Inception (Due: May 21, 2011)", or a more realistic scenario of a format string of
"{LastName}, {FirstName}"
I don't want the user to have to update the title of a record when they change the first name field or the last name field. I fully realize this will likely use reflection but I'm hoping some one out there can give me some pointers or even a working example to handle complex format strings that could be a mix if literal text and placeholders.
I've not had much luck looking for an implementation on the net that will do what I want since I'm not really sure what keywords would give me the most relevant search results?
You need two things:
1) A syntax for formatting strings
You have already described a syntax where variables are surrounded by bracers, and if you want to use that you need to build a parser that can parse that. Perhaps you also want to add ways to specify say a date or a number format.
2) Rules for resolving variables
If there is a single context object you can use reflection and match variable names to properties but if your object model is more complex you can add conventions for searching say a hierarchy of objects.
If you are planning to base your model objects on dynamic chances are that you will find the Clay library on CodePlex interesting.
I have a number of user permissions that are tested throughout my ASP.NET application. These permission values are referenced in an Enum so that I can conveniently test permissions like so:
btnCreate.Enabled = PermissionManager.TestPermission(Permission.AllowCreate);
However, I also have these permissions stored in the database because I need hold more info about them than just their Id. But this creates a horrible dependency between the enum values and those in the database, an ill considered change to either and I have problems throughout my application. Is there a better way around this issue? Has anyone dealt with this before?
I do not know what the best solution is, I would like to hear that.
Our solution is to explicitly type the enum like
public enum MyEnum : int
{
None =0,
Value = 1,
AnotherValue =2
}
And save the integer value to the database. When for instance the Value 1 is removed, you will still be able to use the enumeration and AnotherValue still has the value 2 in the database.
Or maybe store the enumvalues as string in the DB. ToString();
Using enum values is acceptable to do as long as you never change the already assigned values. If you were using the standard role-based authorization in .NET you would still be relying on the exisistence of certain text strings in the corresponding role table in the database.
We use a small application that generates enum code (example: NorthwindEnums.cs) from the database. We make sure to run it and update affected libraries whenever the database changes.
We also try to keep our enums starting at 0 and sequential to avoid issues with web service references in C#.
A while back I built a little tool to do this for my company that would use attributes on the enum fields to allow "synchronisation" with the table in the database.
The tool could scan an assembly and generate appropriate INSERT/UPDATE SQL commands that would sync the database with the enum definition in the code.
I add an extended property on any table that I will need to access in code as an enum. I then use code generation software (codesmith, T4, whatever) to generate all my enum's for me by looking up any table with this property. Any table that is to be used for this abides by some basic rules (must have a Name column, etc.) so the code generator knows which column to use as the name for the enum's elements.
Once values are added to those tables we take care to virtually never change them to avoid breaking the build.