Heres my thoughts on autobean thus far:
- I really like the concept of putting up a OO facade to your actual CFC objects. So that in many ways you kind of tightly control your objects interaction with in many ways the view (while still having your own Object controllers/service/facades). (Sad part is, if they are accessed elsewhere? not via autobean.. ie setters/getters emulation.. that could be a weird exp).
- I really like the import() functionality. We have a situation here were we have multiple objects instantiated in Server scope (as multiple "applications" use them and rather then instantiating them in every application scope, we'd do it once and if its already done, cool else load it. That was really cool approach to simulating the "Import" concept in other languages.
- I'm still in many ways a bit clueless as to how an automated setter/getters work but i'll read some more i think.
- Not exactly fussed about the exception handling but as we have our own way of handling this in many forms and i think it goes against our intial framework. Also if you your own persist level, and in our case we are caching data simply because our database is really old and i'm more inclined to leave the actual caching to the persist.cfc as its the only one that needs to know (ie tests if that static query is already cached if it is, it knows where to get it, in order to feed it back up through the object chain etc).
But its a great concept, it still feels like its trying to emulate something CFMX isn't but its nice just the same.
Regards Scott Barnes
Robin Hilliard wrote:
Tim Lucas wrote:
What is this 'framework code' you talk of? It isn't a modified version of Farcry is it?
-- tim
Hi Tim,
No, it's a framework called autobean I developed in my own time after MXDU to help make development with CFCs faster and the resulting application more scalable - I had sent it to Barrie and a few others off-list. A short list of features:
- Pooled instances (you can write a whole app in cfcs but then have almost all requests never calling createObject),
- Support for interfaces (should have been in CFMX from the start IMHO),
- Definition of properties via cfproperty to support automatic getters and setters and provide info to an extensible persistence service (commit function copies all updates and creates back into whatever persistence implementation is provided),
- Cache function return values and exceptions, and
- Hierachical locking (so that a lock named "a" will block "ab", "abc", "aeee"
I used it on a Flex/CF application currently in production at Macromedia. Main problem is that there's no documentation (although there are pretty verbose comments in the code) and I'm in the process of refactoring it into a new, smaller framework with one extra core feature that I've since worked out how to implement.
I'm happy to share the code with people, contact me off list if you want to look at it. I don't want to put it up on an ftp site because without documentation it's really not suitable for general release, however there's possibly a bit you could pick up just reading through the code.
Cheers,
------------------------------------------------- Robin Hilliard Partner RocketBoots Pty Ltd Professional Services for Macromedia Technologies m +61 418 414 341 f +61 2 9798 0070 e [EMAIL PROTECTED] w http://www.rocketboots.com.au -------------------------------------------------
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
