Yeah, you've misunderstood a little. Action pages are like "process this form submission", while display pages are like "display this page". Each page may required multiple fuses (and fuseactions, in FB4.x), quite possibly even some of the same ones. But the two things should be separate requests.

For example, say I click an 'add to cart' button for a product. The overall result of the click should be to add the product, and display the cart for the user. The click will first call an action page that'll add the item to the cart. Then the fusebox should redirect to another (display) page that renders the shopping cart. The two shouldn't happen in the same request.

The end result is that the user experience hasn't changed (aside from perhaps a short extra delay for the redirect), but the user is protected from adverse consequences of hitting the refresh button. It also makes the code simpler, because each request is only doing a single thing. Simpler code is easier to maintain code, and that's always a good thing.

Its regarding point #1 – split action and display pages, so that an action page has to redirect to a result page. I may have misunderstood so correct me if i'm wrong, but isn't this what fuses are designed for? You can still have one page request, ie fuseaction, but split it into separate action and display fuses? Each fuse is still independent and reusable, and this way you have one less fuseaction to worry about.

It seems a bit of overkill to have a different fuseaction for each individual fuse.

Many thanks. You helped to come forth.

Ulf

You got it. I usually set variables.my.lockkey to a UUID in the init() method and use that as my lock name. If I need multiple lock names, then I'll obviously have multiple keys. That helps avoid typos in your lock names, which can lead to amazingly subtle (and difficult to quash) bugs when your app starts running under load.

Don't try to do too much with your service component regarding locking. Just as it encapsulates the locking behaviour from it's calling code, your other objects should encapsulate their locking behaviour from the service object. If you're allowing multiple service method calls to access a single object, then yes, the service needs to lock that. But if your business object has an internal race condition, the BO should do the locking, not the service, because the service can't know that race condition exists without knowing how the BO is implemented (and thereby breaking encapsulation).

just to get it right. If I need locking, I'll have to do it in this service component (which is in application scope).

So I don't lock access to the service component (and use cflock scope="application"). I'll have to use named cflocks in a called method if I use business objects where race conditions can occur. Is that right?

Ulf

Redirect after post is pretty simple. Any time a request is a form submissions, don't display a page, use CFLOCATION (or an equivalent) to go to another page for the display. Take the example of an "edit user" operation. First page is the form. It submits to a second page which runs an UPDATE query. Then, instead of displaying a "update complete" message, it uses CFLOCATION to forward to a third page, and that third page displays the "update complete" message.

The only exception is errors in server-side validation. In that case, it's okay for the action page to detect the validation error, and then regenerate the form with the error message(s) at the top.

For the independant UI and model, DAOs aren't going to get it for you. Those are an implementation detail of the model (a specific way of implementing persistance operations), and if your FB app knows about the DAOs, then it's not encapsulated. The service object provides an adapter between FB and your model. If you use DAOs, your service will deal with them. If you use inline SQL, your service will do it. The FB app doesn't know and doesn't care, as long as the service method does what it's supposed to do (addUser, getUserList, etc.).

Breaking down your persistance code into DAOs that are then leveraged by your business logic is a good plan, but they are for separating business and persistance logic, not business and presentation logic. Both are desirable, but your business and persistance logic are usually much more tightly coupled (just the nature of the beast), so the benefits aren't as great as between business and presentation logic.

I don't really have any good samples to share, unfortunately. The code from my presentation at the conference has an example of how service objects are used. Any book on application design should also talk about these principles, no matter the platform (CF, J2EE, .NET, FORTRAN).

No, not really. Access to shared-scope CFCs does not require locking unless a race condition is created. However, only the CFC should know if such a condition exists (because that's an implementation detail of the CFC), so only the CFC itself can know if locking is required. Thus, any CFLOCKs that you need are internal to the service CFC, not external (in the calling code).

In this app, the service object happens to carry a single instance variable (the datasource name) and the SQL access is all transactional, so there are no race conditions to worry about. That will undoubtedly change in the future, and at that point, I'll add CFLOCK calls as necessary. Because they are internal, my FB app won't even know the change happened; it is 100% isolated from implementation details.

I saw your presentation at Fusebox 2004 and left with some ideas for improving my apps. But I'm still coming up short. Can I get some training wheels? I feel the need for two major improvements and you've got them: re-direct after post, and model independent implementation. I've been trying to get more comfortable with DAO's expecting the model to be more flexible through their use. Any materials or samples you can suggest to get these ideas through my thick skull?

Thanks,

Ed

Are there any problems to expect because the service factory is in application scope and calls to it can not be locked in circuit.xml?

For example, I've got a method for retrieving a comment, which is called like this:

[set name="comment" value="#application.blogservice.getCommentById(attributes.id)#" /]

Of particular import, note that the method doesn't know where the ID came from (attributes scope, in this case), nor the name of the variable it's return value is stored in (comments, in this case). Because of that, I can call the method in a different way (from a CFC facade, for example) without the method caring.

That's one of my major gripes with "standard" FB4 MVC, because your fuse defines what the parameters and return variable must be named. Well, the Fusedoc does, but the point is that they are locked at architect-time. With a method call, I can pass it a value from a query, a page parameter, a hard coded value, or whatever, and I can also assign the result to a variable of my choosing. No variable collisions, no fuse-centric variable assignments, just pure logic in a container that's not only reusable throughout the framework, but throughout the app as a whole.