> > You can't use Plum in conjunction with Fusebox or any other > framework,as there would be no need. There is nothing that > another framework could add to what Plum already has. >
That statement nicely sums up a couple of resons why I will probably never use Plum. In its current form at least. If I can't used it in conjunction with Fusebox or any other framework it must be putting some pretty severe restrictions on the freedom I have to make decisions about how to structure my application. Assuming that another framework couldn't add to what Plum does is pretty arrogant and not a little bit short sighted. As a simple example, how well does Plum cover the things provided by a framework for simplifying the use of Event gateways? I have downloaded and looked at Plum a couple of times. I didn't care for the structure of the applications it generated and I didn't like the code it generated either. That's not to say it isn't a great tool. It's just not something that I can see providing *me* with anything other than frustration. The specific things I don't like: * I dislike code generation wizards. They assume too much and are practically impossible to build in a way that doesn't do that. * I dislike anything that auto-generates code unless I have control over the templates for that code generation. * I distrust anything that presumes what the directory structure for my application should be without knowing anything about the application itself. * Once I have created the application structure using Plum I am effectively on my own when it comes to editing it. * If I want to customize the auto-generation code for something like a form I need to modify some of the core Plum files. What happens if I upgrade Plum to a new version, or if I make a change that has an unexpected consequence elsewhere in the Plum framework? * There is little in the way of data encapsulation. Shared scope variables are used widely throughout the core files rather than being passed in as attributes to custom tags, so if I create a variable in one of the shared scopes I can easily introduce a bug which affects the framework. * In the few times that I have played with Plum I have always got the uneasy feeling that it would be easy for a client to introduce a requirement after the initial project release that would require the modfication of some of the Plum core files. Without understanding exactly what the entire framework does internally that exercise could be very prone to introducing bugs. Essentially my unease boils down to the feeling that Plum does too much in the way of generating application code and too little in the way of providing powerful APIs that can be extended and used by a developer without ever needing to know how the internals work. Spike -- -------------------------------------------- Stephen Milligan Code poet for hire http://www.spike.org.uk Do you cfeclipse? http://cfeclipse.tigris.org ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:195252 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
