This tip has to do with modifying the way your data is presented. Essentially the problem arose like this. Client had and admin that I built using the scaffolding in Model-Glue Unity. I have modified most of the displays and it has worked great for us. But now we want to add to the admin another field. They want to mark wether a member has sent a check as method of payment. All and all this is not very tough. I go to my database and I add a field to it called checkSent its a tinyint(1). So now I can just store null, 0 and 1 in the field. Since most people have no values and i dont want to go change that, we will say that only the value 1 means they have sent a check.

If we tell MGU to rescaffold for us (?event=member.list&scaffold=true ) then we can go look at the generated code and steal it. Since we have already been modifying the display we already have a frmMember.cfm in the views folder of our application. So now we have added the html to display the value from the database. Only one problem… Its a text field. Now our users have to remember to put a 0 or a 1 in that field to make things work nicely. I dont know about you but I dont trust users to be able to remember that. What I really want here is a checkbox. So I change the cfinput that we added to our form so it has a type=”checkbox” the value=”1″ and the checked property is based on the value being a 1.

All better right? Well now we can check the box and save our member. If we go back and visit the form we will see that our box is checked and we are happy. But what if we didnt mean to set it. Maybe it was an accident? Uncheck the box, submit, and then return to the edit form. Its still checked. :(

See because we allow our field to be null in the database the form validation doesn’t require we pass a value. And the field being undefined (remember a checkbox thats not checked passes no value on submit) doesn’t get set into our database.

So how do we fix this? Well one way is to go the same route we did with our list event. That is to over-ride how Model-Glue processes the data. But that sounds like a lot of work and I am not into it. So my solution was a little trick with the html. Think about what happens when you submit a form that has multiple inputs with the same name. Most common example of this is with checkboxes. The results are passed as a comma separated list. But what if one of the possible values of the list is “”? Well then its not really worth passing is it? So what I did to solve my issue was add a hidden input on the form with the same name as my checkbox. Now if the check box is marked when the form get submitted we the value of 1. But if the checkbox is not checked when the form is submitted the hidden input takes over and the value is “”. And that is a value it gets stored into our database as null. And because we decided above that only the value of 1 means that a check was sent, we are in business.

Of course this is in some ways a hack. But the truth of it is that if fits our needs and the effort required matches the payoff we get in the site. So take that little tip with you on your next Scaffolding form adventure.

PS. If you want to test this little hack of mine, through this code in a test.cfm and give it a whirl.





In that post I talked about adding a function to your controller to change the query that is used for a scaffolded event. This is just one way to go about this however. I think for most model-glue ‘ers this will be the most familiar way of adding functionality. However now that we are working with Reactor inside MGU it may not be the best way. Reactor is an ORM framework for cf. It is a kind of highbred between the Active Record and DAO design patterns. What that means to us however is that it creates a Gateway object for each of the tables in our database. This gateway object is then responsible for retrieving sets of data (queries) from our database for us. So in my last example the query I wrote would really have belonged in my MemberGateway object. Again this is not really a tutorial on how Reactor works either (what good am I too you anyway :] ) so I direct you to look more into Reactor if you are interested.

But what I do want to show you is how your Model-Glue.xml file will change using this method. As it stands our event-handler broadcasts the the “member.getAlMembers” message and then displays our list of members. It looks something like this.

What we want to do is bring back our “ModelGlue.genericList” message that our scaffold generated. With that back we can add on the “gatewayMethod” argument and specify the function we created on our gateway. Now our broadcast configuration will look like this:

And the only thing that is really different between what we had in the last post is that last line about gatewayMethod. Now Model-Glue will use our method on our gateway to get the data from the members table. And we can use that same function from elsewhere in our application if we require.

Seems like a long way to go, and we ended up so close to where we started. But hey sometimes it takes a bit of work to learn something. Now go forth and build on the code that has been generated for us.

Well I happen to believe they are a great place to start. So much so that when I had to build a free site for someone recently I used MGU in the admin, even though the front end of the site was done with fusebox. This arrangement worked out great for a while, but now they need a little bit more information to be displayed. MGU makes it very easy to take what it builds and customize that. For starters I wanted to modify what gets displayed on the member.list page of my admin. Well MGU generates the templates for me inside the /site/views/generated folder. For the purposes of displaying the list of members the file is named dspMemberList.cfm. If you just take that generated file and drag it, up out of the generated folder, into the views folder MGU will use this file instead of the generated one. So by default the scaffolds in MGU display every field in your table across the page, and we dont need all that information. The first task is to only display the data that we need. Remember this is just a summary page. After saving your new file with you modifications you can run your page again to see how you have updated the layout. You can also do this with the frmMember.cfm and dspMember.cfm files if you would like to modify the layout of them.

That is all well and good for getting started on making modifications. But lets look at something a little bit harder. And I will note here that I am using MGU from the svn respository ( its possible this stuff may not work with whatever release is out in beta). On my member list page I want to display some aggregate data. Maybe its a sum of the number of times a user has logged in. But really the point is just that our generic query that the scaffolds wrote for us isnt going to cut it anymore. What I really need is to write my own query and use that to populate my display. This task is almost as simple as creating the scaffold in the first place. First thing we want to do is get the generated event handler xml code from the scaffolds.xml file. This will be located at /site/config/scaffolds/Scaffolds.xml assuming site is the name of your MGU app and you haven’t changed the location of the scaffolds info in your MGU configuration. Glancing at that file you will find a section that looks much like this.

We want to copy that code and paste it into your ModelGlue.xml file, inside the section. Just having this code here is not enough though. We also need to tell MGU not to scaffold the view piece for us. So we need to modify our scaffold tag for member to specify that information.

Now our scaffold knows not to generate the member.list event. If we run our application again and append the &scaffold=true attribute. We should see our application run, just like we left it. Only difference is behind the scenes its using our new xml config in the Model-Glue.xml file.

So lets push ahead. This is not really a tutorial on using MG, I am really just working on extending the scaffolding features. So when I say “I next created a new message-listener and called a method on my controller which got my new query” I am not really going to get very deep into how that works. I believe this to be a standard Model-Glue item and if you have done any you will know how. And if not then check the documentation because Joe does a great job with that. In fact you can take a look at Quickstart 4 in the Model-Glue Unity Documentation to see the steps involved.

So I created a new message-listener called “member.getAllMembers” on my controller and asked it to call the “getAllMember” function on my controller. That function does some stuff to get a query that is joined with a couple tables and does some calculation. Then it puts that query into the event using setValue. Now i need to modify the event-handler for member.list to call this new bit of code and use it for display. This is as simple as changing:

To this new code

Now when we run our ?event=member.list page in our MGU site, our new query is used to get the data. And using the same file we modified above we can display the new data from the query on our list.

Pretty neat. What we looked at here was modifying the code generated by the Scaffolds in our Model-Glue unity application. We created new templates to use for display as well as changed how the code runs. We now have a site that is customized for us, but we still had to write very little actual code to get it done. So go get some coffee and play some Gears of War. You earned it.

I already use ColdSpring and Reactor in my fusebox projects, so the only thing I really needed to grasp was the Model-Glue pieces. This is all very well laid out and it took no time at all to have some basic pages running queries and displaying data. So on to the scaffolds. Adding the CRUD functionality based on a table in my database was stupid simple. In the event-handler section of the model-glue config file you just add a scaffold tag and specify what table you want it to work on. Something like this:

But I had already setup some layout code for the site so I wanted to use that with the scaffolds. So I amended the code like so:

And with that I could visit my site and use the following url to see the list of data from the members table in the database:

http://my-site.com/admin/index.cfm?event=member.list

This also added member.view, member.edit, member.delete and member.commit as events that can be run in my application.

In just a couple lines of code I added a whole bundle of functionality to my site. Enough so actually that I could get the thing out the door and let the client have some time to decide what they would like added.

What came next is was adding functionality to the scaffolded code. But thats a post for next time.