tag:blogger.com,1999:blog-38586079.post8388401367762664520..comments2024-01-22T15:27:00.730+08:00Comments on One size doesn't fit all: ADF BC Groovy – showing old values along with new part II – via ViewRowImplChris Muirhttp://www.blogger.com/profile/06566648350240654621noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-38586079.post-38928610663989045652012-12-19T12:37:37.274+08:002012-12-19T12:37:37.274+08:00You can create a transient attribute in the Entity...You can create a transient attribute in the Entity that displays the posted value using a Groovy expression<br /><br />Put this in the expression<br /><br />adf.object.getAttribute(1,(Byte)1)<br /><br />First attribute is attribute index, 2nd attribute 1 means ORIGINAL_VERSION 0 means CURRENT_VERSIONDon Kleppingerhttps://www.blogger.com/profile/02266023115878336856noreply@blogger.comtag:blogger.com,1999:blog-38586079.post-29239465480827253152010-02-12T06:03:05.637+08:002010-02-12T06:03:05.637+08:00That'd be the exact example where you should u...That'd be the exact example where you should use the supplied accessor? Still not sure what you're trying to emphasize when I did it in the original post. I've told the reader to use the accessor, the one generated by JDeveloper, to avoid issues where getEntity(0) doesn't perform as expected. Obviously if the accessor then calls getEntity(0) and it doesn't return the primary EO for the VO, then it would be a bug in ADF.<br /><br />John, I think our crossroads here is you'r etrying to emphasize protecting programmers from themselves, while in this post I'm more interested in the technical technique.<br /><br />CM.Chris Muirhttps://www.blogger.com/profile/06566648350240654621noreply@blogger.comtag:blogger.com,1999:blog-38586079.post-7435481489504122352010-02-12T02:31:00.927+08:002010-02-12T02:31:00.927+08:00Hi Chris,
getEntity(0) -> what if the VO is ba...Hi Chris,<br /><br />getEntity(0) -> what if the VO is based upon multiple entities, and the attribute you're interested in comes from one other than the first...John Stegemanhttps://www.blogger.com/profile/10099907629085401995noreply@blogger.comtag:blogger.com,1999:blog-38586079.post-44732545426888799592010-02-10T20:11:35.390+08:002010-02-10T20:11:35.390+08:00Hi John
That's what I thought I pointed out, ...Hi John<br /><br />That's what I thought I pointed out, it's my specific use case, that's why I spelt it out in the opening paragraph.<br /><br />Regards your point about the protected method, in this case I don't see any issue in doing this. The method being protected, as you know, would therefore be available to the EntityImpl to use. As such if the method's functionality changed, it would break the valid EO case in the original part I post, as much as it would break the VO usage. As such we're as much (in the limited assurance we have Oracle wont change how methods work) protected by this protected method's functionality changing if used by either - it's the same risk.<br /><br />However I'll agree that pointing this out to beginners isn't necessarily a good idea, but as I said at the end of the post - your mileage may vary.<br /><br />Finally I'm not sure I get what you're saying about the getEntity(0) method? In step 3 I explicitly tell the reader to check that the framework has created a named accessor (ie. getEmployees - that example was created by the framework) and use that instead, rather than calling getEntity(0) directly in step 4. As I said "I'd be cautious on doing this [using getEntity(0) directly] as you're relying on future upgrades of the framework not changing what's at position zero." Obviously if the framework generates an accessor method for us to use then we should use that instead, which will protect us against the internal mechanics changing, based on the assumption if Oracle does change the functionality, in the upgrade utility, they will change the accessor methods appropriately too.<br /><br />Cheers,<br /><br />CM.Chris Muirhttps://www.blogger.com/profile/06566648350240654621noreply@blogger.comtag:blogger.com,1999:blog-38586079.post-86215452804063995152010-02-10T19:20:09.723+08:002010-02-10T19:20:09.723+08:00Chris,
cough, cough *hack* *hack*
For some reaso...Chris,<br /><br />cough, cough *hack* *hack*<br /><br />For some reason, I get a *hacking* cough when reading this.<br /><br />No reason that this won't work, but one of the reasons of protected methods is to hide things from callers that you shouldn't rely on, so you're breaking that principle.<br /><br />Another thought... as you've written this, it won't work directly in the general case, say for example, if you have a VO based upon more than one EO, as you explicitly call getEntity(0).<br /><br />This may work for your specific case; I just wanted to point out those issues.<br /><br />Best,<br /><br />JohnJohn Stegemanhttps://www.blogger.com/profile/10099907629085401995noreply@blogger.com