Application Generation - Controllers

Reconsidering Controllers - Part 3

Fri, 22 Jun 2007 07:26:00 -0400

In my first post, I looked at a basic DSL for simple "view" screens and in the second part I added support for conditionality ("if form submission valid do this, else do that"). In part 2.5 I made some comments about "types of elements" in DSLs. In the third part of this series, I start to look at some of the other issues that my controller DSL might have to consider by trying to "build" a simple commerce system using my DSL . . . [More]

Reconsidering Controllers - Part 2.5 - Types

Thu, 21 Jun 2007 17:55:00 -0400

Just a real quickie as part of this continuing series. I just want to go from having a type attribute to different elements for each type. Here's why that is often a good idea . . . [More]

Reconsidering Controllers - Part 2

Thu, 21 Jun 2007 11:16:00 -0400

In my last article, I came up with a very simple DSL for controller queries (pages where you want to access but not change application state). In this posting I look a little at how it would have to evolve to handle commands and slightly less trivial use cases . . . [More]

Reconsidering Controllers - Part 1

Thu, 21 Jun 2007 08:46:00 -0400

I've spend most of my time with my in-house framework focusing on the model as that is where the heavy lifting goes on. I've used a base object controller to good effect so I can just make parameterized calls to generic form process, list and other base methods to cut down substantially on my controller code, but I still have front end "features" that act as a facade to this and right now they are still written in a 3gl (ColdFusion). My goal is to have more configuration and less (no?) coding in my controllers, so I'm trying to figure out just the right way to break this down . . . [More]

Generalizing the Controller

Mon, 28 May 2007 14:02:00 -0400

Imagine if you could look at every page request as a type of parameterized action on a specific object. So, you would come up with a list of types of actions (list, displayForm, save, confirm, delete, associate, publish, import, export, report, etc.) each of which would have its own set of parameters (a list would include things like a property name list, default records per page and the default order by, a save would include the list of properties to save, etc.). An inheritance hierarchy would allow you to set defaults at a system level (by default all lists display 25 records) but to overload those at a object level (by default Products display 50/page), an action level (the MasterAdminList displays 30 records per page) and for certain parameters, at a request level (if exists URL/form.RecordsPerPage, use that instead of the default value). If this was true, what kind of metadata and/or code would be required to implement Controllers to solve the majority of use cases? . . . [More]

What Does the Controller Do? (Advanced)

Tue, 08 May 2007 20:17:00 -0400

Usually when we talk about controllers, we mean the HTML controller whose responsibility is to mediate between the language of the browser and API of your model. What would happen if we looked at controllers as the code responsible for mediating between any request and the underlying model API? What would that model API look like? And how can we generate the darn things so we can all stop writing code and start watching Lost?! . . . [More]

Context Counts - The Importance of the Page Metaphor

Thu, 01 Mar 2007 21:56:00 -0400

When is a resource not just a resource? When its context counts . . . [More]

Introducing the Input Object

Sat, 17 Feb 2007 14:13:00 -0400

All of the major MVC frameworks have some way of providing access to the URL/form scopes as a single scope. In LightBase, we use an object with generic getters and setters (why are you not surprised!) but we also add a little more power to solve another common issue with input variables . . . [More]

In Praise of Pages

Sat, 17 Feb 2007 12:39:00 -0400

Why I don't love Fusebox, Mach-II *or* Model-Glue! For most applications, a major goal for developers is to program in a language that is relatively comprehensible to the client who has to specify the requirements. If you're coding for loops and they're talking insurance coverage rules, that mismatch will typically make both specifying and maintaining the code more difficult than it needs to be. This is one of the big drivers of Domain Specific Languages - allowing programmers to write solutions that (at least at a high level) are described in terms of the problem domain. One of the big trends in ColdFusion frameworks has been the move from a page controller model to a front controller. In this posting I am going to argue that for many use cases this is not a great choice. [More]

Beyond MG and M2: Continuations for Stateful Web programming

Mon, 22 Jan 2007 18:08:00 -0400

This is about as a good an introduction as I have ever seen to the concept of continuation servers (which I have mentioned a number of times before). While continuations are by definition a function of languages that use closures, the same basic approach could be mimicked in CF by simply storing a modest set of information in session state. I am not convinced that continuations are the one true way to write web apps, but I think it is time to get beyond a simple stateless event=xxx paradigm and to talk about more interesting approaches . . . What is everyone else doing?!

Proposed New Years Resolution: Write Re-usable Models

Mon, 01 Jan 2007 13:21:00 -0400

Sean has mentioned this before and I think I locked a pretty good test for putting the right functionality into your Controller (hint: almost none!), but I still see a lot of applications with business logic in the controller. It’s a good anti-pattern to learn to avoid. [More]

Main Content vs. Secondary Content Areas

Sat, 09 Dec 2006 19:51:00 -0400

One of the biggest questions I keep asking myself when developing a simple controller for stateless requests is how handle the population of secondary dynamic content areas. Examples would be a dynamic sidebar with links based on the page section you are in, or a right hand sidebar on some pages displaying anything from a list of recent testimonials in the “Why buy” section through corporate news releases in the “About Us” section and category or product specific cross sells if you’re in viewing the store (and nothing at all on checkout pages to keep the interface cleaner). So, what is the best way to go about generically solving this class of problems? . . . [More]

Is it Worth Being Able to CF Flush?

Fri, 08 Dec 2006 00:18:00 -0400

Ben Nadel posted an interesting piece the other day about his requirements for a page rendering system. One of the things he was looking for was an approach that allowed you to defer as much processing as possible to allow for at least partial page rendering as quickly as possible to give the perception of shorter load times on the basis that users consistently report lower perceived load times for pages that start to render quickly even if the total page load is the same or even slightly longer. There are two issues that need to be addressed when looking to implement such a solution. CF locations and dependent content areas . . . [More]

Will Implicit Invocation Continue to be Important in Controllers?

Sat, 02 Dec 2006 17:02:00 -0400

I am wondering if we will see less of a need for the flexibility of implicit invocation in the controller layer as multi-modal systems, portal style controllers and continuation server style stateless controllers become more common? Definitely blue sky as I have no idea of the answer but I’m hoping any comments to this will help me to understand it better! The purpose of implicit invocation is to provide a level of indirection by decoupling an event from the code that needs to be executed on that event. While it can arguably make an application a little harder to debug, it can also make it much DRYer by allowing the same listener to be associated to multiple events and to allow for the decoupling of more complex flows. To take a simple example, if an “add product” form is validated successfully by the model, you may want to redisplay the product list. With II, you can just fire off a “ProductList” event so the same product list listener (which calls ProductService.getProductAdminList() and then sets the screen to display to “ProductList”) can be reused rather than being replicated . . . [More]

Object Controllers and Inheritance

Sat, 02 Dec 2006 16:35:00 -0400

There is no single optimal pattern for implementing controllers. For example, sophisticated state dependent flows like complex checkouts and wizards are often best implemented using a stateful continuation server, and multi-area content management or portal systems often work better with component based controllers with each content area having its own unique controller along with some fairly sophisticated component based session state management features to ensure that changing the page of the user list you look at doesn’t break the fact that you’re still viewing the articles in the top right corner ordered by title rather than publication date (if you have those kind of requirements). I’ve been thinking a lot about these kinds of controller requirements and will be fully supporting them in LightBase by the end of the year (promises, promises :->). But for now, I want to talk about a very simple solution to a very simple problem. The vast majority of single content area, stateless page views (which is what a lot of us deal with a lot of the time) can actually be implemented quite nicely using an “object controller” pattern. I’m sure this isn’t even vaguely original as it seems a very obvious approach, but I though I’d post on what I’m doing so that I can get feedback on how other people are implementing similar system and any limitations/issues they have run into. I need to clarify that this is NOT a complete solution to any kind of controller requirement, but does seem to be a fairly elegant way to handle simple single content area stateless controllers. [More]