Model Glue is Good!
Ok, you already know that, but I've never worked with model glue before. I've been a mach-ii guy for a while and I like it. But now that coldspring is said to be super easy to integrate with mg, I figured, I better take a look. So here's a quick rundown of the day. 10:00, I slept late, OK? My kids stayed at their grandparents last night, it's the first day I've slept passed 7:00 in years! Anyway, at 10:00 I got model glue from svn, went straight for the ber! I figured I better clean up my dev machine at this point because I had 3 versions of coldspring and 2 versions of the record store example app on there, so that took a little while. I changed the layout of the model components a little and shifted around my root folder so both controller apps could share a config folder, as well as the coldspring config file.
After initial set up, I decided to read the quickstart guide, OK skimmed it, and figured I'd jump in and see if things would just work. I copied the 2 listeners in to the controllers.mg folder, replaced all the event.getArgs() with event.setValue() and put return values back in the event instead of returning them. I really like this part. I have had numerous discussions with mach-ii developers about putting data in the event in listeners, instead of all the request scope stuff. I have apps that do this exclusively, so this fits perfectly to me. I hit the views next, this was basically nothing. I just switched my event.getArg() to viewState.getValue(), which I do first thing anyway to get local references, so that was simple. I did all this before creating the xml, since I figured that's where the differences would lie.
Working with the xml file was really pretty easy, my only big problem was I read the quickstart guide too fast and didn't put my message tags in a broadcast block, so when I fired up the app, I got my layout view with nothing. Then I figured out the proper way to use the ViewCollection.getView() method and got my nice layout page with my error template. However, looking at some debugging I did see that my model components were completely wired up through coldspring no problem! After a little more kludging and some teasing in the coldspring irc channel I think I got into the swing of things pretty well. Since mg has no filters, that means more control logic in the controller, so it's a little heftier that the corresponding listener. Is that a bad thing? I don't think so. Why do I need xml to tie all that logic together anyway? A few things here and there kind of tripped me up, but after I felt a little more comfortable, I stopped trying to make mg fit the app that I already had written, and worked on it as a mg app instead. So after all that, I had a completely functioning app at 5, inheriting all the model goodness from the mach-ii app, logging, security and caching.
Overall impressions? I like it, as a matter of fact I really like it. One of the things that's great about coldspring is it's very lightweight, especially if you're using Sean's autowire controller for mg or our autowiring plugin for mach-ii (which will be in the next release). Coldspring just does its work and gets out of your way. Model glue seems to follow right along with that mantra, it's nice and light. Filters and plugins are very powerful, but maybe we don't need them so much. Maybe we don't need to rely on them so much, to be more precise. You need to concentrate on business logic, and model glue gets right out of your way, and lets you get to it!
After initial set up, I decided to read the quickstart guide, OK skimmed it, and figured I'd jump in and see if things would just work. I copied the 2 listeners in to the controllers.mg folder, replaced all the event.getArgs() with event.setValue() and put return values back in the event instead of returning them. I really like this part. I have had numerous discussions with mach-ii developers about putting data in the event in listeners, instead of all the request scope stuff. I have apps that do this exclusively, so this fits perfectly to me. I hit the views next, this was basically nothing. I just switched my event.getArg() to viewState.getValue(), which I do first thing anyway to get local references, so that was simple. I did all this before creating the xml, since I figured that's where the differences would lie.
Working with the xml file was really pretty easy, my only big problem was I read the quickstart guide too fast and didn't put my message tags in a broadcast block, so when I fired up the app, I got my layout view with nothing. Then I figured out the proper way to use the ViewCollection.getView() method and got my nice layout page with my error template. However, looking at some debugging I did see that my model components were completely wired up through coldspring no problem! After a little more kludging and some teasing in the coldspring irc channel I think I got into the swing of things pretty well. Since mg has no filters, that means more control logic in the controller, so it's a little heftier that the corresponding listener. Is that a bad thing? I don't think so. Why do I need xml to tie all that logic together anyway? A few things here and there kind of tripped me up, but after I felt a little more comfortable, I stopped trying to make mg fit the app that I already had written, and worked on it as a mg app instead. So after all that, I had a completely functioning app at 5, inheriting all the model goodness from the mach-ii app, logging, security and caching.
Overall impressions? I like it, as a matter of fact I really like it. One of the things that's great about coldspring is it's very lightweight, especially if you're using Sean's autowire controller for mg or our autowiring plugin for mach-ii (which will be in the next release). Coldspring just does its work and gets out of your way. Model glue seems to follow right along with that mantra, it's nice and light. Filters and plugins are very powerful, but maybe we don't need them so much. Maybe we don't need to rely on them so much, to be more precise. You need to concentrate on business logic, and model glue gets right out of your way, and lets you get to it!
posted by Chris Scott at 7:31 PM
3 Comments:
...and don't forget that my autowire component is now checked in so it should be available in the next ColdSpring release!
Sean
BTW, there is feature request by Dave Ross for the post 1.1.0 release of Mach-II to receive get[Listener/Plugin/Filter]Names() methods so ColdSpring can discover all registered listeners, plugins and filters without the ColdSpring plugin having to reparse the XML configuration file itself.
Best,
.Peter J. Farrell
Hey Peter, I actually reworked the plugin so it doesn't have to reparse the xml, but I do this by adding those methods myself. Let me know if those methods are going to exist in the next release on m2 and I'll switch over the code. Thanks!
Post a Comment
<< Home