There are almost always different possible approaches to solving a given problem. Sometimes certain approaches are clearly superior to others for classes of use cases, and at other times it is more a matter of preferences.
I am by no means convinced that MG and M2 are not the best approach. They are time tested and every day more and more developers are using them successfully to solve a wide range of problems. Asking what is wrong with them today is (to me) like asking what was wrong with Java in 2002. The vast majority of developers would say “nothing”!
The question I am asking here is if we didn’t have M2 and MG, what else might we come up with, and are there any use cases where it might conceivably be superior to the current best practices?
I’m going to make a number of assumptions. They are assumptions about how I would like to go about solving problems, so if you don’t like the assumptions, please go make up your own and feel free to link in the comments to your alternate postings/ideas on the subject. The goal of these articles has been to start a debate – not to end it!
Assumptions
- More multi-modal applications - In general I want to develop applications designed for out of the box support for multiple modes (HTML, Flex, AJAX and SOAP and REST web service calls).
- Complex navigational flows are a model concern - Complex navigational flows (complex multi-page forms and checkouts) contain too much business logic to be stuck in an HTML controller and then replicated for each additional mode. We need a way of specifying state machines as part of a facade to the model which can then be called by a much simpler controller. Seaside and Spring Web Flow both speak to this but I really don’t yet have my head around the best way to implement this solution. I am fairly convinced that however this is implemented it will lessen the navigational load on the controller allowing for a simpler architectural controller design for some use cases.
- Conventions can replace code - Currently most people write custom scripts for doing things like taking the results of a form and turning that into a bean that can in turn be passed to the model for saving. Why write that code? It would be a manageable task to come up with a set of conventions that would allow for automating this based on introspection of the form scope.
- The event model has weaknesses - While it is possible to use an event driven model as a controller for a content management system where there are multiple different content areas and where context within the site map may drive content (if we’re in the about us section, we’ll display news releases on the right hand side bar, but if we’re in the store, well display a list of recommended products driven by the product or category we’re viewing in the main content area). I have personally found a pseudo-page controller a better fit to this kind of multiple content area contextual display problem. Both approaches work, but clients are more comfortable with designing business rules that say things like “if in about us section then display y in content area z” – they are thinking in terms of pages within a site map and I haven’t found any real benefit in trying to move them to an event based mindset for that kind of logic (have you? What benefits accrued?).
- Implicit invocation may not be necessary - This could be way off base, so stay with me here for a second. In general terms I love the observer pattern and often use it within the model to handle things like associating email notifications to events within the model (using the same logic as in my previous articles it seems to me to make more sense to build this into the model than to have to rebuild it in a set of different controllers). The question is, if you move all business logic into the model, what complexity is left that justifies the flexibility of an implicit invocation framework? It seems to me that with the singular exception of authentication (which I see as an exceptional framework feature rather than a standard page flow – typically my frameworks and pages are explicitly authentication aware), most of the complex problems that II solves are problems that may be better solved in the model as we move towards a multi-modal future.
I’m playing with a lot of things right now. I have a base controller with a small set of actions that it employs generically across all objects (the generalized process of taking form variables and putting them into a bean is no different whether you’re managing an article, a product or a user, so why write the code three different times?!). I’m looking at how best to distinguish instances within a class of action (the getAllUsers() from the getUsersinCompany()) elegantly within the controller, the best way of implementing a state-machine for complex wizard base flows within the model and the best way to implement the observer pattern within the model. I’m playing with different approaches to reusing and combining views and am rediscovering how well the pseudo-page controller seems to fit my use cases.
Is anyone else there playing with alternative approaches? Are there use cases where MG and M2 aren’t optimal? Which specific ones? Do you think that as we move more logic into the model there will be less need for implicit invocation within the controller? Should authentication really be an add on (filter or action pack) or is there a sufficiently generalized way of describing and parameterizing authentication to allow it to become a first class citizen within frameworks – not just another set of events?! Even if that is possible, would it be a good idea?
Is there anyone using M2 or MG and who is finding that it is indeed the ideal way to solve all of the problems mentioned and more? Also, I know Sean Corfield and his team implemented a solution using MG with XML views for a project rather than a separate remote facade. Is this just a special case or a taste of things to come?
Any input appreciated!!!
To accomplish this, wouldn't the FLEX front end need to call objects that know not to provide any views? They would need to be separate from everything that renders page data or returns views. This means that all data access and return would have to be abstracted out to be both separated from calls made by FLEX and calls made by a traditional http HTML request.
Is this how it works? Or is FLEX utilizing a different set of calls than a standard web page request?
And then there is the issue of CFFlush. A lot of framework do not allow the use of CFFlush as the view it created as a final action in a chain of request actions. While this does have benefits for modularity, it is not recommended for performance reasons. There are going to be pages that do a lot of processing and need to render inclemently and be sent to the browser in chunks.
Image a page that does a lot of processing over a number of records in a record set. To provide good feedback to the user, you could process a record, flush it, process a record, flush it. This way, the user sees that stuff is happening ever few seconds rather than waiting around for 5 minutes to have all the content finally flushed to the browser.
In this case, which is an optimal user experience, the view is directly tied to the activity or page rendering. In an application that provides an alternate FLEX interface, this would break. FLEX would need a completely different set of calls. It would have to implement the same "controller" logic internally in order to be able to perform a similar part-wise page rendering. What this means is that the VIEW has to be knowledgeable of the relation between objects, which is primarily a responsibility of the Controller? The Model?
Sorry if I am making NO sense here. Sorry if I am confusing and I seem incoherent. Its just that I am not sure that you can create ONE application that has the same controllers. I feel like each face would need its own set of controllers to some extend, which would require duplicating code.....
No need to respond to this, my inexperience with MG and Mii does not warrant a rebuttal. I just felt the need to ramble.
I thought I understood the controller at one time. I really did. I was a Fusebox addict after all. I really believed it made my life easier. Now I am building bigger sites and I don't think that I have suffered for not having a front-controller. In fact, I think my development life is easier now than it was before (perhaps this is due to my individual needs).
I have read your entries on controllers with interest because I feel like I have to be missing something given all of the discussion on controllers. Still, I haven't used a front-controller on any new work in more than 4 years.
I am NOT saying that this should be a driving force in any decision regarding application architecture, but I am just pointing it out.
And true, if everyone in the office had the same standards of coding, it would be an issue at all... but frankly, that's a more impossible dream than a perfect application :)
I also have nil experience with Flex, but you have nailed it. A Flex app calls a model that knows NOTHING about views of HTML. However, the key point is that SO SHOULD YOUR WEB APP!!! The model your web app calls should know nothing about views or HTML - that is what the views and controller handle.
Sometimes a Flex app will need different methods that the HTML app, but with a good design there should be a pretty good overlap.
It is true that each app needs its own controller, but not that they need to duplicate code. There is extra code, but no duplication. Code duplication occurs when you embed business or orchestration logic that is not "mode" specific into your HTML controller. If you want to go to Flex, you have to duplicate the code. If instead you put all of that in the model (while stlll having a model that knows nothing about forms or URLs or HTML) then there is no duplication of code.
Make any sense?
It makes sense in theory, and I appreciate the response. But, as my code is not that clean, it is hard for me to make concrete sense out of it. As I build better applications (and read your posts) I am sure that it will become more clear over time. Thanks.
Interesting. Typically I have code that processes the form and URL scopes, putting them into a request scoped object for better encapsulation and handling of default/non-existent values. Then depending on some kind of parameters (tvent name, page name, whatever) I use that to call a specific controller method which does things like either load the passed form into the appropriate bean and pass it to an edit or add method or make a well parameterized model call to getProductsinCategory(14) or something similar.
Once the model has done its magic and returned some information, I may then follow some conditional logic (such as cflocationing to a list page with a "success" message if an add was successful) and then take any data returned by the model and put it into the appropriate views.
Where do you put the code for doing each of those and how do you make sure it is reusable between pages? I would imagine you have "controller" style code in there somewhere - it is just a matter of what you call it, where you put it, and how you break it up!
First, I think the future of these applications is not applications that are entirely Flex (which seems to be the model now), but rather some mixture of technologies (standard HTML/JavaScript, Ajax and Flex) each serving its most appropriate purposes within an application... or, for instance, an application that has a Flex front-end for standard web-browsers, but something else for some other interface (perhaps mobile though Flash is making significant inroads here too). So, how does an MVC framework like Mach II fit into a hybrid application? Not sure yet, but it may have a place.
Second, even in an all Flex with a CF back-end application (like my generator), I found the need to have some management of application (and perhaps) session scope as well as loading of dependencies within my model. While my very basic solution worked (just manually handling this stuff) because so far my Flex applications have been simple, in a larger application this may require something more standardized and organized like a framework. Whether the current batch of frameworks fit into this model is something I am not sure about yet, but I think they can possibly be made to.
Well, that is why you teach them all Mach-II or Model-Glue - so they all CAN add a page to a front controller when you're out for the day.
I personally use a different approach. If you want to add a new page to one of my apps, you go into the admin site and Page - Add, filing out a form. You select from a drop down list of "features" and if you are a programmer, just write a feature that implements the feature interface and then any non technical user can add that to any page anywhere on this site. Drop the same feature code into another project and as long as any model dependencies exist (if it is a shopping cart, you're gnna need to have products somewhere) it'll work and again be available for a non-technical user to add to the system anywhere, anytime they want. Always seemed like the easiest solution to me, but then I come from a content management background, so I guess it would :->
I would use the pseudo page controller for the HTML piece of the applcition, as in the kind of projects I build the concept of context (I'm in about us section so the secondary content area should have news releases, not product specials) is important. However, all my pseudo page controller does it to call the appropriate feature with the appropriate parameters for each content area within the page. Those features would be available as remote methods (each feature - cart, checkout, article - is a cfc with one or more methods) which is what a web service or Flex app would call. I wouldn't expect the contextual stuff to be used by flex (it could be, but it probably wouldn't be a good choice) because as you pointed out, Flex is usually request rather than page based.
The point for Flex apps though is that you must pull a lot of the navigational complexity out of your HTML controller. If you have a lot of "if this is true go to screen 7 else go to screen 4" kind of logic in your controller for wizards and the like, if you want to support traversal of those wizards using multiple "modes", you need to put that logic within the model and I think ideas like Spring Web Flow and continuation servers give potential models for handling such complexity. There is also something to be learnt from approaches like BPEL.
Its a good day when all the employees here show up to work (and come in on time) ;) Once we get that under control, teaching them a common framework would be good.
Your solution sounds nice. Give me a few years... i'll have something like that :D
Know what you mean about the training. Oh well . . .
About my solution, feel free to play with it sooner than that - I'll be releasing a rough cut of a ground up rewrite I'm doing over the next few weeks!
I think some of the confusion comes from the fact that I break down what people think of as a controller into two chunks. One is HTML specific and handles URL and form scopes and context (using psuedo pages). The other handles orchestration and is part of my model that can be exposed via a remote facade, providing access to all of the orchestrations and features without knowing anything about HTML.
I typicaly don't have a need to convert Form and URL variables into any other scope (something that seemed essential in my Fusebox days, but I almost never need now).
I should probably give a little context to my approach. Although I feel like I have a basic understanding of OO, I haven't really embraced an object-based approach in my design. I typically use a service-based approach, relying on service components and passing data (not objects) to them.
Consequently, I can deal with structures (which Form and URL are) instead of beans, which saves me a step (and has yet to cause me any limitations which I have noticed).
Each page knows what method it needs to call and what data it has available to pass. It also knows where it should go for its "success page".
Since I am typically doing CRUD forms, I have a custom tag set that can call a specified method and pass each form field as an argument and then send the user to the indicated success page.
This approach keeps my code really clean (see CodeCop or the Tulsa CFUG site as examples) and doesn't require much data massaging (hence, I suppose the lack of any real controller).
I find that I need some sort of controller when I am working on multi-page wizards, but then I have a controller for the wizard itself instead of making that part of a larger controller for the application as a whole.
Does that make sense? Am I still missing something fundamental about controllers?
Take the checkout process, for example. You could have data objects for shopping cart items (which could include product objects) buyer name, shipping address, purchase methods and resulting billing addresses. I believe that there is a Checkout business object that would be used to implement the wizard like process of a checkout populating the data objects and ensuring the data is acted on appropriately. I guess that makes the business object psuedo-controllers, but I consider them as part of the model because the controller interfacing with these business objects could be from one of the many modal applications you refer to in your assumptions.
Very interesting indeed - that seems to be exactly what I'm playing with.
The idea of a separate orchestration layer within the model above the business object service layer seems to provide for a bunch of flexibility. Interestingly though, it doesn't leave very much for the HTML controller to take care of. I'm having a hard time in this scenario figuring out why my controller would need to use implicit invocation when all it ever does is call a single method and maybe handle the occasional cflocation!