• Microsoft LightSwitch – Customizing a Data Entity using the Designer

    Posted Aug 24th, 2010 By in LightSwitch With| 1 Comment | Microsoft LightSwitch – Customizing a Data Entity using the Designer
    Share on TwitterSubmit to StumbleUponSave on DeliciousDigg ThisSubmit to reddit

    In my last post I created a really simple application that I can use to keep track of some simple customer information. I created a simple entity named Customers, and then created a couple of screens that allow me to manage the entities I create. What I’ll do next is take a closer look at this Customers entity, and see what can be done to it to better meet my needs.

    This post is specifically about the “entity”, not the fields within the entity (yet). I want to first understand what I can do with the designer in the management of a single entity. Things like creating and editing the fields and their properties, as well as entity relationships, are all subjects for later posts. I don’t have enough time during my lunch hour to write an all inclusive post about that stuff, so I am going to create  smaller bite sized tidbits of information that you can print and read during your library break at work.

    The Entity

    My Customers entity contains some pretty simple information. Not really much there, and probably not nearly enough for what I want to eventually accomplish. None the less, it’s a start and enough to get me going and start exploring.

    Here is a look at my Customers entity in LightSwitch

    The Customers Table

    The Customers Entity

    Since my last post I’ve had some time to think about my Customers entity. I was thinking that, hey, this entity I created is really supposed to represent a business entity, not a bunch of entities. As such, it is probably a better idea to name my entity in a way that represents a single entity instead of many. So I rename my entity to just Customer.

    One of the first things I notice is how LightSwitch automagically saw that I changed the name of my entity. In the Properties window of my (now renamed) Customer entity there is a property labeled Plural Name . Before I renamed the entity, this propery had a value of “CustomersSet”. When I changed the entity name to just “Customer”, LightSwitch saw this and automatically pluralized the name of the entity.

    When it comes to naming your entities (tables) it is a good idea to follow a consistent naming convention for all entities. Everyone likes to use a different convention when naming anything in an application; it’s really a matter of personal choice. Personally, I like to name a table as if it is a single entity. Others like to name it in its plural form. Some conventions even include one, or a combination of, different casings (upper and/or lower case characters). Whatever you think is going to work for you is ultimately the “right” way, so don’t think that you have to do exactly what someone else says is the “right” way – like when I BBQ!

    Just for kicks, I click the Start Debugging button. I want to see if changing the name of entity had any cascading effects to my application.

    Cool! The application fired up just fine and let me do the same add and edit customers without barfing.

    Properties

    Looking further further at the property window for my Customer entity, I see some other properties I can try messing with.

    Default Screen

    In the earlier post I created a screen showing a list of customers, and a screen allows me to edit customers. These are not to be confused with Search Data nor Details screens. Details screens are screens that I can create to use instead of the default detail screens that LightRoom might present. If I had created a Details Screen for my Customer entity, the Default Screen dropdown would contain an item for the detail screen I created. For example, If I double clicked a record in my CustomerList screen, and I had created a Details Screen and selected it from the detail screen drop down box, that screen would open instead of the default LightSwitch detail edit screen. For now, I am not going to create a default screen. I’ll let LightSwitch present one on the fly as I need it.

    Plural Name

    As mentioned before, the Plural Name property is the name that is pluralized representation of my entity. The plural name is editable, and can be customer to whatever you want. Just remember to use something that will make sense to you. Oh, and it can’t contain any spaces or special characters.

    Is Searchable

    The Is Searchable property tells LightSwitch whether or not the data will be searchable from a screen. This applies to both the list screens, and the search screens that LightSwitch creates. You can still create a screen from the Search Data Screen template, however the search box will only be visible if the Is Searchable property is selected.

    For example, here is my CustomerList screen with the Is Searchable property set to true on the Customer entity…

    Is Searchable property of entity set to TRUE

    Is Searchable property of entity set to TRUE

    … and the same screen where the search box is not there because the Is Searchable property is not checked…

    Is Searchable property of entity set to FALSE

    Is Searchable property of entity set to FALSE

    Name

    This is what I talked about before. This is the name of the business entity.

    Description

    This is a description of the screen. It may help you better understand the purpose of the screen should you end up with a whole lot of them. I am not really sure where else in LightSwitch this property value is used.

    Display Name

    This display name is what will show up on top of some of the screens that are created for your entity . The default display name is the same value you first entered in as the entity name. If you like, you can give it a different name that may make more sense that what may have been used for the entity name.

    Summary Property

    An entity might be made up of a lot of different fields. There is likely a field that could be used as a summary for the entity. In my case, the CustomerName is going to be the Summary Property. If not otherwise defined, the value of the field defined as the summary property will show up on the screen where there is a list involved. Running my application I see that the value of the CustomerName field appears in the list on the CustomerList screen.

    Conclusion

    That’s it. Not that difficult to understand is it?

    In my next post I am going to start playing with the properties if the fields themselves. This is where I am going to do some fun stuff like creating choice list for one of my fields.


    • delicious
    • digg
    • reddit

    Paul
    My name is Paul Patterson and I am a software developer who has a keen interest in technology, including; open source, .Net, and anything Interweb. When not crafting some code, I can be found learning something new about photography. As well, I occasionally escape to the "music room" with my guitars to practice a few scales and then jam with my favourite FM radio stations.

Leave a Reply


Comments (1)

© Copyright Paul S Patterson - Please, no touchie. :)