This feature is small, hell since I’ve been using spark I almost forgot about it, that is until I started working on a simple administration section. The application has enough entities that “Right Click –> Crud” would make just the right tool.

Idea

ASP.NET MVC provides customizable code templates for the view/controller content. There are a few really good articles on how to get started.

Plan

1. Include the CodeTemplates in my project
2. Change the output extention to .spark
1. 
3. Modify the markup to sparkup
4. Phase 3: Profit.

Problem

ASP.NET MVC uses a custom tool to process the T4 templates.

MvcTextTemplateHost

It ignores the output extension directive in T4 templates.

(Click play)

Sadness

MvcTextTemplateHost is included in Microsoft.VisualStudio.Web.Extensions.dll and this DLL that is not “part” of MVC code that was open sourced.

Conclusion

I’d love to write a Visual Studio addin to create spark views but I just don’t have the time. However; I do wonder if I can just have spark parse the .aspx and .ascx files.

No related posts.

Need:

To pass information to every view based on an environmental variable. The specific case I ran across this need is when you want to use the minified version of your JavaScript libraries in production and the human readable in dev/QA.

Solution:

• Create your own base controller class.
• Override either onactionexecuting or onactionexecuted.
• Populate TempData with the environment specific information.
• Change your controllers to inherit from your custom base controller
• Use that information in the view.

using System.Configuration;using System.Web.Mvc;

namespace BaseController.Controllers{    public class BaseController : Controller    {        protected override void OnActionExecuting(ActionExecutingContext filterContext)        {

            filterContext.Controller.TempData["OnActionExecuting"] = "OnActionExecuting";            filterContext.Controller.TempData["js_dev"] = ConfigurationManager.AppSettings["js_dev"];

            base.OnActionExecuting(filterContext);        }

        protected override void OnActionExecuted(ActionExecutedContext filterContext)        {

            filterContext.Controller.TempData["OnActionExecuted"] = "OnActionExecuted";            filterContext.Controller.TempData["js_prod"] = ConfigurationManager.AppSettings["js_prod"];            base.OnActionExecuted(filterContext);        }    }}

Pros:

• I’ve found that I often have to create my own base controller class. Doing so for something this simple is a god starting point.

Cons:

Alternate Solutions:

• Use T4 templates to generate a const file based on environment.
• Put the information of each server in the machine.config

Final:

The solution is sound and a sample is attached but I am going to have to come back and flesh out this post a little more with details about the *.config/caching and other options.

No related posts.

What is it called?

First off; what are we calling “Classic ASP.NET Development using Webforms and the MVP Pattern” today? I’d like to suggest we stick with a discussion of the patterns and the surrounding technology.

Component based development using the MVP pattern…or MVP for short

and

Non-Component based development using the MVC pattern…or MVC for short

And I am aware that there are companies working on MVC components/html helpers…so what else are we going to call it? Then again you might be write…what % of “Webforms” developers are using the MVP pattern? 5%?…hmmm…anyway I am sticking with MVC and MVP until I read something better on stackoverflow.com

Don’t be such an ass

Here is the document that I presented to a client when they asked for…well a comparison of “Classic ASP.NET Development using Webforms” and “MVC”

Introduction

In the .NET world the MVC pattern is relatively new but it has been the staple development architecture for Java and Ruby for over a decade. Most of the current the debate between what technology is “better” is argued from a developer’s point of view. While the technical underpinnings of a technology can often translate to the projects success; I feel that both WebForms and MVC are mature enough that most projects will do fine with either.

ASP.NET WebForms

Through the abstraction of HTML, CSS, and JavaScript; ASP.NET WebForms attempts to recreate the experience of developing a desktop application. The entire HTTP protocol is successfully abstracted away and developers are present with a faux statefulness that mimics desktop applications. Development teams are able to use a WYSIWIG style of development.

ASP.NET MVC

Out of the box ASP.NET MVC forces developers to understand HTML, CSS, and JavaScript. There is little to no abstraction which can be a double edged sword. On one hand your development team has access to the raw power of the markup & languages that make up the web. On the other; if your development team is not experienced with HTML, CSS, and JavaScript there might be a learning curve.

Decision Matrix

Number	Topic	ASP WebForms	ASP.NET MVC
1	Size, Extensibility, Maintainability	Your project is small and your team is not experienced with MVC	Your project is large (experience with MVC not required)
2	3rd Party Components	Your project requires many specific 3rd party vendor components	Your project is not bound to 3rd party vendor components (The UI can still be very rich)
3	Open Source	Your project team is not comfortable with open-source libraries	Your project team is comfortable with open-source libraries (especially jQuery)
4	Extensibility, Maintainability	Your customers requirements will not change during development	Your customers requirements may change during development
5	Extensibility, Maintainability	Your project will never be "extended" or have a feature "added"	Your project maybe be "extended" or have features "added"
6	Testability	Unit testing is not required for this project	Unit testing is required for this project
7	Extensibility, Maintainability		Your project is limited in maintenance hours
8	Compliance	There is little to no concern with regard to HTML compliance	HTML markup compliance (compliance, screen readers, etc)

Notes

1. The convention built into the MVC framework helps enforce a separation of concerns design pattern what helps developers built applications that are inherently more extensible and maintainable.

2. If your project/company has an existing large investment in 3^rd party components you should consider sticking with whatever framework the components are developed for (Webforms or MVC)

3. component suites are available for both frameworks but many developers have found that jQuery, and to a less extent other open source frameworks, is a better solution for building rich UI

4. The convention built into the MVC framework helps enforce a separation of concerns design pattern what helps developers built applications that are inherently loosely coupled.

5. See note #4

6. ….

7. ….

8. ….

No related posts.

I find myself adding child objects within their parents control. For example; if I was going to add a child. I would call the parents controllers addChild action.

/parent/addChild/2

In this case 2 would be the id of the parent that I wanted to add a child to.

Doing it this way I don’t have to keep an internal track of which parent the user wants to add a child to.

For example /child/create does not tell me what parent I am going to associate the child with. In this scenario I would have to put the parent ID in session or something first.

Not sure if what I am doing is “right”….I think so.

No related posts.

I have to admit I am total bias towards MVC but hear me out. I have yet to work in an organization that implements an OOP or even MVP when using WebForms. It’s all been directly bound controls to data readers/sets/tables. No object model, no business object layer, page_load is used and abused, etc. It can’t be stated enough that MVC will not save a project from the bullshit code that is forms over data crap but at least there is hope in the form of a tiny amount of guidance from Microsoft. </rant>

Introduction

In the .NET world the MVC pattern is relatively new but it has been the staple development architecture for Java and Ruby for over a decade. Most of the current the debate between what technology is “better” is argued from a developer’s point of view. While the technical underpinnings of a technology can often translate to the projects success; I feel that both WebForms and MVC are mature enough that most projects will do fine with either.

The technical debate does nothing for those who are trying to persuade their organization to consider ASP.NET MVC. What I am trying to present here is a list of decision points an organization can use when deciding on MVC vs. WebForms.

ASP.NET WebForms

Through the abstraction of HTML, CSS, and JavaScript; ASP.NET WebForms attempts to recreate the experience of developing a desktop application. The entire HTTP protocol is successfully abstracted away and developers are present with a faux statefulness that mimics desktop applications. Development teams are able to use a WYSIWIG style of development.

ASP.NET MVC

Out of the box ASP.NET MVC forces developers to understand HTML, CSS, and JavaScript. There is little to no abstraction which can be a double edged sword. On one hand your development team has access to the raw power of the markup & languages that make up the web. On the other; if your development team is not experienced with HTML, CSS, and JavaScript there might be a learning curve.

Decision Matrix

ASP WebForms	ASP.NET MVC
Your project is small and your team is not experienced with MVC	Your project is large (experience with MVC not required)
Your project requires many specific 3rd party vendor components	Your project is not bound to 3rd party vendor components (The UI can still be very rich)
Your project team is not comfortable with open-source libraries (expecially jQuery)	Your project team is comfortable with open-source libraries (especially jQuery)
Your customers requirements, possibly by contract, will not change during development	Your customers requirements may change during development
Your project will never be "extended" or have a feature "added"	Your project maybe be "extended" or have features "added"
	Your project is mission critical and deserves the comfort provided by unit testing
	Your project is limited in maintenance hours
	Your project cares about HTML markup compliance

Conclusion

I think that most projects will be able to succeed using either technology. The question is simply how much pain will you cause your developers? Will you stick with web forms and create an endless maintenance cycle? We know how much developers love maintenance programming. Or will you force them out of their comfort zone and make them learn something new for the sake of your project?

No related posts.

Let me start off by saying I am so happy with the “New” Microsoft. An engaged Microsoft, an open Microsoft.  So to the Kobe team I say “Welcome to the real world”.

There are enough people writing about the amazingly horrible code. I’m upset with the response from the team. The response, at first glance, seems to acknowledge there is a problem and that they will fix the Kobe code.

Then I read it again…

This post is defensive and response laden with manager speak for “fuck off”. More so, they don’t even acknowledge a problem with the Kobe code!

The sample app is not a "reference application" in the context of code completeness. A "sample app" and a "reference app" are quite different in the context of code completeness, and we do not claim Kobe to be a reference app in this context.

Oh!, I am so sorry, I thought it was a "reference application" now that I know its a "sample app" all is right in the world. FAIL. What is that code a sample of anyway? After looking at the code and reading the numerous community responses its quite easy for me to say.

The Kobe code is a sample of how NOT to do ASP.NET MVC

If we now have the same understanding of the word sample; then I agree; Kobe is a sample.

Now, I am aware that Rob and the Scott are stepping in to clean this up…Oxite déjà-vu. But I need to make one final comment about the teams acknowledgement of the problems in the code.

We will review all sumitted feedback and take action to address items within the context of the intended scope & goals of the Kobe project.

That is so so so far from an acknowledgement. This is an acknowledgement.

No related posts.

Today Oakland County launched Golf and Trails, or GAT, their first ArcGIS Server Web Application based on the JavaScript API.

Over the past 2 years I, as a consultant via Technology Aces, have been part of a team of developers working on a very large GIS web application. So large and so complex that its first public appearance is as the underlying framework that powers GAT.

I am happy to say that one of my projects with Oakland County finally released to the public, even if it is a “light” version. 

No related posts.

I wanted to learn how to use facebook connect and ended up using FBC, Twitter, OpenID, some complex htaccess, got sick enough by the process (not having a PHP MVC framework to call my own) that I started on php.technologyaces.com

I have code that won’t write itself…

Also, I decided to dump the simple framework…I think Code Igniter is simple enough. I don’t have time to play developer…I am in need of cracking stuff out quick!

No related posts.

Or at least I think so…

I started using the PHP MVC thingy today – after spending a relatively short amount of time coding the core. I found there where a few missing items…who needs to support HTTP POST anyway?…and I needed just the little bit of sugar in the form of some db helper methods and FirePHP for debugging.

I spent about 3 hours coding the new MVC’afied http://dev.vinspection.com and I am really happy with the new framework thing.

No related posts.

I wrapped up the alpha version of the new Technology Aces PHP MVC Framework. Which by the way I really need a name for. TAPMF? um….no.

I don’t have any code for the model yet…hence model-less MVC..I’ll have it done soon.

No related posts.