Default Values
The kind of default value most people are probably familiar with is a default value within the database, so if a particular field isn't included within an insert statement, it'll be defaulted to that value. Things get a little more interesting when using an ORM or data mapping solution as you need to inform the framework not to persist a null value to the field - either by listing the fields to persist or by listing the fields NOT to persist.
But there is another level of default. Sometimes you want to enter a helpful default value in an "add" form. Lets say that most pages are NOT secured (where PageSecured is a radio button with yes and no options). You could just leave the radio buttons unselected, and set the default in the db if the user doesn't enter anything, but it might be nicer to default the value in a new() page to PageSecured = false, so the "add" form displays the appropriate "no" radio checked and the user knows exactly what will happen if they don't change it.
So, one of the benefits of setting a default as an actual value of a new() object is that it makes it clearer to end users what will happen if they submit the form without changing the value.
The question is whether you ever want to post-set a default value. The two use cases are for properties where a null value was entered and for properties which weren't part of the form. Lets say that there is a simple addArticle form that allows you to enter just a title and some HTML content. It was decided to default the DisplayOrder for all such items to 100, providing a separate admin for managing the display order. In this case the DisplayOrder isn't part of the form, so it would want to be defaulted in the db or the SQL persistence layer to 100. If you had a field where someone could type in a DisplayOrder value (yeah, I know, a different UI would be better for handling display orders, but lets just go with the example for now), you could optionally set it to default to 100 in the form, allowing the user to change it if they wanted, or just leave it as null and set it to 100 after the user entered the form if they didn't enter anything.
So, what does that give us?
- Essential Default - If this property is not included in the list of properties being persisted, it will be set to this default value. Ideal for default values that have to be set but that you don't necessarily want to clutter up the UI with in all cases.
- Display Default - With a displayed default, if you get a new() object and call the getter on this property, this is the value that will be returned. It will not be persisted unless the property is one of the list of properties to persist for a given operation.
- Null Default - If this property is part of an insert/update and the value passed to this has a zero length, this default value will be persisted instead.
If the app is the only interface to the system, the first two options would appear to operate identically, but the second is more of a display concern whereas the other is more of a persistence concern so they have somewhat different use cases. The third is an alternative to some kind of validation for a field where a value is required, but where you don't necessarily need the user to enter the value. I have mixed feelings about this third type where you enter nothing but something is persisted in the database, but there have been times where a client has asked for something like this.
What do you think? Any other types of defaults? Could you simplify the list of default values? Anything here you don't think is a good idea? (if so, why?) Any better naming ideas?
Any input much appreciated on this one as I don't love what I've put together so far . . .
Some of the concepts here went a bit over my head, as I am just getting into this.... but I think one thing to consider is that not all default values can be persisted. Let me come at you from a procedural point of view:
Let's say we have a help Ticket that you need to enter. As part of the help ticket, you need to select a Type of problem (ie. General, Hosting, SQL, etc.) In my world, that is represented by a foreign key - (ex. 1 - General, 2 - SQL, 5 - Hosting).
Now, in my form, I might default the drop down of "Help Type" to zero and have the label be "- -" or "Select type of Problem". However, I might also want the drop down to be pre-selected to "General" and then have people select a more specific one if necessary.
Here, we have one object, Ticket, with a decision between two possible default values to make. Who's responsibility is that? Let's say the database and the domain model both default to zero. Does that mean my form has to default to zero? Or can I have put in logic to default to what what I - an User Experience architect- decides is most useful from a UX standpoint?
To me, this very concept makes the idea of using objects in a form seem incongruent with MVC and separation of concerns. An object should not be outputting data to a form, in my beginners opinion. To me, this very much feels like the responsibility of the FORM scope.
I am sorry if I am not making any sense and / or am totally getting off the point. As you know, I am very new to this stuff.
... that being said, I am confused as to why objects should worry about forms? Or objects to worry about persistence? Aren't these responsibilities divided up between different parts of the system?
Take for example, the idea of that Ticket from above; let's say I have a MSSQL data access layer thatn always stores the ticket_type_id (ex. 1 - General) as an integer where zero is the same as "unselected help type". Then, I have a MySQL data access layer that I can swap out that will only store NULL for "unselected type" and then 1+ for actual foreign keys.
Here, we have a data access layer that implements two fundamentally different types of storage. But, does that mean the domain model should change in any way? Should it's default values change depending on the way default values might happen in the database? I should like to say No.
One final thought - in OOP, should you ever have a value that is not set? If you are updating an object, and you don't persist every property, how can you be sure that you are not corrupting the data. What I am getting at is that I don't understand the concept of an "Essential Default". When would you ever have a property that is not being persisted?
Sorry for the stream of consciousness :)
I'd argue that the job of the UI is primarily to expose the model and provide a touch point for interacting with it. In most cases I'd argue that the appropriate default value for a given property of an object (which is what you are setting using a default value in the drop down) is indeed a model concern.
It depends what the form is, but typically a form displays the current state of an object (whether using defaults for a new object or existing values for an existing object). The form scope is simply a way for a user to pass information to the app and I tend to avoid explicitly using the form scope in my views except in smaller projects.
Business objects shouldn't worry about forms, if by a form you mean the HTML input fields displayed on the screen. However, if you look at a form as a way of displaying/populating an object it makes perfect sense for the values of the fields to be populated like <input type="text" name="FirstName" value="#User.getFirstName()#" />.
As for objects worrying about persistence, I'm trying to come up with metadata to describe the model, so while I'd agree that you wouldn't (for example) explicitly out database defaults into a business object, it makes practical sense for the same metadata that you use to generate business objects to also generate your db schemas and that is where a database default value would come in.
As for the idea of storing two different values for two different db servers, if that was the model you'd have to have a set of persistence rules that was db specific. However I'd argue that wouldn't be a good design choice. Unless I have to I'm trying to describe my applications in as technology agnostic a manner as I can do, so while the actual SQL generated for each db might be different, I'd want to just describe my intent for the db layer in one way and then just use different mappings to transform that into the appropriate SQL for a given platform.
In OOP you run into values not being set all the time. Think about a User object. I sign up for a newsletter, I have an email, first name and last name, but not a password or an address. I sign up for a printed catalog, I have an address but maybe not an email or password, and so on. Often objects have different states or roles or implement different sets of interfaces over their lifecycles, so there are definitely times where a property is not manually set.
Or think about the following. E-commerce admin. We have a full product admin with 20 fields, but we have a quick add allowing you to enter title, price and sku for 20 products at a time. What is the value of the short description or description or display order or Image or ThumbnailImage or Weight or whatever for those products we quick added? That'd be another example where you might add an object that doesn't have user input for all of the possible fields.
I am not sure that I follow you on the eCommerce example. Are you saying that your Product object would not have any values for things like Description and Short Description? You wouldn't even default to empty string?
In a ColdFusion world where we do not have NULL values, but rather empty strings, or hacked nulls, I assume that they only way to not have a value would be to not have in the actual instance variables.
Meaning, in your User example, one user might not even have the instance key for "Password", while another might,? I am very new to OOP, so in my head, I would do the same thing that my procedural world would do:
User with login:
variables.instance.username = "ben";
variables.instance.password = "booya";
variables.instance.email = "";
User with newsletter subscription:
variables.instance.username = "";
variables.instance.password = "";
variables.instance.email = "foo@bar.com";
In both cases, they user has all the same values (since ColdFusion does not have NULL, i just use empty string to denote default value). Then, when I persisted these, I would persist all fields, not just the fields that would be set.
But, from what it sounds like you are saying, you don't actually have the property fields for non-used values?? Do you do a StructDelete() for something like that?
Making any more sense?
How do you keep track of which properties have been updated? Do you have some sort of "Dirty" bit that you store for each property?
I understand the point that you might have a different View for quickly adding items. However, from the model point of view, it doesn't care about the interface; as such, how do you keep track of the properties that have been updated in such a way that only those values are persisted?
Going back to your quick product add screen, let's say you had someone just entering Name and Description. But, let's say that products also have a SKU value (not entered in the quick-add screen). How do you keep track of the properties such that your eventual SQL statement inserts the Name and Description, but NOT the SKU value?
Ahhh, i see. So let me ask you this question - If you defaulted values in your Object and then persisted your entire object, wouldn't that negate the need to have any default values in the database?
At least then, all of your default values would be centralized, rather than spread across three tiers?
What I'm more focused on right now is coming up with the best conceptual distinctions for the model (not as in mvc model but as in model driven development model) so I can describe my requirements efficiently. Choosing an implementation strategy from there (what code to generate and where) is less important and more eaisly changed.
Then maybe I am just not understanding the question. I only think of defaults as either in the DB, via a CFParam tag (as in the FORM), or as part of a CFC pseudo-constructor. I am not sure how else to look at defaults?
Defaults can be looked at as a requirements level. The goal of this posting is to distinguish different types of defaults so that if someone says "I want field x to default to y" I can clarify whether it should default the value in forms, whether it should default the value in displays if it isn't set and/or whether it should put the default value into the database (which might be important if you had other systems calling against the same db or some kind of export mechanism). As long as I can describe the requirement, I can capture that and just change my code generator. I'm working up a series on cfgen over the next couple of days, so maybe that'll help . . .