We upgraded the sitecore from 7.2 to 8.1. Since the upgrade the content authors are complaining that the experience editor performance is much slower than previous version. It takes long time to load and also editing experience is very slow as well.
For now I've reverted back to SHEER UI version of experience editor by updating experienceeditor.config.
I read this blog post below but option 1 and 2 states "be aware that there are significant consequences...".
http://kamsar.net/index.php/2015/02/sitecore-8-experience-editor-performance-optimization/
Has any one experience this issue? And have any recommendation for the fix?
Thanks.
Reverting to SheerUI is probably an option you could consider... we know it works faster that the SPEAK UI, so it's a quick win to help out your content editors at the moment.
However Sitecore is moving towards SPEAK, and so I'm not sure how long the SheerUI interface will still keep up with the new features of the Experience Editor.
In addition to the pre-compilation of Views, you COULD attempt Kam's optimization, but as he mentioned, there could be significant issues that come about because of it.
I would also have a look into some other possibilities for speeding it up, like:-
Use the application cache to increase the performance of loading the
Experience Editor ribbon. - (https://doc.sitecore.net/Sitecore%20Experience%20Platform/The%20editing%20tools/Improve%20the%20performance%20of%20the%20Experience%20Editor%20ribbon)
Using ContentSearch instead of Fast Query for the 'My Items' count - (http://mikael.com/2015/12/speading-up-the-sitecore-experience-editor/), or even turning off the count altogether (http://sitecoreblog.alexshyba.com/hidden_gem_of_sitecore_page_editor/). UPDATE: Sitecore now has a Support DLL for this. (https://kb.sitecore.net/en/Articles/2015/12/04/14/31/549951.aspx)
Customize or even disable the SuggestedTestsCountRequest. - (http://blog.horizontalintegration.com/2015/07/05/sitecore8-experience-editor-slow/)
We are currently using Adobe ColdFusion 9 for a rather large application. We are thinking about moving to Railo or Blue Dragon.
What problems will we run into?
Will it require a large amount of refactoring or will most CFML code just work on the new system?
Do alternative engines provide support for most all official tags, or are they more limited?
In short, how divergent are these alternatives from the official language?
Is there anything we can do to make this process less painful (like upgrading to CF11 first or removing/avoiding certain features)?
My question is similar to What Notable Differences are there between Railo, Open Bluedragon, and Adobe Coldfusion?, but while that is concerned with practical differences I'm asking more specifically about practicality of transition/implementation.
It all depends on your code and the specific Adobe ColdFusion functionality that you are using. For the most part each CFML iteration supports the same tags/functionality. Where they deviate from the Adobe product is usually documented and explained. You need to dive into your code base and look specifically at the features you are using and compare those to the CFML engine of your choosing. Or you can just download and spin-up the alternate CFML engine, drop your code base in it and see what breaks.
As an example from Railo - CFML Compatibility
Railo tries to adhere the CFML standard as good as possible, Still there are some differences like missing tags and functions or a slightly different behavior. This page and the ones below should describe the incompatibilities.
And I have to question what you are basing this comment on? "and especially it's very uncertain future with them". You are running ColdFusion 9. Adobe has implemented two major version releases since then (10 and 11) and are currently working on the future release.
There are two main areas that can prove problematic when migrating from Adobe ColdFusion to Railo:
Use of feature areas that are not supported by Railo
Sloppy CFML code
The former includes integration with Microsoft technologies, such as Exchange and Sharepoint, as well as Office document manipulation; PDF forms and some of the more sophisticated document manipulations; UI "widget" integration. There are third party extensions for some of the Microsoft integrations, e.g., cfSpreadsheet, but for PDF-related stuff you'll need to roll your own using Java libraries (PDF forms and high quality HTML to PDF conversion are Adobe specialties so be prepared to do quite a bit of work in your migration if you rely on these). As for the UI "widgets", you're better off doing that the "right way" so if you rely on those, you should read ColdFusion UI The Right Way.
The latter is a harder issue to nail down. The differences are not well documented - except in experience posts to mailing lists and blogs by people who've made the transition to Railo - but they include things like:
Using scope names as variables (Railo treats scopes as reserved names for performance reasons)
Embedding comments inside tags, e.g., <cfif x gt y <!--- check boundary --->> (I've seen things like this in older CFML code and was surprised it worked).
Reliance on automatic creation of nested struct elements, e.g., a.b.c = 0 when a has not been declared.
Reliance on long-deprecated features, e.g., parameterExists().
There are many other small differences: Railo is generally stricter about syntax and semantics than Adobe ColdFusion, and often those decisions are driven by performance concerns in that compatibility with Adobe ColdFusion would make Railo slower.
Full disclosure here: I have used Railo pretty much exclusively for five years and I used to run the US arm of Railo's consulting business. That said, you need to consider that Railo is a small company (despite the backing of five fairly large former Adobe partners) with just a handful of people working on the engine, and very little awareness of the product outside the more leading edge portion of the CFML community. By comparison, Adobe have a large team and a marketing budget. Your concerns about the difficulty of finding developers will not be addressed by switching to Railo - to gain access to a larger developer pool, you'd really need to switch to a more popular language, not just a different engine.
Finally, a word about Blue Dragon's engine, specifically Open BlueDragon: the maintainers of that project have stated publicly several times that compatibility with the other engines (Adobe, Railo) is not a primary concern for them, and indeed there are a lot of modern language features that they still don't support or at least don't support in a compatible manner. Last I checked, full-script components were on that list despite having been supported in Adobe ColdFusion and Railo for many years (by which I mean using component { ... } rather than the <cfcomponent><cfscript> .. </cfscript></cfcomponent> form). The BlueDragon dialect of CFML has been steadily diverging over the years so unless you have very old school CFML, that would still run on CFMX7 / ACF8, you probably won't have much success trying to migrate to Open BlueDragon.
There are a couple good answers here and I appreciate the advice given in them. When I asked this question I was looking for something a little more specific, so now that I've had the chance to really play around with migrating our app to Railo I thought I should come back and list out the issues we've run into and, just as importantly, the severity and workarounds. Hopefully this will help others considering making the jump:
cfMessageBox:
cfMessageBox is not a supported tag in Railo. The best solution we've come up with is to create a new custom tag called MessageBox.cfm, then drop it into “{railo-install}/lib/railo-server/context/library/tag/”. This will allow it to be recognized as a core tag and referenced via “”, which saves us from updating hundreds of templates that call it. This, of course, requires us to create a message box custom tag from the ground up.
cfDiv:
cfDiv seems to be throwing a JS error when used to bind to a JS function. I'm going to guess that this is because JS binding is not officially supported (given that I can't find any reference in the official docs), and while ACF allows it as delayed execution, Railo simply doesn’t accept it. We could just create a custom tag that generates a JS setTimeout as described in (1) above, which solved our problem, but applications that actually use this tag for its intended purpose may have a more difficult road ahead.
cfWindow:
There appears to be limited support for cfWindow in Railo. Specifically, new windows need manually shown, and the destroy methods do not exist. Various other bugs appeared as well. We decided that it made more sense to just move to JQuery based modals.
cfLayout:
cfLayout support is questionable. It is based on JQuery and not Ext-JS like ACF’s version. This causes a problem because we run JQuery 1.10 right now and the built-in tag doesn’t appear to work beyond JQuery 1.8. In fact, I could not find any JQuery version within which the tag worked perfectly. We decided that it may be best to, again, just write our own custom tag based on JQuery.
cfDocument:
cfDocument works differently in Railo and seems to require more strict HTML. I found a lot of helpful information here, though as of yet I haven't actually gotten any of my cfDocument calls to work as expected.
Relative cfLocations:
cfLocations that began with a “../” and backtracked beyond the webroot would throw a weird Java error. This ended up being a bug in Tomcat, and was patched by the Railo team in version 4.3.1.003. If you download an older Railo version you may run into this issue and need to update all of your cfLocation calls.
Oracle Thin Client:
Our database guy reported to me that he setup the Oracle Thin Client, because the OCI client is not natively supported in Railo. I found this, which might be relevant, but I don't have the expertise to say for sure.
Documentation:
ACF Livedocs are sometimes aggravating as they don't touch on the more important intricacies of how some tags are implemented, but Railo's version is the definition of minimalist. I think it's fair to say that Railo has no docs specifying each tag and function and that they leave you to rely on Adobe for that, which causes a serious issue when you need to know how the two implementations differ.
In the end it seems like, as predicted by previous answers, the UI tags were the bulk of our issues. Based on previous comments I was hoping for better implementations of them that may just require a tweak here and there, but (at least for our needs) the Railo versions seem borderline non-functional and it looks like we would need to replace them completely. For us, this may not be realistic, though we are still tossing the idea around.
To be fair, here are some of the good points from our research and testing:
Performance:
Although compatibility problems have prevented me from doing much performance testing, initial spot checks show approximately a 50% decrease in execution time for most pages.
Debugging:
The debugging options in Railo are quite amazing. There are far more options for formatting, including specifying different formats for different developers (IP addresses). One incredible feature is the inclusion of a comma delimited list of query fields that were actually used in the page: this could allow you to effectively develop based on a "select *" query and simply copy and paste the fieldlist into the query at the end of development, which would save a lot of time with views as large as the ones we're using.
Cost:
This is one of the larger reasons we decided to look into alternatives. Switching just a few Enterprise licensed ACF servers over to Railo would save $20k+ over upgrading to the newest version of ACF. Further, with the performance increases you could see an even greater savings in hardware requirements. A side effect of this point is that one can keep far more up to date without the constant cost/benefit analysis of licensing costs holding up upgrades.
Support:
Without a support contract, it doesn't seem like Adobe responds to user concerns. I've had a production impacting bug reported since ACF 9 which still hasn't been fixed. Yet the Railo community is one of the most helpful and responsive I've ever seen, and developers have even responded directly to concerns and bug reports I've raised.
Longevity:
This is a highly opinionated point, of course, but while Adobe seems to be relegating ACF to the shadows more and more with each new version, Railo appears to be dedicated to growing the community. Combined with its open source nature I think this makes it a safer bet for future support in the long term, even if that support is just us taking development into our own hands when needed.
For a number of reasons, including divergent CFML compatibility, we did not even get to the testing stage with Blue Dragon.
For a custom wiki django-wakawaka, i want to be able to add a WYSIWYG support.
TinyMCE is obviously the most popular plugin, used even by Wordpress.
But CK-editor seems more feature full.
Those who have used either of these or both, which is better and why. Are there some better packages, that I am missing?
Is there something that I am missing when I conclude CKeditor is better, by going through them (because it is not as widely used).
I want to use it with django and jquery, with multiple instances of WYSIWYG widget per page. Does one offer advantage over the other.
I spent some time implementing CKEditor in the last couple days. I've implemented TinyMCE in the past as well. On the positive, it's far more consistent and bug-free than TinyMCE... by which I mean, where TinyMCE "feels" buggy, CKEditor has worked around awkward browser behavior to a much greater degree, making it "feel" much more solid. On the negative, if you want to extend it, the documentation is relatively sparse. I think this is mostly because CKEditor is relatively new (its API is very different from FCKEditor), and it would be reasonable to expect the CK 3.0 documentation to reach at least the quality of the FCK 2.0 docs soon.
I've been using both editors since some years ago... Almost always I've chosen CKeditor over TinyMCE.
The reason?
Short answer:
CKEditor is very stable and very easy to use and has integrated the file manager (with an ad, but it is no problem for me), but TinyCE has not any integrated File manager.
Nevertheless, I like JCE editor (for Joomla), this editor is based on TinyMCE and works like a charm. It has a very good implementation of File management.
If you plan to use a WYSIWYG editor for a wiki, any of them are ok, because you don't need a filemanager (I think).
However, I recommend you, based in my experience, CKeditor.
The long answer is very long for this space. If you want the long answer, contact me or google around about this topic.
A cople of other Wysiwyg editors
http://imperavi.com/redactor/ (paid - actively developed)
http://xinha.webfactional.com/ (updated 2010)
http://www.kevinroth.com/rte/ (updated 2010)
http://nicedit.com/ (updated 2008 - small fix 2012)
Because of the fact that my Internship has something to do with the CKEditor. I have been developing a lot with CKEditor the last 4 months. And as my research said: If we Compare TinyMCE and the CKEditor 4.x There aren't any big difference. The only differences are: CKEditor has a smoother layout and design, CKEditor has a lot bigger community (If i remember it right a difference of 13k (35k vs 50k i remember, something like that) and CKEditor has multiple developers. The last argument is an argument that i'm not sure off. But i have been told that TinyMCE is being developed by only 1 or 2 persons and the CKEditor by multiple (and an entire community!)
If you ask me, all in favor for the CKEditor.
The negative point that is stated once above, that the documentation isn't what it is used to be since the new version. I don't really agree. The only thing is that you need to read the API. With JAVA (as example) you won't find a full explanation neither. And the nice thing is that, I and many other persons are posting questions on StackOverflow. This will support all the support you need. And for the basics almost everything is there already!
And if we have a problem, there is always one of the Core developers of the CKEditor to help us out ;)
One big bug of TinyMCE is a when you copy and paste in TinyMCE then it does not manage any space or tab and indent it to the beginning, so TinyMCE is not good but ckeditore is a more powerful editor.
Currently our team is using MoinMoin as a wiki for IT and it's so nice.
We want to promote to use wiki for end-users because some of them are interested. On the wiki we'll share and edit requirements of aplications, for instance.
I think MoinMoin is not the more user-friendy (but I love to use it) that's why we are looking for the best user-friendly wiki for end-users/customers
For yourself MoinMoin is obviously user friendly. =) Seriously, consider all users and try to figure what kinds of usage patterns you have. MoinMoin is a reasonable choice since it's such a simple program. You can often help your non-programmer users by adding a feature or two to MoinMoin. Developers are up to speed with it and you have all the content there already.
That said. Mediawiki is used for lots of general wikis out there today. Including Wikipedia. An aspect of user friendliness is recognition. Mediawiki might feel more friendly because users are more familiar with how it works. And Mediawiki is widely adapted. Lots of extra features you might want to add to help your users are already written as extensions. And Mediawiki's extensions API is really good so you can easily automate your own verticals when the need arises. Mediawiki is reasonably feature rich without being totalluy overloaded. It has categories and templates which both come in handy for keeping things DRY and using the wiki in various processes. It shares lots of its syntax with MoinMoin since both have the same ancestor (syntax-wise).
I'd probably go with Mediawiki.
Visit Wikimatrix.org to determine what features you need and what tool is best for you. I often mention Foswiki.org as a very nice and userfriendly tool, but it really depends on the features that you need.
I have yet to see any Wiki that is more end-user friendly than Confluence.
Just the most important reasons:
While other Wikis say they have WYSIWYG editors, what they actually do is enclose selected text with markup when clicking an icon. That is not WYSIWYG, that's code injection! In Confluence 5 all editing is done from a visual editor (you actually DO see what you get right away straight within the editor). With the ability to add macros (markup) by powerusers.
In almost all other wikis the users are entirely responsible for creating and maintaining the link hierarchy. This means broken links and orphaned pages will be the norm. In Confluence all pages are automatically added to a page hierarchy and sorted by name. You can enable the tree browser via the Documentation theme to make browsing the wiki even without manually added links convenient. Lastly you have the ability to reorder pages in any order via drag & drop.
However, Confluence is rather costly for > 10 users. But well worth it if you can afford it, or you don't need more than 10 editors. Pure "readers" do not count towards users if anonymous viewing is enabled.
I believe we're moving to Oracle Apex for future development. I've read about Oracle Apex on wikipedia and it's pro and con. It seem to me the con outweigh the pro but maybe I'm wrong. I get the sense that Oracle Apex is for DBA with little or no programing knowledge to setup a web app quickly sort like MS Access for none programmer.
If you have Oracle Apex working experience, can you share your thought? From Wikipedia's entry, it doesn't seem like you need to know any programming language at all but just the PL/SQL?
edit: Is Oracle Apex scalable? Can it handle traffic like Facebook's size?
edit: after working nearly two years on Oracle Apex 3.2. I can safely said that I hate it and I don't see why anyone would want to create web app/page on browser, pl/sql and no way to do version control.
Thank.
Jack
Please note my experiences are with APEX 2.x-3.0.
I used Apex for a few internal apps over a 12 month period but eventually dumped it for ASP.NET.
Some Oracle evangelists claim it is capable of creating highly dynamic content on par with the more mainstream frameworks like ASP.NET/J2EE. Technically this is true, but then technically its also true that you could cross the atlantic in a one man canoe. If you are tempted to throw yourself into a APEX project of even moderate complexity then I suggest you look at the APEX sample of a simple discussion forum. Compare it to an ASP.NET MVC discussion forum sample or a RoR implementation.
Having said that:
The Good
Incredibly easy to generate a respectable web app with basic CRUD data entry, simple reporting and populate it with data. If you're the IT guy who's been tasked with consolidating a company's mess of Excel/Access dbs into a central DB/web environment then you should take a look at APEX, it very well suited for this task. If you expect the scope to grow to something of even moderate complexity then I would move straight to a more flexible framework.
If you are a DBA/PLSQL guru but have no experience with traditional web development you'll be well prepped to expose existing business logic in a web app without stuffing around with HTML/CSS/JavaScript if you dont want to.
APEX support forum has a ton of info and is well staffed by APEX devs.
The Bad
My experience with Apex began to go downhill when apps moved beyond CRUD data entry and required more dynamic and event driven behaviours.
The web based GUI is not cool. Debugging is painful.
Version Control? Who needs version control?
When you (inevitably) need to do anything outside the limited scope of the framework, you'll have to get your hands dirty with PL/SQL. Writing business logic against the database is fine, but generating HTML from PL/SQL procedures felt uncomfortably archaic in 2007.
Given the large number of sneaky places you can hide page and redirection logic, the program flow is both difficult to visualise and not naturally conducive to modular, separable and reusable code. OOP developers will be not be impressed. It's possible to have well structured maintainable applications with APEX but its harder than it should be. This is worlds away from MVC.
Unacceptable number of framework bugs in the versions I used. I'd hope this has improved with recent versions, but the paradigm of integrating the IDE into the APEX platform itself caused me some of the darkest, soul destroying debugging sessions of my life. As an example, I was trying to reproduce an intermittent bug that would cause a user to lose their session data. Using the session information popup I saw that occasionally the session data would change when it shouldnt have. I spent 2 days trying to find the error in my code with no luck. Near delirious, I noticed by pure chance that I could reproduce errorous session data in the debug window but the application itself wouldnt go into an error state. My heart sunk when I realised what might be happening. Oracle later confirmed that I'd found a bug in APEX that caused the session information window to intermittently show me data from a prior session. I'd wasted 2 days debugging a session related bug with a buggy session debug window. That was the last Apex app I built.
PL/SQL is not and will never be the Next Big Thing in web development. After working with APEX for a while I realised it wasnt going to make me a better web developer. Mastering APEX is really about PL/SQL. Thats fine if you plan to focus your career on Oracle technology, just be aware that APEX is so tangential to the direction of mainstream web technologies that the portable set of skills you can take from APEX to other web frameworks is minimal.
If you are considering APEX to provide simple web based data entry and reporting, its worth a look. If you are looking for an alternative to .NET/JAVA/PHP for dynamic web content and rich UI interaction I'd advise you to look elsewhere.
I read this page with great interest. Our development team has using Apex for about 2 years now, and I'd like to sum up our experience.
For building basic CRUD applications, Apex really is excellent. In fact I recommend you try it yourself. We did face some initial minor difficulties setting it up, but these seem to have been ironed out in the 3.2 release.
The good
Great for simple applications. If you app will grow in complexity, consider an alternative solution.
The built in templates mean your app looks quite professional (although some will debate this).
A good support forum and community, with plenty of eager people on hand to assist you.
Some superb built in controls. Love the graphs and reports (but see below).
The bad
The debugger is abysmal. If you have used Visual Studio (and even ancient versions of Microsoft Access), you will cringe at the debugger. No breakpoints, debug messages spewing out to screen in a big list, having to manually print debug messages to the screen. Horrible. The cause of many, many hours lost to support.
As soon as your application becomes complex or requires any rich functionality, you have to resort to Javascript and HTML / CSS hacks, which make debugging and support even more complicated (although you can use tools like Firebug or Visual Studio to assist with this).
We've encountered unexplained session state bugs, and stylesheets becoming 'detached' from the application without explanation - to name a couple of issues.
Supporting unfamiliar apps can be challenging, as it can be difficult to follow the page logic flow without a good debugger. And I don't buy the stock response of 'well - apps should be coded better'. Because in the real world, they aren't - especially when you're using a contractor.
Reports look good but not much good if you can't print them or export to PDF. Of course you can shell out for a reporting server, in the end we used another solution.
Overall
I would say by all means use Apex for simple CRUD apps. For anything of more than mild complexity go for .Net or Java. I wouldn't take any notice of the Wiki article on Apex as it's very skewed. Note how 'difficult to debug' (in my opinion the biggest failing) has been erased from the article.
Something to be very wary of as well is the ludicrous claim that you can quickly convert Access databases straight to Apex. Yes it will work if you Access DB is very, very simplistic. Anything moderately complex, forget it, as we found.
We would definitely not use it for web facing apps, only internal. There are simply too many difficulties doing things you would take for granted in say, .Net. I know there are sites out there such as AskTom, but these are not exactly complex. Will we see the next Facebook on it? I think not - although I am sure someone reading this will have a crack at it.
Apex is summed up in a previous comment - managers see the demos, and quickly buy in, convinced that they've found a silver bullet that will slash development times. I've had managers calling me and saying, we need a db app with 40 tables building in a week in Apex please - that's how far the myth has perpetrated. The reality is somewhat different. Yes some things are quicker, substantially quicker, but you will lose the time in other areas - debugging, support, and customisation.
Of course you are best deciding for yourself. Install it, give it a go, you may like it. But don't be fooled by the fast development time claims until you've given it a good going over on a realistic application.
I am involved in a huge project to migrate a 5000 module Oracle Forms application to APEX. This is an extreme use of APEX, but it's working just fine. It is a complete myth that APEX is suitable only for small internal apps built by DBAs, interns or end users: it is certainly suitable for those too (and more suitable than most other tools), but it can also be used to build extremely sophisticated applications.
To build a sophisticated application (rather than a default out-of-the box APEX one) you will need someone on the team with Javascript skills, and someone with CSS skills. But most developers will just need PL/SQL initially.
Is it scalable? Yes: probably more scalable than most other solutions! APEX adds very little overhead to the database server, and only the most minimal of application servers is required. "Facebook size"? I don't know for sure but I don't see why not, assuming you have an Oracle database on a machine large and powerful enough to handle "Facebook size" data and transaction volumes. Like any Oracle project, scalability is impeded mostly by bad database designs and poorly written SQL, not by the tool. Not many people ever find themselves building "Facebook size" systems though: are you?
APEX is a framework that uses the database and PL/SQL to produce web pages. If you can figure out what the output to the browser will need to be you can create it in APEX. If you find any part of the framework inhibiting you can write PL/SQL procedures and expose them to the web server directly but still take advantage of the security, logging, session state, etc that the APEX system manages for you.
You should know PL/SQL, SQL, HTML, JavaScript and CSS. Sure the interface looks like a big data entry application but the data you enter will mostly be code snippets in each of these languages.
It scales as well as the database does. It typically uses Apache as a web server but is only used to serve static files and pass requests back to the database, where the web pages are created by the PL/SQL code in the APEX schema. You can use AJAX to minimize the size of the traffic traveling up and down the pipe. You can set caching for specific items, lists, page regions, pages, etc.
Since most things are pretty simple to do with the framework, naturally there will be some things that are a little more complicated to do within the framework. The color coding example given above might be something you do with CSS or maybe you would need to turn to print statements to produce the output you need. The thing is to learn the how the framework makes life easier and then when you hit a limit you can easily resort to more direct methods.
Coming from VB.Net you will miss the step by step debugging and the drag and drop. You will never miss the fact that some part of the page lifecycle will do a bind and reset the values you bound to an object in another part of the page.
Good luck.
Greg
I am a DBA and I never had to program with APEX or recently anything else (aside some bash scripting and custom SQL scripts for administration purposes) because my job is far away from developing applications (except being pain in the ass of developers that is). Of course my background is developer though and I do believe APEX is future for strictly Oracle based data centric programs.
Now the keyword here is data centric since I disagree with many other DBAs that all applications are data centric (you know the kind of DBAs who still think ODBC stands for ORACLE Database Connectivity). Of course all applications involve data but are all applications data centric? I doubt, just as I doubt APEX would be ever used for image processing or mobile gaming kind of apps. However, despite all the hype with RIA and Web 2.0 the fact is most of businesses around us are hungry for those plain old data centric applications and Oracle is best database around and I can assure you Oracle and APEX can handle much much more than Facebook scalability provided of course you have put the same amount of money as Facebook guys in underlying infrastructure.
By the way I also hate Oracle's design of APEX themes (awful unprofessional UI, just imagine it as main UI for a bank or airline business), limited capabilities (although that seems about to change in the future), many many more issues (professional PDF reporting without paying amount of Enterprise Database license for BI publisher??) but most of all marketing of APEX as substitute of Access or Excel because it gives bad impression it is for kids and I can assure you my friend I would never allow kids to touch my databases :)
You see, Oracle has a gem called PL/SQL which was perfected over the years to handle data in much more intutitive way than any other language. Now that gem is withering with slow death of Forms/Reports and I am positive no fresh graduate will ever bother learning it strictly for database stored procedures (just see the raging war between Java and .Net developers and you realize that once you touch curly brackets {} anything else becomes a heresy). Alas for thousands upon thousands of excellent PL/SQL developers APEX remains the only sanctuary where they can remain productive and develop outstanding data centric applications and without APEX PL/SQL will surely become next COBOL. This is why PL/SQL community will drive Oracle to transform APEX to grade A platform much more powerful than what we are seeing today. Either that or say bye bye to PL/SQL and join curly brackets front (by the way it is never a bad idea to at least try different technologies when you are developer, at least you get an idea why it is not neccessarily greener at the other side).
I'm not sure why you don't consider PL/SQL a programming language...
APEX is ideal for internal applications where you want a lightweight UI on top of your data. You can build that rather easily without having to write any code.
I also find APEX to be very good for developing smaller customer-facing applications. I wouldn't want to build a giant application that is going to have hundreds of developers working on it using APEX. But if you have a case where 3 or 4 developers are building a smallish site, APEX is likely to be just as good as Java/PHP/ASP.Net/whatever assuming equally skilled developers. If your developers all have lots of ASP.Net expertise, for example, they're going to have a learning curve to write APEX apps. You'd have at least the same level of difficulty, though, if you had a bunch of PL/SQL developers try to learn how to build ASP.Net sites.
That Apex is only suitable for non-programmers and DBAs is an unfortunate misconception. We have used it to build several line-of-business, mission-critical, customer-facing web applications.
The GUI is handled by Apex page templates (HTML), CSS and a bit of Javascript to enhance the user experience. All business logic is placed in PL/SQL packages. This is key to making your application easy to maintain, and to reuse the business logic in other Apex applications and from other client tools, such as C# WinForms, Delphi, Java apps, etc.
As for performance, the Apex engine adds little overhead and the response times and scalability of your application depends largely on the quality of your SQL queries (and the data model). Think about it this way: With Apex, the only thing between your user and the database is a thin layer of PL/SQL. It's only common sense that this has to be faster than a typical .NET or Java application that has seventeen layers of complexity (typically including lots of web services and object-relational mapping layers) between the GUI and the database.
Don't put buisiness logic into Apex. Use it for presentation only.
If you put the code in the app your will not be able to maintain it, and you'll get RSI from all that clicking. I always create a wrapper layer, and in the oracle world follow Tom Kytes advise - put the business logic as close to the data as possible. This also means that you PL/SQL modules can be called by other systems etc - and best of all - the real meat of your applicaiton will be in straight text files that can be manipulated with your favourite text editor / IDE.
Create a view with all of the data to be retrieved for each screen.
Create a single wrapper package for all CRUD operations. (Thats is Create, Read, Update and Delete I presume)
In short:
DO NOT PUT YOUR APP LOGIC IN APEX.
Thats my advise . . . .
Oracle's Metalink support site was written in Apex, so it definitely CAN scale. They're migrating to a newer Flash-based support site now though. I understand they acquired that platform through an aquisition of another company, rather than building it in response to any Apex limits.
If you want 'super sexy' with any web-app, you'd probably need to go Flash/Silverlight/Air. Under that, any HTML based site, including an Apex one, can be prettied up with Javascript. The JQuery library will be included in with the next main version of Apex (4.0), though you can include that (or any other library) now.
The caching issue mentioned in the Wikipedia article has been addressed, though most installations would still put images and scripts on a conventional directory structure rather than serving them out of the database.
While you are locked into the Oracle database, I don't get the 'platform' lock "con" in the article. Oracle is available on Windows, Linux and AIX (amongst others). That's a lot less lock than ASP / SQL Server.
On my project, we use Oracle APEX for internal views of our system. It works very well for that purpose.
There's no programming required. PL/SQL and even SQL are optional. As a result, our DBA and operator can mold the view to their liking.
On the downside, if there's a feature you need which is not programmed into the system, it's very hard to add it. For instance, we wanted to color-code our output and have not been able to do that.
I would not want to have a customer-facing site built on APEX.
On the question of scalability, one nice thing about APEX is that it's built on Oracle. Focus on writing good SQL and designing the tables properly, and things should scale just fine. I'd be more concerned about getting enough users for scalability to be the problem.
Enjoyed very much reading the thread from top to bottom, as it felt like a hot debate. To remind the start of the thread it started as "I believe we're moving to Oracle Apex for future development..." jack being a .NET programmer was worried about the decision of his management and thought of finding counter facts for Oracle Apex which ultimately ended up washing the dirty linen (of all web frameworks) in public.
Despite the fact that the victim was Oracle Apex, the same could happen to either .net or j2ee if the debate was between .net and j2ee gurus. My point is all frameworks has their own pros and cons. That is why actually we have so many. Its a waste of time debating over what is more important to live (sex, food or water?) Naturally we select the most appropriate item when that is needed.
Oracle APEX suites for environments where you have lots of Oracle Databases and when you really have Pl/SQL enthusiasts. Can really build rich, complex, web 2.0 Data Centric applications really easily (Apex 4.0) but debugging and version control is still a mess and you also will have to stick to an Oracle database(yes you can have workarounds but not robust).
If you'd like to see an external web site done in APEX, I suggest looking at the Oracle Tools Users Group site, or Ask Tom. Both are large, frequently used sites with much customization.
Your impression from the Wikipedia article is correct. The only programming knowledge you need is PL/SQL. If most of your site will be simple reports, you don't even need to write the SQL queries, and the wizard interface will build the query and the output for you. If you want cool client side work, you will need to know CSS and Javascript. The PL/SQL is only for the more complex data validation.
I disagree. It is not only suitable to devs with a few developing skills or DBAs.
We actually produce highly customized apps using CSS templates of our own, a lot of dynamic actions and interaction (using jQuery and several frameworks), fine-tuned security, our own apex plugins and complex PL/SQL processes.
Of course, I am using apex > 4.0.
So, you can build complex apps (we have up to 100 different processes/validations and dynamic actions per pages) if needed. And it could require strong programming skills to code properly in javascript and PL/SQL(OOP) or Java stored procedures + a good knowledge of SQL to define opimized queries of up to 500 lines of code using recursive SQL and some funny features.