This content has been marked as final. Show 7 replies
That concern is not limited to plugins only. Install any third party library, and run into an issue the support you receive is by the author of said library, and not by oracle themselves - as they didnt author it! In the end, you need to assess, should something go wrong, can you either get the support you require, or have the ability to fix the code your self.
The plugin code is available, in shared components -> plugins -> you can normally see how a particular plugin works. However, this is not always the case - some authors want to keep their code hidden well (probably if they have released the plug in under a commercial license), so wrap their code.
Anyway, if you're still worried- just code it yourself? In the end, you should be thoroughly testing your apps to ensure their will be as little issue as possible. If you test it well, you reduce the risk down the line of anything going wrong. If the tests fail, don't use the plugin and look at another solution. Plugins are not limited to those released open source. For instance, your organisation may have a common functionality in all your apps, so then you can create a plugin for your dev's to use. By documenting the plugin well, down the track if there are issues, you should be able to fix it.
And so, such tools sort of have a critical massI like to think APEX has a large population - that is every growing - helping out too. Look at this forum, their are people helping out every day.
Another concern is would the plugin code "survive" an Apex upgrade. I would hate to upgrade, say, from 4.0.2 to 4.1 and find that my previously installed plugins had disappeared.Of course, I'm not an Oracle employee, so can't speak for there future. But i'd be quite surprised if they didn't make the upgrade path for plugins as seamless as possible, in the event they had some core changes.
Just some of my thoughts.
Edited by: trent on Apr 14, 2011 11:07 AM
Also, Martin made some posts on his blog about some other concerns of plugins. Perhaps you'd like to have a read of them too:
Thanks very much for your thoughts.
I also followed the included links and read through the articles (including associated comments) on Martin's site.
The common thought in all of these posts is to be "cautious and, if possible, examine the code" and "test - test - test for scalability and correct function" before placing a plugin into a production app.
I DO wish that Oracle would follow Apple's lead and place all plugins published on apex-plugin.com to at least some sort of security checking for malicious code (SQL injection, for example). It would make using plugins far less a case of "user beware" and save much time trying to determine if the plugin code is safe. Some of these plugins have lots ofcode and it would take alot of developer time determining its safety.
In any case, thank you.
I will designate my question as "Answered". Still, I do invite others to share your thoughts on this important topic.
From a personal point of view, I would be very wary of using third-party plugins for something which is business-critical (say anything you would normally log a priority 1 or 2 SR for). If it's something which is a "nice to have" then why not? Of course you would want to verify the plugin first and ensure it wasn't doing anything undesired.
Your questions are very pertinent, I think.
I just want to share a real issue that we had (and are having) with an Apex plug-in.
We use the DHTML Dialog plugin (http://www.apex-plugin.com/oracle-apex-plugins/dynamic-action-plugin/dhtml-dialog_49.html) to create modal windows to display an Apex page on top of another Apex page in an iframe. It works very well and users love it.
The issue we are having is not directly related to that plugin, but rather to the JQuery Dialog plugin used by it. The JQuery Dialog plugin has a bug (or a feature if you like) in which it "evaluates" (for lack of a better word) the contents of the dialog at least twice: when the dialog is created and every time it is displayed.
So think about it -- every time we show an Apex page in a DHTML Dialog plugin, it is requested twice! This is a waste of server resources at best, or can generate fatal errors that are difficult to trace at worse if the page does some data manipulation in a page load process for instance.
I tried to contact the plugin author but I had no response so far. The source code is available (both JS and PL/SQL) and I tried a few hacks to fix the issue but no luck. So for the time being we decided to use that plugin only when really necessary and only for light-weight pages.
In my opinion, plugins should be used only when really needed, not just because they are available or because they make the pages look "cool" (except of course in the case of a public application where the coolness factor is decisive). Not having someone to ask for help (as in our case) is quite frustrating.
I like the idea in Martin's page of plugins certified by Oracle -- as long as "certified" means if there is a problem Oracle will help to solve it.
Sorry to be "away" so long from monitoring this Forum. Have been so busy with work, I've not had time.
I read your post with much interest and am glad I'm not alone in my concern over the use of Apex plug-ins in a production environment.
As already mentioned, I wish Oracle with take "ownership" of plug-ins, similar to what Apple, for example, does with iphone apps. My understanding here (and forgive me if I am mistaken), one cannot just willy-nilly make an iphone app publically available until it has passed some testing rigor. Furthermore, Apple supports any issues with it. One need not hunt down the app owner for help.
I wish the Oracle/Apex team would do likewise.
Oracle created this very useful feature for Apex, incorporation of third party tool-lets. It also needs to provide oversite for them.
Hi Elie,1 person found this helpful
I think it would be a shame to disregard such a useful feature as plugins for production systems just because they are not all produced as a supported product.
Thanks very much for your thoughts.
Truth be told, I like plugins and want to use them.
What you've said I think is probably the best and most realistic advice -- know how the code works and, if placed into production, take responsibility for it.