Is it just me or is GraniteDS just too complicated? I'm an expert using FMS Flash Media Server and I understand BlazeDS but Granite Data Services is beyond plug-n-play. First, what is the stack and why is it hard to figure out? Tide, EJB, Gravity, Pojo, Seam, Spring, Guice, etc..

I have Glassfish v3 installed on my Windows PC along with MySQL and I want to create a Flex 3 application that uses GraniteDS 2.0.x with consumer and publisher, possibly along with Cairngorm Enterprise and no, I do not want an example, I want steps. I'm using Eclipse with Flex 3 plugin, and I don't want to use Maven or Gas3.

1. How do I get GDS installed on the Glassfish server so that I have a gateway (http://xxxxxx/graniteamf/amf), what files, how and where to put them, etc.. 2. Do I use Gravity? Tide? EJB? etc.. 3. What are all of the configuration pieces and minimum params?

I'll take anything I can get to work locally that touches GDS for real time data services with push. I've read everything I can online including the GDS web site and can not find a clear concise simple step by step tutorial or documentation. And if I ever figure it out I will certainly write a tutorial for my blog; sadly it'll be the only clear tutorial available.

So if anyone can tell, show, or point me to the right location, thank you. And I have to warn you, for over 2 weeks now I have tried everything I can find with no success. Please help.

It's my opinion that Adobe is making a mistake renaming Flex Builder to Flash Builder. Simply put, when it comes to business applications, businesses still don't want to buy a Flash solution. Adobe should catch this wave created by the Flex craze and call it just that, Flex.

Is it me or is the view layer in the MVC pattern being ignored or at least understated? Working on my most recent project I stepped up my MVC and OO emphasis during development and noticed that we, web developers, aren't doing anything structured as far as view development goes, at least I can't find anything searching the net. We conform the underlying complexities, like the model layer, into formal design and standards (OO for instance) but don't hold the view to the same or comparable expectations. We make sure that the view layer is seperated from business logic at the layer level but when it all comes together at the view level we fail to make anything formal out of that. I'm attempting here to formalize and structure my view layer borrowing my experience in MVC and OO methodologies. It may be done already somewhere else but I can't find it and I need it, so here it is, right or wrong it's a jumping point.

If you look at the view layer in an object oriented approach and formalize the views as pseudo classes you may be able to deduce where I'm headed. For example, views or pages have properties and methods that can be used to create UML class diagrams during the design phase. In addition you can carry these through the implimentation phase and realize the seperation within your page view code. The view is more than just the HTML layout of tables and div tags where content sits, it's a layer, not just a file. We already seperate CSS, Javascript, and other like concerns but not the inner page code structure, and I'm not just refering to physical speration. It's just assumed that by the time you get to the actual view programming that you'll be able to just do it, no planning or formal organization required.

I'm not talking about architecting the view in an object oriented manner, that's just too much. I believe the view can benefit from organized structuring of page concern seperation and we want to use this technique in planning and in coding. To demonstrate this I'm going to create a simple and quick fictitous site with a few views in an MVC structured application.

Here's a draft of a UML class diagram showing how I might plan my views and view layers on paper. Notice that my page views are now represented as classes with properties and methods. Keep in mind that UML diagrams and planning is an iterative process and will change quite frequently but, we must start somewhere.

Notice first the hirarchy from Application through layout and to individual nested pages. These are connected to show how each page view inherits it's elements from upper view layers. I'm not advocating that this is the right way to diagram or think of it, just my way for now.

The application node is the top node here and has properties and methods you should recognize. This sits in the view layer in an inner application layer. An application layer in my mind can also include other nodes like UDF and configuration files.

Inner view layers:

    Container layer - the top most containing layer surrounding all other inner view layers in an application. All other view layers inherit from the application layer.     HTML layer - Defines containers and layout structures in which to place content.     Content layer - Contains the content of page views and any externally viewable content media they may include.

My site has a default_layout page that displays content layers, and as usual frequently repeated elements across multiple views are located here too; ie the header, footer, and navigation. Notice it's properties here. The value for jsDir will be the physical path that will be used in the source attribute of a script tag or anywhere else we may find a need for it. For example:

The homeLink property has a value equal to the actual href tag, the link back to the home page. And in this property we can edit the link as needed from one easy to find location in this view. The default layout view here also composes of the CSS, the JavaScripts, and anything else you would need to include somehow. These inclusions, not expanded here, could be psuedo classes with properties and methods as well.

Moving down the view layer we have the content layer view nodes which is the meat of our site to the user. They inherit properties and methods of the layout layer as well as defining their own. In this diagram we can see what the content views inherit, most useful when trying to remember what your content view pages are capable of before any code goes into it.

Starting with the home content view I created a userListLink property containing the href link to the userList content view. That property can be used anywhere in the home content view.

Next, the userList content view will output a list of users that we retrieved from the control layer after being queried and cast to an array in the model layer. So the users array will be a property of array type. Notice I don't type simple properties such as strings. There are two other properties, listPerPage (how many to paginate per page), and userDetailLink which is the href for the link to the userDetail content view. Here we also have methods for this view.

The userCountTotal() function placed here for example is a simple function the view can call from anywhere to get a value. And no matter where or how many times this function is placed it can be altered from one location.

Let's take for example the next function, wTitle(), to see how this works in practical code. The purpose of this function is to encapsulate a piece of content and seperate it from the views tables and divs, making the design much easy to read, move around, and format. The best way to show this is probably a before and after example.

Before using view layering:

After using view layering:

Notice how we took out a huge chunk of content making the layout much easier to conceptualize and edit. This also lends to seperating concerns for content programmers and design layout artist. In making these separate I usually rule out any chunks that are either small or contain more layout code such as td repeaters. All I want to be left with below the content functions is basically a skeleton of table and div tags.

The userDetail content layer view has two properties. User is a user object passed in from the controller and the userListLink is an href string used to link back to the userList node. There are two functions used to output content, wUserImage() is the code to output the image for the user. The wUserDescription() function is called to format and place the description block how and where you would like. Think of these functions as an easy way for a layout artist to place content within his work that the content programmer has already developed. These functions could also take in arguments if the programmer feels witty. Then a view layer API can be documented and used by the design artist.

What I'm doing inside the views to seperate content and layout design isn't as important as the benifits realized from the view layer model in the design phase. The other models such as those in the model layer can now be associated with nodes in the view layer. Eventually I want to produce a document where every element that is a part of the process can be modeled to and from each other and between layers in a world view type map.

It's all pretty simple and not well thought out for now, the result of about a day of thinking. I do plan to expand it if I can't find anything comparable out there. For now it seems to help me a lot with organizing and visualizing page views. Esspecially when you consider that I'm already thinking this way for the other layers.

I'm completely embarrased to admit it but, I didn't know until yesterday that not only can I create my own web site's API documentation automatically but how useful it can be. Sure beats glazing over my directories and trying to remember where everything is and what it does.

My latest project has got me dealing heavily with application API's and it's important to read and understand how to apply the API to development, especially when using OO framework architectures. Reading and using the API's for my Coldbox framework (here) I got to thinking that having this documentation for my own site would be very useful and very cool. It literally puts OO into perspective, for me anyways since I like the API's, and helps me to visualize how my classes (components) are organized, if anything is out of place, and if I can optimize anything.

At first I was using the CFIDE component utilities (localhost:8300/cfide/componentutils/) like the explorer and the componentdoc. But it would always list packages from everywhere, including the CFIDE and WEB-INF folders. And then it would list the pakages from the mappings as well as the folder it pointed to. So I edited the code to exclude folders, thinking that there's got to be a better way, and there was. Looking back at Coldbox's API I notice it's from an open source RIAforge thing, get it here: CFCDoc. It's so easy, just extract the zip to your root under a folder, like '/api/' and go there. There's information about what to do next because all the packages you'll see at first are the one's in the /api/ folder you placed it in, not very useful. But basically you add or delete folders to include through a simple config xml file and that's it, your exploring your very own API.

Depending on the length you want to go to in your documentation you can go really wild with component and function attributes like hint and displayname, probably more too. Using these extra attributes I'm sure you thought were useless and time consuming you can add enough information to make the API a virtual users manual. At the very least you can use the API to match up with your UML class models. I'm thinking also that planning a site's structure could be done API style instead of UML style, maybe even faster. You can think of what classes you need and how to package them for your application doing API visualization. In other words, what should your API look like and is it all packaged logically from an API documentation perspective?

Before I begin let me just say that although I'm not a certified Java developer, which would make me an automatic OO guru, I do develop Flash and Flex applications using AS3, which is an OO language. Yes, when it comes to OO I know what I'm talking about and have studied and used patterns for a few years. I'm not a pure OOist but who is and who really needs to be?

I'm so tired of chasing that alusive brass CFOOP ring of knowledge, trying to become a an object oriented guru with the deepest depths of understanding. I'm already there and so are you, seriously, its not as far as you thought. And I'm talking to CF verterans that use cfc's as objects, and patterns (whether they know it or not) to solve problems. You may not be using pure OO but you are OOing purely enough. For those reading this that know nothing of OO please stop and go read a few beginner OO basic articles and then come back.

There's only about a 10% difference between OO in an "OO language" like Java, and OO in the ColdFusion scripting language. And that 10% difference is used about 1% of the time. So you can't create interfaces (technically you can with underlying Java), big deal, and completely irrelevant too. Creating "I" classes is simply rewriting the original class in a more impressive way and there's only a 1% chance you'll actually need the real thing. Interfaces for the most part are for compile time error checking and CF is not a compile time language, not at our level it isn't.

Let's see, what else is there that I'll probably never have a need for, or can do in some other CF way. Overloading, constructors, overriding, and multiple inheritance, and that's about it. As for the constructor, we use an init function on object instantiation as a consturctor for now but, CF 9 will have implicit constructors. Overriding can be accomplished in CF using composition. BTW, implicit getters and setters will be available in CF 9 also.

Other than the lack of multiple inheritence (which isn't a requirement to be considered a true 'OO capable' language, like Java and Smalltalk), if Adobe added overloading capabilities then CFers could be concidered OOers too. And just like a Java coder can produce crappy non-OO code so can a CF coder create crappy non-OO CF code.

Here's the thing though, follow me. ColdFusion is a RAD tool that can be structured in an OO way following proper OO techniques. ColdFusion is OO when and if you need it to be but we certainly don't want it to be totally and purely OO, ever, EVER. If you make it pure OO say goodbye to rapid development and say goodbye to the market it is ment for. OO was devised to help solve complexed problems in very large systems, something that CF can but doesn't do much of. Those complexed and very large systems are far and few between, the market is in the average system, which don't need OO much any ways.

All that being said, if you've got the jest of OO terminology down and have enough understanding of the underlying principles that you can apply it safely, stop worrying about it and get back to work. The only way you can become a better OOer is to practise it. And as for those Java guys laughing at us CFers when OO is mentioned, they're just trying to chase away the new kids in their OO sandbox, spoiled sports don't want to share the spotlight. Honestly I don't consider anyone an OO programmer based on the language he uses, it's how he uses the language that defines a programmers OO understanding. And if people will stop refering to CF as it was prior to the MX version we'de stop having this debate in the first place. Once apon a time, ColdFusion couldn't be architectured with OO principles, but now it can. The end.

Saying that you don't need OO or MVC to build a ColdFusion application or web site is like saying you don't need blueprints and building code standards to build a skyscraper or a house. Granted, blueprints are overkill for a birdhouse but, OO and frameworks are overkill for a one product web site too. You should know when all the overhead is needed and when it is just going to be overhead. To me, it seems like this is the real problem when it comes to utilizing more sophisticated coding techniques rather than just plain old coding.

In all actuality most of the complaints, confusion, and questions come from weekend programmers who don't need to concern him or herself with such extremes. But they make a mountain out of a mole hill (or an application out of a web site in this case) because they want to hunt with the big dogs or think they need to or should, or they just feel inadaquite if they don't. I don't blame them, I did too, and I wouldn't be where I am today if I didn't venture into the world of software engineering. But all that stuff didn't add anything positive to my low level projects at the time except taking more time to do it, so be careful.

Here's the honest to goodness truth about using all that fancy stuff. Any site or application created using any of that overhead can be created just as well with straight down proceedural coding. The end user, and sometimes even the client wouldn't know the difference between one and the other unless you pointed it out and showed them. In all frankness, only about a quarter of web sites need to bother with anything more than simple code, yet three quarters of web developers think they should.

My advice to web development noobs is to stick with the one thing you need to get the job done unless and until that job requires more than what that language can do efficiantly on it's own. Who knows, you might develop a simple site that makes you a millionaire without ever knowing what OO is. But if that site begins to grow unwieldly with errors coming from nowhere, it's time to turn to more sophisticated techniques. It's time to use MVC, properly incorporate a framework, and maybe even learn some OO terms and patterns. Then the question "when should I use the fancy stuff" becomes "how, what, and where do I use these".

Personally I use an MVC architecture on anything over a dozen pages, frameworks on anything with more than a few applications, and OOD/P on anything considered an enterprise. If you must, its important that you be able to do these things with professional precision to get something out of it. Your not going to get any ROI using a framework on any application if you've never used one before, so don't practice where your paycheck comes from.

MVC is a term used to describe a seperation of concerns, the business model, the user interface, and the central controller. It's not a product and there is no one right way to do it. As long as the thinking is done in one place, the displaying done in another, and neither knows about the other except through a controller, your using proper MVC architecture. Pretty simple right? If you only have a few events, or page views, then yes it is.

But, try rolling your own MVC on a medium size project and you'll grow to appreciate frameworks rather quickly. A framework is basically an MVC, structured and expanded for medium to large scale projects. That is, it supports agile development by not only insuring best practise MVC organization, but also offers commonly used programming logic in prebuilt API's. It's the foundation or base that will be the strongest part of your structured application if used properly.

Object oriented programming basically helps when you can objectify parts of a program into seperate entities and only if there will be a lot of them. In addition it's only benificial if those parts will be very active during the life of the application. By active I don't mean the use of the application, I'm talking about moving things around, enhancing them and depricating them, or allowing others to use them. If an object is going to be static in that regard, then it shouldn't be factored into the decision to use OO.

In summary, something important to think about while you hone your enterprise software engineering skills is that, as you get more comfortable with this sophisticated stuff you'll become more able to use those bigger skill sets on smaller scales. I for one find myself able to flesh out an OO UML model for a simple site in a matter of minutes. An OO noob might waste valuable precious days over the same thought with a negative ROI. So yes, you can use this stuff on smaller scales effectively when it becomes second nature and you don't have to think about how but what. As for all those naysayers that are swimming against the industry tide and trying to convince you that it's all uneccessary, they couldn't be more wrong. The storm is coming, mark my word. Maybe not in our life time but soon, developing web sites will be out of the range for the average Joe and the strongest of proceedural coders will be lost without keeping up. Stop pouting and start evolving, accept it, embrace it, love it.

Here it is in a nutshell. I have a controller cfc in my framework that directs execution instructions to the business model cfc's. But I'm wandering if I should pass whole objects, like a user object, and get values as needed from it's methods within the business model? Or should I just pass the object's properties to the business model classes as needed?

Another way to put it is this(model/securityService.cfc):

The business model gateway in this example would be something like(model/data/gateway/securityGateway.cfc):

Maybe because I'm not a seasoned OO veteran but I'm looking at this and trying to figure out the best course and can't decide which one to take. From the service cfc do I pass in the user object or it's properties (username & password)?

For now I'm passing the object's properties if the gateway method only requires data and doesn't need to access any of the objects other methods like setters. If the gateway method here needed to use the object's methods instead of just it's properties, then I'd pass the entire object. So what do you think is best practice?

I got tired of trying to get cfUnit working and all I wanted to do was test component methods. I wanted to be able to simply point to it, test it, and enter arguments if required. And I wanted this set up somewhere easy I could use quickly, repeatedly, effortlessly, and painlessly (word?).

In almost all my applications I have a 'webmaster' directory where I run test. Lately I've found myself getting fancy with setting up a web development control panel of sorts. Whereas web sites generally have administration control for admin users, I've been building in webmaster control for developers. Mostly things like server and framework info, links to documentation, framework and site functionality examples, and etc.

Now I'm adding a little CFC Test form where I enter my cfc path, the method name, and arguments. It will pass the event argument so you can also test cfc handlers.

Warning, I just created this a few hours ago. It's tested to work but I haven't cleaned it up or put in validation and error handling yet.

views/webmaster/index.cfm (webmaster control panel)

events/webmaster/panelcontrol.cfc (Coldbox handler)

Basically it loops through the method arguments list you entered in the form setting them as part of the arguments struct. That arguments struct is then passed to the invoked component and method, along with the event object. Then the view is set to output with the test results, whatever the method is set to return.

views/webmaster/dspcfcTestResult.cfm

KISS output.

Let me know if this might be a good idea to expand on or should I just LOL learn cfUnit? And the webmaster information and control panel stuff?

After working in Coldbox for a while I know your first instinct is to make a cfajaxproxy call to a cfc event just like all the other Coldbox events. However, using cfajaxproxy is just a little different. Here is an example to show you one simple way of doing it, not the only way but one of them.

First let me note that I am using Coldspring version of IOC. It should work the same though with any form of IOC. Mostly we need the IOC to provide the bean to the services your Ajax call requires from within the Coldbox proxy.

After having provided a service in Coldspring like so:

we can use this "usersService" bean in the coldboxproxy.cfc like this:

The code above is what the Ajax, cfcajaxproxy, will call as a method for Coldbox to perform. It fetches a private message object bean, sets or updates some properties, then uses the gateway to save the object bean. I don't have a return or output but you can do that also here if desired. And here is the actual view and Ajax calling code:

The cfc attribute is dot notation to the location of your coldboxproxy.cfc, mine here is at the root. Basically I'm showing the private message details in a div but needing to set the read flag in the database to 1 to indicate it has been read. And using Ajax I can set this in the database for each message read without a page refresh. The alerts in the javascript are for demonstration and testing purposes.

The code I provided is a cut down version of actual code and does not include the view event, form code, queries, or other behind the scenes code. I hope this helps to give you a step ahead on how to use Ajax with the Coldbox framework.

Coldbox plugins are a really useful aspect of the framework when you want to create reusable interfunctions. Interfunction is a term for a function within an application that can be used in any application within any one specific framework.

Coldbox plugin interfunctions are, to me, like UDFs, almost. Except that they are OO capable components. But enough with talk, read more about plugins here.

And here's an example of a custom plugin I created called "MyUtilities" that has a function utilizing CF8's new image resizing abilities. It's not expanded yet as this is just what I needed for the moment on a project.

This goes into a cfc (MyUtilities.cfc) file in your plugins directory, I called this plugin "MyUtilities" for now:

And this is how you'd use it in your code:

You can see from the resizeImage function that I hard coded resize quality and antialiasing, as that is true anywhere in my project for all image sizing. But you can take this and customize it further for your needs. I just mostly wanted to share with you an example of using a custom Coldbox plugin.