This content has been marked as final. Show 20 replies
you got my vote for this. The first thing I do whenever a new technology stack appears with JDEV (or better in a demo), is to scan the sources for code which is helpful for my own development.
In my opinion the ADFUtils and JSFUtils are indispensable for ADF Rc development. There is so much to learn that I'm glad someone helps to get the basics right.
I agree with this idea. Meybe it would be helpful to start on Oracle Wiki topic: "My faworite helper methods".
Personally, I'm +0 with that. We often create those classes in our projects, but not with the same methods, and even when using the same methods we don't always implement them the same way (especially for JSFUtils). So having two classes with the same name on our classpath could get confusing for some developers, but then again we could simply tell them to always use our version.
I get your point Simon.
However I think you need to think further than just your project or organisation. If you employed additional JDev/ADF staff, at least they would (should!) have used a standardized class(es) from Oracle, rather than a custom project one. This flows on to maintenance benefits, because you should be able to guess how the programmers have done things in the backing beans thanks to the standardized classes on all projects across organisations, rather than trying to work out how every single project (potentially) has done it their own custom way.
At the moment ADF BC pretty clearly dictates how to do things because of its plug in framework (ie. create(), remove(), doDml() methods), but the backing beans are left fairly up in the (pojo) air, so it would be nice to see some commonality applied to the BBs out there. This would be a good start.
....you knew I was going to ask....
...if you've got a better set of classes, feel like posting it on this forum?.... or a new JDev wiki page as was suggested earlier! ;)
Have a good weekend :)
I agree with Chris and Kuba - where new developers can't do stuff declaratively it would still be better to use a standard method to do something rather than cutting and pasting snippets of code. Plus library code designed for re-use tends to be more robust (e.g. in error handling).
Of course from Oracle's perspective to integrate this into JDev/ADF Installer would mean additional code management (including enhancement requests etc), testing and documentation. Maybe it would be better as a separate "unsupported" OTN download (a bit like Forms WebUtil started). Alternatively it could be entirely community-driven (e.g. a SourceForge project) but that could make it more difficult to encourage widespread adoption.
It would also be interesting to hear how the Fusion Apps developers have approached this too as they must have had to build some fairly comprehensive utility class libraries...
"Of course from Oracle's perspective to integrate this into JDev/ADF Installer would mean additional code management (including enhancement requests etc), testing and documentation"
Bah! That's their problem! :P
And regards your comments about Fusion Apps developers, yes, they seem awfully quiet don't they? And for that matter, the rest of the JDev team on this thread!! ;)
Thanks for the comment user645894. Unfortunately http://myforums.oracle.com/jive3/thread.jspa?threadID=223104&tstart=0 doesn't seem to be accessible on the web - any chance you could cut and paste the relevant comments into this thread? (we're all friends here!)
It would be helpful to know from Oracle if something like this is already underway to save possible duplication of effort.
Well, we do always use the same classes, just not those of Oracle. However, you're totally right about the better implementation, I should really start blogging and publish those lines of code.
I was thinking about this for a while, but now that you brought this up ;-) I actually thought of asking for annotations for the most common methods in ADFUtils e.g. get the bidning
Maybe a good idea to have this discussion opened up. So what do you think would be the best option.
a) shipping JSFUtils and ADFUtils with JDeveloper where developers can extend them to build their own copy
b) providing annotations for common functions identified by the community - some kind of collaborative work as suggested by Chris - and leaving the option of using extra JSFUtils and ADFUtils libraries to individuals
Ps.: note I didn't yet created a testcase for the annotations
Ah, the ugly can of Java annotation worms. Sure you want to open it? ;)
Personally I'd love to see annotations introduced to masively reduce the complexity of Java JSF beans, and also the Java ADF BC side.
One of the bits I see students really struggle with when teaching JDev is the unnecessary exposed Java methods in the ADF BC classes, such as the EntityImpl getAttrInvokeAccessor, setAttrInvokeAccessor, createPrimaryKey. Beginner non Java students really can only think about objects like POJOs, they struggle when they see lots of framework code added. As such hiding the detail using annotations should in theory make this eaiser.
Regards the backing beans and injecting the binding container, iterator etc. I note between JDev 10.1.3 when it first came out, we were injecting bindings via the faces-config.xml file. This worked badly because new users struggled with getting the config file entries exactly to match the backing bean properties and accessor names.
Then ADFUtils + JSFUtils came along which meant no injection was required, but now people are struggling with what to cast the result to (using something like JSFUtils.resolveExpression). As they don't inherently know the binding classes, what to cast to becomes a problem. The IDE doesn't help with this at all either.
As such with the annotation approach, this would be better as the annotation would take care of returning the correct binding classes. This would take us to the next level. Also as the IDE would inherently know which binding class, then users would be better off in understanding the binding layer classes and which methods to call thanks to the code completion facilities. Of course it means someway of associating a backing bean with a particular page such that the BB knows which binding container to get, which iterators to include etc, and if the binding names are changed in the page def, the BB would automatically change its names (I figure you'd have to do this for beginners, otherwise they'd get confused).
However, I think there is still a need for ADFUtils and JSFUtils even with annotations because there will be times where you want to do something that isn't provided by the annotations.
sure there will always be a need for JSFUtils and ADF Utils, but these could be then maintained by the individual developer based on the existing libraries.
I believe that it wont be possible to make it right for everyone and therefore I propose to go with a solution for the most common "shortcuts" first and then over the time add more to the common functionality. So we may want to call for a public voting to some point in time plus an option to suggest more.
As sad as it is, Java and Java EE never has been designed with beginners in mind ;-(
I think that these kind of toolkits are a great shared community resource and should be maintained in that way. I don't believe that they should be baked into the product, all they are doing is saving you a few lines of code, and not (necessarily) showing you the "best" or most efficient way of doing that, just a way that the original programmer (ie. Me) happened to pick.
So what we need here is a community forum for managing such code samples and that's something we're working on.
I let this discussion to grow while I was thinking on Frank's proposal (annotations).
I think that annotations are good idea. They make code simpler, more readable and streamlined (making easier for beginners to learn the patterns). On the other hand, the higher level of abstraction can be implemented in (annotated) JSF/ADFUtils which may follow the evolution of framework driven by community incentives. This would make a perfect compromise.
While Java is not created with beginners in mind, it evolves with productivity in mind (including better "usage" of juniors for mass production). Annotations are just for that – modern and productive.
I personally don't like the annotation abuse either, and I think they're getting quite out of control lately. As for the specific ones proposed here, I don't really like them because they would really simply replace a getter method evaluating an EL expression but, at the same time, be more dangerous than the former since it would be enforced only upon bean creation. Such limitation would force request scoped bean usage, and when that's the case, I prefer using XML injection as it allows better separation.
I believe annotations should have been kept to marking entities, not processing, but then again I guess that's the purist in me talking.