I am a computer programmer by training but have been away from web development for a while. I am doing a little bit of background research on various Python web development frameworks. I understand that Django, Grok / Zope 3, and Pylons are all good solid frameworks, but have little in the way of background working with them. Can someone explain to me the difference in approach of the each of the frameworks, and where one shines when compared to the others?
My specific use case is in building a web application that will recommend products to users based on a variety of user supplied information. Thus, it will take a fair bit of user input in the shape of a basic profile, product preferences, attempt to establish social relationships between users. It will also need to support staff uploading products into the system with labeled features that can be then matched to users.
On the last point, would parts of Plone help with providing an interface for non-tech people to upload products and descriptions of the products? Are piece of Plone easy to borrow? Seems like I shouldn't have to reinvent the wheel in terms of having a way for people to upload items for sale / recommendation along with some metadata to describe the items. Thanks for the help.
Based on your background and requirements, I'd advise you to go with something like http://pinaxproject.com/ which is based on Django.
Pyramid (the successor to Pylons) is a very low-level framework and you need to either choose the libraries or write all your application code yourself. For someone experienced this makes sense and gives you full control over your code. But it is a bit of a hurdle if you start from scratch and aren't familiar with the available libraries.
Django and Grok are both high level frameworks, with Django being the more popular choice. If you aren't familiar yet with using object databases or URL traversal, Grok is more time consuming to learn.
Plone is not suited for your use-case. It's a content management system and not a general web framework. Very little of the libraries it uses can be reused in a different context, certainly none of its UI. If you want to provide an engaging user experience with personalized content, Plone isn't for you - that's not what its been build to handle.
Disclaimer: I'm a release manager for Plone and Zope 2 / Zope Toolkit and have used Pyramid but not Django.
Dolmen project is a CMS built on top of Grok. Is very simple, but there are very few that use it. If you go with Grok, you could be able to reuse the GUI.
But As Hanno said, Grok is more time-consuming to learn than Django. Also Django has far more users than Grok.
The advantage of using Grok is that you can profit from Zope Component Architecture almost without writing ZCML and using decorators instead.
With Pyramid/Pylons you get a very simple framework and nothing else. It is a decoupled framework, so you are free to use whatever templating enginge you want (Mako, Genshi, Jinja, Cheetah), you are free to choose sqlalchemy, zodb, mongoDb, etc., and you are also free to choose the url mapping scheme (traversal vs. django-style mapping or a combination of both). You can also use ZCA here if you want. For starters this might become quite confusing or verbose.
Django is a kind of monolithic framework that gives you one way to do stuff. That's why it's easy to learn and a very good option. But, in my experience, you sometimes get to a point where you want to deviate from Django standards and it simply cannot be done without patching a bunch of stuff.
And, as for Zope3, I'd recommend you to download a copy of BlueBream and se how it does for you.
As a Plone user I can say that creating Content Objects in Plone is difficult. There is not much documentation on how to do it and it is complicated. Some recommend using UML and specialized Plone products to make it easier but that introduces yet another dependency.
I mention the problem with content objects because your "products" (not the same as a Plone product) would probably be represented in Plone as a content object which you would need to write yourself.
Plone is best when users and editors are entering and approving text in the form of news articles, press releases, photos etc. When that is the use case there are predefined content objects for such things so one does not need to write them oneself.
--Jonathan Mark
I'm helping build a multilingual website in English, Chinese and French (after in Spanish, Korean and Arabic). I've collected a database of over 2000+ entries. It is essentially a huge product catalog (specifically travel packages) where more or less the info is the same (prices, sizes, numbers, etc.) but the labels change (of course excluding certain intro texts that must be written manually). I want to avoid having to translate piece by piece manually.
There needs to be a way for users to save the things they are interested in and rate their favorites. Also, I need an e-commerce shopping cart. Search functionality is a must since people tend to start general (one or two categories or wants) and work towards specifics. Another need is to localization and internationalization. The other need is a specific workflow system so as content is updated and new additions are made, editors can be notified and translators can translate what needs to be done. Work flow is key since the project will involve dozens of non-technical people from around the world.
I originally tried to a work-around solution in Drupal but it seemed ill-equipped and clunky. I tried a self-built PHP CMS but the project seems to big for purely manual. I'm considering Plone and Django, but I don't have any experience working in Python, only PHP. I'm open to trying a new CMS if it meets my needs of internationalization, translation work flow, search functionality and on-going user experience.
Any suggestions on the best CMS for all this?
Plone would be a good solution for the CMS, workflow, search and multilingual.
Ecommerce is not Plone's strength though. I would recommend integrating Plone with something like Satchmo than doing the ecommerce in Plone itself. (This has been done with success in other deployements)
If you are looking at a Django solution to these problems you might consider Satchmo or Lightning Fast Shop for the e-commerce part and Pootle for the translation process...
Not a programming question I'm afraid, so moderators do what you will, but it is a question specifically for self-employed programmers running their own ISV sites.
If you publish your own shareware or freeware, do you use any CMS or templating system to streamline maintaining the website? Would you recommend any?
Two most important features I'm looking for that I couldn't find in any popular CMS/blogging engine, from my favorite TextPattern to WordPress, Joomla and Drupal are:
a templating system to maintain structural consistency of xhtml page layout
a hash table of user-defined values that works with the templates to substitute these values for identifiers.
Explanation: If you publish more than one application, the site probably contains several classes of pages that are nearly identical for each product: "Features", "Screenshots", "What's new", "Download", etc. These pages have the same layout and differ mainly in product-specific data. I'd like to be able to define "CurrentVersion=2.2" for product A, and "CurrentVersion=3.3" for product B in a "dictionary", and have the system generate two "Download" pages from the same template, replacing the "CurrentVersion" identifier with each product's respective value.
Other than that, I am looking for good support for static pages (the example pages above do not yield themselves to blog-like timeline treatment) and for design templates (themes), since I can't do graphic design at all (no skills, no tools, no talent). A good search function, esp. for the FAQs, is important. Another nice-to-have is easy (preferably wiki-like) way of linking to pages within the site. Some CMS-es, such as Joomla, make this simple and common task surprisingly inconvenient.
LAMP, and preferably free, since mine is a freeware-only shop.
I need no collaboration features and no multi-user content editing at all. My ISP doesn't support Zope, so that excludes some candidates.
I'm asking this question having spent months trying to find a solution that would help me leave static html behind and reduce the maintenance chores, such as updating the current version number on several pages manually. So what do others use to publish their software?
(Please do not reply by just saying "Try X". At least please say what makes it suitable or how it is better than other possible solutions. I've already tried a number of CMS engines, and they all seem to require extensive modifications to suit this particular need. Since my programming experience is strictly desktop-side Windows, tweaking these products is well beyond my skills (and my skin crawls to think of potential security WTFs I could unwittingly commit). Time is also a factor, since between my day job and my late-night coding, there's little left for learning how to write my own CMS from scratch - just typing static html would be more efficient.)
Wordpress is quite nice. It has a big community behind it so you can leech some plugins, like for SEO optimization, PayPal integration, Google Analytics statistics tracking, etc. And you also have a full-featured administration backend to manage all your content.
I would recommend Joomla 3.2.x. I have the same sort of project based websites, and this provides the flexibility for all of the different requirements. While WordPress is great the simplicity of it gets the better of it, Joomla is far more flexible and has a huge support network and extensions library.
I'm not familiar with Filnet P8.
My assumptions from reading some online docs is that it has a central web-based user interface called Workplace which is implemented on the Java web stack and communicates with the core parts of Filenet through Java APIs.
Also it seems you can extend the Workplace trough JSR 186 compliant portlets. - from what I've read Filnet P8 Workplace is not a portal itself and cannot host portlets, but provides some of the functionality as portlets which can be used with 3rd party portals.
Filenet also seems to have a lot of extensibility points which don't require coding, but I'm considering a highly-customized application with custom dynamic grids and forms.
Is it possible to extend the Workplace using portlets and/or plain JSP/Servlet approach with custom GUI for a custom workflow? (Probably the "Web Application Toolkit" is the tool)
The GUI can contain grids with filtering and column selection, forms (not paper once) with dynamically disabling/enabling fields, custom search forms, dynamic context and dropdown menus.
The GUI should be able to integrate with the Content and Process engines of course.
A link to an existing Filenet P8 based solution which proves such a custom Workplace GUI extension possible would be great.
Thanks!
This is possible. First of all Workplace comes with FULL source code. Look in the AESource directory (usually in c:\Program Files\FileNet\AE if you are running it on Windows). What you need to decide first of all is where you want to plug in (for example do you want to create a new Wokrplace page altogether like the Browse and Search pages or do you want to splice it in as a new action like Checkout, Get-Info etc).
Once you figure that out, I can provide more specific information of where you want to look to add your new code. Once you can display an entry point to your own feature in Workplace, then you can use whatever you want as far as controls etc. You can use JSF grids or just classic JSP stuff or even JQuery controls (provided you link the right libs etc).
Another thing to keep in mind is that you are going to need to get familiar with the Web Application Toolkit (WAT) so that you can make sure you are getting the right state information from Workplace (like the user token of who is logged in, maybe what doc id the user clicked on, what folder they were in when they entered your UI).
Anyways, here is some info to get you started. If you provide more info about where you want to splice your UI in, I can provide some guidance as what you need to change etc.
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.