I dig the Java Objects. We are using org.safehaus.uuid.UUIDGenerator to generate GUIDs on the fly and I created a wrapper service so it could persist in my model and be auto-wired etc. It would have been nice just to give it a name directly in the model.
Of course, if I need to perform initialization on it before it can be used, I might need to put a wrapper around it anyway… ponder
How would we handle model caching with java objects etc that we wished to be transients? Do you forsee this as part of its definition in the model config, or would a component wrapper need to be placed around it with the appropriate cache and cachetimeout meta attributes?
Not to derail at all (I really like this conversation) but I'm about
to start implementing a bunch of GUID-related work in an app I'm
developing. Would you mind sharing the work you have so far with
UUIDGenerator, Brad?
Thanks and I'm really looking forward to implementing Groovy in my
model layer. I've got a coworker who has done a fair bit of Groovy
programming and is loaning me his book soon. Looks very cool and I'd
love to use it with Coldbox.
Funny you mention groovy, because we are also working on an addon to coldbox that could help you integrate with groovy/java model layers and even do cf/groovy/java hybrids.
The key is workflow and have the grunt work pre-wired. Anyways, these ideas are preliminary but promising.