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]

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]

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]

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]

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]

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]

When is a resource not just a resource? When its context counts . . .

[More]

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]

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]

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?!