I often override DfSysObject.init() in my TBOs and never really thought much about it but considering it isn't a doXXX method am I setting myself up for problems down the road?
Thanks,
-Mark
If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.
Mark,
as long as you (obviously) extend instead of overriding (i.e. always call super.init()) you should be safe. Especially if you do dynamic inheritance e.g. then you want to make sure "the other inits" of any supertype is called as well. One caveat is that init() won't be called if the object is cached.
Other than that you should be safe.
Ingo.
Thanks, I always call super.init() and the fact that it won't be called on cached objects is probably fine since I usually use it for initializing new objects with specific attribute values. EMC should go ahead and make a doInit() method though, just so I'll feel more secure
I just posted a blog about how I got burned by a non-doXXX() method override in a TBO. (http://msroth.wordpress.com/2012/12/17/burned-by-a-tbo). init() seems safe, but my concern would be, as I expressed in the blog, that if EMC changes the internal implementation of the DFC, init() may not get called when you think it does. And that can cause all sorts of unexpected behavior.
This sort of thing becomes unnecessary with D2 v4 and xCP v2.
Hi Scott, yes I read your blog regularly and I saw that. Could be why it had been bothering me on some subconscience level. Unfortunately, the way D2 is licensed will probably prevent me from ever getting to use it in my work, but even if I could I think I prefer BOF over configuration of a user-interface. That's for people who can't code. BOF feels more like freedom to me. Maybe I'll change my mind if/when I get burned by a TBO but I'm trying to build a framework that will be able to cope with such things.
I fully agree, but the way of the future for Documentum seems to be these two platforms (D2, xCP). In xCP training a few weeks ago, we were told that TBOs are all but extinct, the preferred method implementation of the same logic is a business object with a stateless process (xCP) or a creation profile (D2). The configuration isn't really in the UI, it sets up objects and rules in the repository, similar to a TBO. And like TBOs, the business object rules always apply. (A business object has no relation to a BOF object, it is just an unfortunate name.)
Good information, but what about those people that aren't using D2 or xCP, and have no plans of doing so. We will use xCP in a limited manner but by and large it will be WebTop for 90% of our users for the forseeable future. So we don't really have a choice but to continue doing such customizations with BOF development.
Only EMC can change that, but to do so they would really need to something major with their licensing to get my company to even consider it. Not likely to happen. In fact, (I work for a government contractor) all I hear these days is that we should be considering a move to something like Alfresco over the long-term.
So, in preparation for that possible eventuality, we are trying to move our document object models and processes to be as generic as possible and to make as little use of propriety tools that will lock us in to doing something in some way that we can't easily port to another vendor. I am not at all happy about that since I have nearly 14 years of Documentum experience, but it is beyond my control.
That said, beyond licensing costs I don't have a problem with D2 or and I actually really like xCP, but I think the customer should always retain the ability to do BOF and EMC should continue to maintain and enhance it, actively developing it.
Just my opinion though, for what it is worth, but in light of what I've learned today, you can bet I'll be having a disucssion with my account manager soon.
Don't beat up your account manager too badly, TBOs, Webtop, WDK, etc. all will be supported for the foreseeable future (through the lifetime of D7 anyway). By then, licensing issues will have all been resolved, xCP will be too awesome and ubiquitous to ignore, and technology will have rolled over 3 times (at least). ;-)
Mark, the example of customizing the init() method is actually also in the DFC advance training material...
By all means EMC should continue to develop BOF, regardless of whatever else they intend to do. It should keep pace with the technology changes. I'd like to see something equivalent to BOF enshrined into the platform for all time. Sure the technology will improve but there should always be a way to do essentially what BOF does, in the way that it does it, regardless of what happens with the technology.
All other ways of modifying the out-of-the box behavior of Documentum content are high-level abstractions reliant on some product or service and are designed with the idea that the most important principle is ease of configuration, even if this means sacrificing power and control. BOF gives control directly to the developer, requires no additional, separate product licenses, and provides the kind of control, that once given, cannot be taken away. Or, at least, should not be.
I'll try not to be too hard on him
Scott, not quite sure but I do vaguely remember reading something in the release notes or the documentation about that change. Well somewhere in one of the docs I normally ignore...
That's cool. I don't think I've ever seen that material. Is it something you can post?
