November 2003 - Posts
As I noted in a previous post I'm writing a simple content management system (CMS) to test out my Entity Framework, as well as to fill the need of one of my clients. One of the concepts which I've been putting some thought into recently is the best way to provide a templating system for the CMS.
I've seen a couple of different approaches that all use a very similar approach. dasBlog, nGallery, and a couple other applications define templates using html files with some kind of global variable tags defined within them.
dasBlog - {itemTitle}
nGallery - [$itemTitle$]
My initial implementation will likely be very similar. I have some thoughts regarding an advanced templating system that could be used by “power“ users. I was thinking of having the templating system be based on the in-line script syntax of ASP.NET. After the users entered a new script into the admin a page parser would be used to validate the template. Assuming the template “compiled“ the template would then be available for use. Essentially the template would be a dynamic assembly that a templated page would hand itself off to. I haven't done any of the ground work to see how feasible this is, but it *seems* doable. We shall see....
UPDATE: The templating and macro code in dasBlog looks pretty sweet. I think I'm going to have to dig through this code a little more...
Last week I wrote a post about some problems I was having entering a license for an unnamed product. In the comments for the post Eric Sink fessed up and admitted that the product was his very own Vault. I intentionally didn't say the name of the product because I didn't want my experiences to scare anyone away from buying Vault. Its a kick ass product (well it is just source control but none-the-less it rocks), if you haven't checked it out yet, do so.
Today I read Finance for Geeks, written by Eric. The article provides a “geek-oriented” overview of accounting, finance, and company funding. All I can say is Eric is awesome. He continually provides excellent articles on the “non-technical topics” that any geek with dreams of starting up his own ISV needs to know. He's got me ready to go tell my boss I'm taking off to start up my own ISV....hmmm...maybe I should figure out what software I'm going to develop first :-)
Last week we had an internal meeting to discuss the future for a class library that we've been using on all of our .NET projects. The class library is actually what spurred the creation of my personal Entity Framework. The library has a bunch of common utilities and functions as well as a set of base classes for business objects. We currently have about 5 sites/applications using the library.
Let me start by saying our current setup sucks.
- Within VSS we have a single source code tree that is organized like so:
- OurCompany
- *.Core
- all the source files here
When we start a new project we copy the latest version of the Core dll into a “ReferencedAssemblies“ folder within the new projects “project folder“ on the network (\\mynetwork\projects\NewProject\ReferencedAssemblies). Within VS.NET we add the core dll to the referenced assemblies by browsing to the ReferencedAssemblies project folder on the network. I'm sure your thinking, WHY?!?! Well I am too.
One of the first things we identified in our meeting was the need to redo our source control structure to better support new versions of the library as well as better sharing of release versions between projects. We currently don't have any problems with our setup because all our clients are using the same version of our class library (v1.0). When we begin working on the new version we'll need to have our source control tree better able to support it. We are planning on branching the current code base into a separate trunk. Any bugs identified in any of the current applications will be fixed in the v1.0 branch. All new development will occur within the main tree that will be moved into a v2.0 tree.
To start we're thinking of creating a set of version folders with VSS that looks something like this: (expanded out beyond what we currently need as an example)
- OurCompany
- v2.0
- src
- v2.0.0.32983
- bin
- Release
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- Debug
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- (All Source Code Here)
- v2.0.0.67384
- bin
- Release
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- Debug
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- (All Source Code Here)
- v1.0
- src
- v1.0.0.2993
- bin
- Release
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- Debug
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- (All Source Code Here)
- v1.0.0.3245
- bin
- Release
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- Debug
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- (All Source Code Here)
So if ProjectA uses v1.0.0.3245 we will share the $/OurCompany/Core/v1.0/src/v1.0.0.3245/bin/Release/Core.dll file to the $ProjectA/v1.0/lib folder. Then if a bug is identified in the v1.0.0.3245 version of the library we can update it once and have all projects dependent on that release automatically be updated when a new build (and thus get latest) is done for the project.
We still have the potential problem of project code relying on a bug within the component. So if ProjectA is written in a way to account for a bug in v1.0.0.3245 of the component, we may actually break the application by fixing the code. To handle this problem we'll probably have to have all kinds of other fun and exciting branches.
After thinking about all this I'm curious how others are handling it. What does your source control tree look like? What works for you? What doesn't? Please share your experiences in the comments for this post!
Last week we had an internal meeting to discuss the future for a class library that we've been using on all of our .NET projects. The class library is actually what spurred the creation of my personal Entity Framework. The library has a bunch of common utilities and functions as well as a set of base classes for business objects. We currently have about 5 sites/applications using the library.
Let me start by saying our current setup sucks.
- Within VSS we have a single source code tree that is organized like so:
- OurCompany
- *.Core
- all the source files here
When we start a new project we copy the latest version of the Core dll into a “ReferencedAssemblies“ folder within the new projects “project folder“ on the network (\\mynetwork\projects\NewProject\ReferencedAssemblies). Within VS.NET we add the core dll to the referenced assemblies by browsing to the ReferencedAssemblies project folder on the network. I'm sure your thinking, WHY?!?! Well I am too.
One of the first things we identified in our meeting was the need to redo our source control structure to better support new versions of the library as well as better sharing of release versions between projects. We currently don't have any problems with our setup because all our clients are using the same version of our class library (v1.0). When we begin working on the new version we'll need to have our source control tree better able to support it. We are planning on branching the current code base into a separate trunk. Any bugs identified in any of the current applications will be fixed in the v1.0 branch. All new development will occur within the main tree that will be moved into a v2.0 tree.
To start we're thinking of creating a set of version folders with VSS that looks something like this: (expanded out beyond what we currently need as an example)
- OurCompany
- v2.0
- src
- v2.0.0.32983
- bin
- Release
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- Debug
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- (All Source Code Here)
- v2.0.0.67384
- bin
- Release
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- Debug
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- (All Source Code Here)
- v1.0
- src
- v1.0.0.2993
- bin
- Release
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- Debug
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- (All Source Code Here)
- v1.0.0.3245
- bin
- Release
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- Debug
- *.Core.dll (shared to other projects)
- *.Core.xml (shared ?)
- (All Source Code Here)
So if ProjectA uses v1.0.0.3245 we will share the $/OurCompany/Core/v1.0/src/v1.0.0.3245/bin/Release/Core.dll file to the $ProjectA/v1.0/lib folder. Then if a bug is identified in the v1.0.0.3245 version of the library we can update it once and have all projects dependent on that release automatically be updated when a new build (and thus get latest) is done for the project.
We still have the potential problem of project code relying on a bug within the component. So if ProjectA is written in a way to account for a bug in v1.0.0.3245 of the component, we may actually break the application by fixing the code. To handle this problem we'll probably have to have all kinds of other fun and exciting branches.
After thinking about all this I'm curious how others are handling it. What does your source control tree look like? What works for you? What doesn't? Please share your experiences in the comments for this post!
What a glorious dynamic SQL vs. stored procedure debate we have going on! 
I've always been a bit of a stored procedure bigot. In my early days I got bitten numerous times by dynamic sql. As Frans has pointed out dynamic sql, which is generated for you behind the scenes, removes a lot of the “potential for pain.” By encapsulating the SQL generation in a single component you can ensure the SQL code doesn't get interspersed with all the other code within your application.
The entity framework I've been developing (which technically is a OR mapper) uses stored procedures. The main reason for this is that like Frans, I had some misconceptions about dynamic sql. Over the last year or so I've read a lot of posts by Thomas, as well as Frans, which have corrected a lot of my misconceptions. They've done an awesome job educating stored procedure bigots like me, on the fact that dynamic sql, when done right, can be a very viable alternative to stored procedures.
The biggest problem with using stored procedures within an OR Mapper is the fact that it introduces another element into the equation. When you update your business object, you then need to update your table, as well as your stored procedures. When you want to add another filter to a select you need to update your stored procedure. When you want to do pretty much anything, you need to update your stored procedures.
Although my OR Mapper currently uses stored procedures to perform all its data access, it would not be a huge task to make it use dynamic sql. As I've noted before the framework uses a provider model. My current entity provider happens to use stored procedures to persist, retrieve, and delete entity objects from the data store. There is nothing stopping me from creating another provider that uses dynamic sql.
Lately I've been thinking about what the REAL problem is with using stored procedures with an OR Mapper. Why do I have to go into each stored procedure myself and add the additional parameter. If dynamic SQL can be generated “on the fly” to persist my entity objects, why couldn't a stored procedure be generated “on the fly” as well.
By relying on myself to update the stored procedures when I update an entity object I'm not keeping with the DRY principle. The information necessary for the generation of that stored procedure is already available within the metadata for that entity object. Why can't the entity object's metadata be the driving force?
One of my colleagues recently asked me to define an “entity object.” Before I came up with a definition he sent me this link: What is an entity object?
The article does a good job of describing what an entity object is as well as many of the things one has to think about when they are designing a system or framework to work with entity objects.
Last night I purchased a license for an application from the company's website. After purchasing the license I received an email that contained my license key. After installing the program on my machine I went into the license “area“ of the application. I opened up the email with the license, highlighted the key, and pasted it into the dialog box in the application. After clicking OK I received a message saying the license I entered was not valid. “Say what?!?!”...I proceeded to copy and paste the license several other times, each time trying something slightly different. I finally realized that I had to manually add line breaks after each 40 characters of the license key. Why doesn’t the license key in the email have line breaks after each 40 characters? Why does the application care? Shouldn’t it be able to figure out what the key is, even if I don’t explicitly add the line breaks myself?
Maybe we should JUST focus on our user interface's usability! I was ready to call up and ask for my money back when I finally realized what I had to do to make the application accept the key I was entering. Things should not be this hard.