If you've ever wanted to have precise control over the look and feel of the Interactive Reports in your Oracle Application Express application, take a look at Shakeeb Rahman's recent blog post on his new blog http://apex.shak.us. Shakeeb Rahman is on the Application Express product development team and is the master of all things HTML and CSS.
Marc Sewtz from the Oracle Application Express development team has been busy crafting a set of HTML templates and styleswhich are suitable for an iPhone or other small device. And to demonstrate this, Marc has crafted an APEX application running on apex.oracle.com (and Application Express 4.0) listing all of the Application Express-related sessions at Oracle OpenWorld 2010.
P.S. Don't bother using this application with Firefox nor Internet Explorer. It will work with any Webkit-based browser (Safari, Chrome). But it will look even better on your iPhone or Droid.
This will not be new information for long-time Oracle Application Express users, but it's worth mentioning for those new to Oracle Application Express.
In APEX page items (those using Automatic DML) and columns in SQL Reports & Interactive Reports, you have the ability to format date and timestamp values using a variety of format masks. Every report column and form page item has a format attribute. For date and timestamp columns, you can specify any valid Oracle date or timestamp format mask, with a full listing provided here. Some examples include:
MM/DD/YYYY
DD.MM.RRRR
DS FMHH24:MI:SS
DL
RRRR-MM-DD"T"hh24:mi:ss.xff
In APEX applications, you can also employ the SINCE format mask on date and timestamp columns. This is specific to APEX applications in the context of the format mask for report columns and Automatic DML page items. Instead of showing your end-users values like:
09/11/2010
you can present a value of:
3 days ago
The time period is relative to the difference between the time it is rendered and the value itself. Values can include 'seconds ago', 'minutes ago', 'hours ago', 'days ago', 'weeks ago', 'months ago', and 'years ago'. The benefit of using SINCE is:
It's time zone agnostic. Regardless of the time zone of your end user, 3 minutes ago is always 3 minutes ago.
It's locale agnostic. Some locales interpret 09/11 as September 11, other locales interpret 09/11 as November 9. Everyone interprets '3 days ago' as 3 days ago.
It's translated into the 10 languages provided for Application Express 4.0. The output will be correctly translated based upon your user's language preference.
New in Application Express 4.0:
Support for future dates and timestamps. You can now have values like '3 weeks from now', '2 days from now'.
Support for the SINCE format mask against columns of type TIMESTAMP, TIMESTAMP WITH TIME ZONE and TIMESTAMP WITH LOCAL TIME ZONE.
And an API (should be documented, but I find that it's not right now) to compute this yourself:
APEX_UTIL.GET_SINCE( p_date IN DATE ) RETURN VARCHAR2
APEX_UTIL.GET_SINCE_TSWTZ( p_timestamp IN TIMESTAMP WITH TIME ZONE ) RETURN VARCHAR2
APEX_UTIL.GET_SINCE_TSWLTZ( p_ltimestamp IN TIMESTAMP WITH LOCAL TIME ZONE ) RETURN VARCHAR2
Impress your boss and your end-users with the SINCE format mask!
Are you going to Oracle OpenWorld 2010, which starts on September 19, 2010? If so, be sure to attend the "APEX Meetup" on Tuesday night. Dimitri has more information on his blog.
A feature of Application Express 4.0 which hasn't received a lot of press but is useful for those building applications that span time zones is the Automatic Time Zone application attribute.
The Oracle database has this wonderfully rich data type called TIMESTAMP WITH LOCAL TIME ZONE. The elegance of this data type is that the value stored in this column will be displayed in the user's current database session time zone. Having written a PL/SQL package to do time zone conversion, it is a non-trival exercise to develop this type of functionality let alone maintain it. Wouldn't it be great if we could put this burden of maintaining constantly evolving time zone rules and daylight saving time dates on the database? Well, you get this for free with TIMESTAMP WITH LOCAL TIME ZONE.
So if all we need to do is set the database session time zone, then:
How do we elegantly derive this for each end user of our application?
How do we ensure that every page view and page submission in Application Express has its database session time zone set correctly for a particular user?
There were numerous suggestions in the past, of storing a user's preferred time zone as a preference and then authoring a PL/SQL block in the VPD attribute of an application like:
Not exactly obvious. And this still doesn't answer question #1 of how do we elegantly derive this. This is where the new Automatic Time Zone attribute is useful.
In the Application Builder, if you edit the Application Properties and navigate to the Globalization subtab, you should see something like:
By default, Automatic Time Zone will be set to 'No'. When set to 'Yes', this will now change the behavior of your application:
At the beginning of an Application Express session (which happens at the beginning each time a user runs your application ), the time zone offset will be calculated from their Web browser client.
This time zone offset information will be sent to Application Express and recorded in the APEX session information for that user.
Then, each and every page view for the duration of their APEX session, the Application Express engine will read this value and set the database session time zone to this value.
All you have to do is employ data types which are time zone aware (like TIMESTAMP WITH LOCAL TIME ZONE; DATE is not time zone aware) and check a box in your application definition. It couldn't be simpler!
To demonstrate this, I created a simple application using the following DDL:
create table tz_log( id number primary key, username varchar2(255) not null, tz varchar2(512) not null, created_ts timestamp not null );
create or replace trigger tz_log_trg1 before insert on tz_log for each row begin if :new.id is null then :new.id := to_number(sys_guid(),'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX'); end if; -- :new.created_ts := localtimestamp; end;
Then, I just built an application with a SQL report on this table and added an on New Instance PL/SQL Process of:
insert into tz_log (username, tz) values(:APP_USER, apex_util.get_session_time_zone ); commit;
You can run this sample application here. Just keep in mind - it will require you to authenticate with your oracle.com credentials (the same credentials you use if you login to the OTN discussion forum) and it will record your visit in a log table, which others can view. Here's what it looks like - nothing fancy:
If you pay close attention, immediately after authentication, you'll see a URL like:
Obviously, your APEX session identifier and time zone value will be different than what I show above. But you'll see that there is a new parameter 'tz' to the 'f' procedure. And it is through this interface that you can create a URL to an APEX application and explicitly set the APEX session time zone to a different value. After you login, change the time zone value in the URL to something else (e.g., tz=0:00) and watch the values in the "Inserted into the Log Table (in your local time zone)" report column automatically adjust to that time zone. The underlying report definition didn't change - we're still simply selecting the TIMESTAMP WITH LOCAL TIME ZONE column out of the database, just now the database is automatically converting that value to display in the current session time zone.
This event had special significance for me, as our next-door neighbor, Jacob Carlino, was diagnosed with a rare form of cancer earlier this year and is undergoing treatment now. Jacob is 12 years old. A child like Jacob or any person, for that matter, shouldn't have to suffer through this horrible disease. Jacob's father Dave organized a team in support of his son Jacob, and I had the privilege of being on this team. Above is the team - Dan, Matt, Scott, me and Dave. On the front of our shirts is a picture of Jacob who we were honoring with our team's tour.
Pelotonia was a most-impressive and well-organized event. There were over 4,000 riders and thousands of volunteers in addition to a great deal of corporate sponsorship. The estimate is that this one event will raise over $8 million, with 100% of this money going directly to fund cancer research at the Ohio State University Cancer Care Center and Solove Research Institute. The honorary chair of this year's Pelotonia tour was Ohio State football legend Chris Spielman, who he himself lost his wife to cancer just 9 short months ago.
My goal for this blog post? To simply raise awareness of this disease, and to also let the world know that there is an ever-growing army of people right here in Ohio who is contributing in ways small and large to the eradication of this disease. Lastly, I would like to recognize and thank the sponsors of me for this ride - I am grateful for your generous support: Sue, Sergio & Priscila, Jason & Shelley, Eric, Bob & Marge, Matt & Gretchen, Tim & Susie, Anton & Chris, Kathy & Terry, Neil & Margaret, Tom, Nada & Matt, Frank, Harry, and Mike & Anita.
Today, Oracle Application Express 4.0.1 was released. This corrects a number of issues discovered in the original Application Express 4.0 release. In the README of the Application Express 4.0.1 patch set, there is a listing of all of the bugs corrected in this patch set. You can view a copy of it here.
We have also repackaged the Oracle Application Express full distribution. If you have never installed or upgraded to Oracle Application Express 4.0, you can download the latest full distribution and install this and you'll have Application Express 4.0.1 out-of-the-box. Since this always creates confusion for customers (do you need the patch set or the full distribution?), use this guide:
If you have Oracle Application Express release 4.0 installed, download the Oracle Application Express 4.0.1 patch set from My Oracle Support and apply it. Look for patch number 9976149. Even though the file is named p9976149_11201_GENERIC.zip, seemingly only for DB 11.2.0.1, it can actually be used against any supported database version running Application Express 4.0.
If you have Oracle Application Express release 3.2.1 or earlier installed (including Oracle HTML DB release 1.5), download and install the entire Oracle Application Express 4.0.1 release from the Oracle Technology Network (OTN).
If you do not have Oracle Application Express installed, download and install the entire Oracle Application Express 4.0.1 release from the Oracle Technology Network (OTN).
And how do you determine what version you're running? Well, if you're a DBA, you can connect to the database as SYS using SQL*Plus and issue:
select version from sys.dba_registry where comp_id = 'APEX';
If you can login to the Application Express development environment, you'll see the version number in the lower right of every page.
Oracle Application Express at http://apex.oracle.com had the 4.0.1.00.03 patch set applied on Saturday, August 14, 2010.
"Please provide a detailed explanation of how apex interacts with database security. It appears that apex is manipulating queries prior to presenting them tot he database to be run either by wrapping them in a pl/sql block that prevents role based security from working or doing a pre-security check that doesn't check role level security prior to issuing a query, or some other even that bypasses role based security. "
Since there really isn't any great explanation of this anywhere, I'd like to provide a brief but lucid explanation about how parsing of SQL works in Oracle Application Express.
The Oracle database ships with a supplied PL/SQL package named DBMS_SQL, to perform the execution of dynamic SQL.
The Oracle database also ships with a supplied but undocumented PL/SQL package named SYS.DBMS_SYS_SQL. This package enables the execution of dynamic SQL but it also enables the parsing of a statement as a specific database user and with the privileges of this specific database user. This PL/SQL package is highly privileged, obviously. The EXECUTE privilege on this package is not granted to database user, by default. It should almost never be granted to any database user, ever. When asked to grant execution on this package to someone, a smart DBA will always say "no."
Until Database version 10.2.0.3, both DBMS_SQL and DBMS_SYS_SQL would not observe roles when parsing SQL. This was consistent with database object access in PL/SQL itself (database roles are not observed in PL/SQL, in case you didn't know).
In Database 10.2.0.3 and later (and XE), SYS.DBMS_SYS_SQL was changed to support a flag which enabled the observation of database roles when parsing SQL.
In Application Express 2.1 and later, support was added to Oracle Application Express SQL Workshop on DB versions 10.2.0.3 and later to observe database roles, to be consistent with SQL*Plus. However, the execution of SQL in an Application Express application still does not observe roles when parsing user SQL. This remains true for the recently released Application Express 4.0.
So this explains a few things:
If you've ever wondered how Application Express can parse SQL as a specific database user and with the privileges of this database user but without ever connecting as that database user, this is the answer - DBMS_SYS_SQL.
When a new database user/schema is provisioned through Application Express, the discrete system privileges are granted to this new database user and not through any database role.
When you look the underlying database view V$SESSION, it will show that the database sessions associated with Application Express applications are connected as the minimally privileged database user APEX_PUBLIC_USER (or ANONYMOUS, if you're using the embedded PL/SQL gateway). But within that session, the underlying Application Express engine is being invoked and, after determining who the SQL can be parsed as for that specific page view, the SQL is being parsed as a different database user.
This also explains why, in some database versions, it will appear that roles are enabled when you issue DML statements from SQL Commands in SQL Workshop, but in the development of your application and in the execution of your application, it will appear that database roles are not enabled and that direct object privileges are required.
The XML translation files generated from Oracle Application Express are produced in XML Localization Interchange File Format (XLIFF) format. XLIFF is a recognized standard for the localization of computer software. "It is intended to give any software provider a single interchange file format that can be understood by any localization provider."
One of the unique characteristics of Application Express is that it is one of the few development frameworks where the decision to localize and translate an application can be made after the application is actually completed. Because the definition of the application is maintained in meta data in the APEX repository, it's already known in advance which attributes of your application are translatable and which are not.
The process to produce a translated application is pretty straightforward. It's as simple as:
Seed the translation repository from your existing application
Export the XLIFF file
Translate the XLIFF file
Upload the XLIFF file
Apply the XLIFF file
Publish your translated application
The first few translation unit lines of a sample XLIFF file generated from Application Express look like:
Logout Logout
Print Print
Logout Logout
Print Print
Home Home
Customers Customers
Products Products
Orders Orders
Charts Charts
Each translatable string is included as a 'trans-unit' in the XLIFF file. The last two elements of each translation unit ID are the meta data ID and the application ID. For example, in translation unit with id S-4-885632445599895776-25721, the meta data ID is 885632445599895776 and the application ID is 25721. (S-4 is an internal code signifying that this is a meta data string and corresponds to the text of a tab).
As I've discussed in a recent blog post about saved Interactive Reports, I explained how the internal meta data IDs "shift" or are recalculated when importing an application to a new ID. And this has presented problems for those customers who make use of the translation facilities of Application Express. Because the meta data IDs are a part of the XLIFF translation unit IDs, when those IDs change, the existing XLIFF files for the original application cannot be used against a new version of the application imported elsewhere as a new application ID. What a dead end!
I have authored an APEX application which helps customers overcome this problem. You can run the hosted version of the XLIFF Transformation application which is running in my workspace on apex.oracle.com, or you can download a copy of it and run it on your own APEX 4.0 or later instance. You need to provide 3 things when running this application:
The original XLIFF file
The application ID of the new application
The offset value between the two applications
To compute #3, I'll refer you to this same blog post where I give a couple examples how to determine the offset value.
The logic is really quite simple. After importing the application and installing the supporting objects, only 3 objects will be created - a table named XLIFF_FILES, a trigger on this table, and a small PL/SQL package named XLIFF_TRANSFORM. The PL/SQL package parses the XML file and uses some XDB APIs to replace certain elements of the XML file. By exploiting the native functionality of the database, this was really quite easy to write. For anyone who says the Oracle database is only good for "persisting data", I say smoke this!
This isn't my ideal solution. In a future release of Application Express, I'd like to make it as simple as choosing to include your translations in your application export file, and they move around with you. As the metadata gets transformed on a new import, so do the translations. But until then, this solution can be used.
A problem I've seen reported numerous times from customers is that users' saved (or customized) interactive reports are missing after they import a new version of their application. This is a problem we've known about for a while with no adequate remedy. However, given the introduction of the APEX_APPLICATION_INSTALL API in Application Express 4.0, I can offer a solution. Granted, it's not an ideal answer but it's certainly a feasible and supported solution. Firstly, some explanations are in order.
When an APEX application is imported into a workspace, the very first thing that's done is the existing version of the application is completely deleted. All of the meta data associated with the application is deleted - the definition of the pages, the reports on the pages, the templates, the buttons, the branches, the shared components, everything - it's all deleted. Once this is complete, then the application meta data of the APEX application being imported is then inserted. This whole process is atomic - so if an error occurs, the transaction is rolled back and the net effect is no change.
In the case of saved Interactive Reports, it's a little bit different. Imagine you have a production instance running application 645 - you have numerous users who have saved many Customized Interactive Reports. Upon import of a new version of the application, all meta data associated with application 645 is first deleted except the Customized Interactive Reports. In essence, these are left "dangling" until the new application 645 is installed. Once the application import is complete, then the meta data of the Customized Interactive Reports will reference real interactive report definitions again.
But there's a catch. If the application ID changes upon import, then this results in totally new meta data IDs being generated. (This is done in an attempt to prevent collisions of meta data, so you can freely export your application and give to anyone in the world to use on their own APEX instance). A meta data offset number is randomly generated and added to all of the existing IDs. This is done uniformly across all of the application meta data (this is important, and you'll see why shortly). Since the IDs of all of the application meta data have changed, all of your users' customized reports in the previous version of the application are forever left orphaned until they're cleaned up by an internal APEX batch process. Yikes!
Let's look at an example. On apex.oracle.com, I created a simple application with an Interactive Report on the EMP table. I defined this application as application 70000. I then exported this application and imported it back as application 70001.
Using SQL Commands and the APEX Data Dictionary views, I ran the following queries:
select tab_label, tab_id from APEX_APPLICATION_TABS where application_id = 70000
tab_label: Emp tab_id: 1573281607527253166
select tab_label, tab_id from APEX_APPLICATION_TABS where application_id = 70001
tab_label: Emp tab_id: 3146580610985521585
And the difference between the two IDs is 3146580610985521585 - 1573281607527253166 = 1573299003458268419
Let's do this again, but this time, for the APEX data dictionary view for page templates:
select template_id from APEX_APPLICATION_TEMP_PAGE where template_name = 'Login' and application_id = 70000
template_id: 1573270610302252883
select template_id from APEX_APPLICATION_TEMP_PAGE where template_name = 'Login' and application_id = 70001
template_id: 3146569613760521302
If we once again compute the differences between these two IDs, we get: 3146569613760521302 - 1573270610302252883 = 1573299003458268419
This happens to be exactly the difference between the IDs of all of the application meta data, with the exception of the application and page IDs. All of the meta data is consistently "pushed" or offset to a new value.
How is this relevant to missing saved Interactive Reports? Simple. Since we're able to compute the offset which was used between the two applications, if we had a way to ensure that the same offset is used every time upon application import, then there would be no issue with the old saved Interactive Report IDs matching with the newly imported meta data. They would be married again. And how is this done? In Application Express 4.0, there is a new API named APEX_APPLICATION_INSTALL which enables you to control this offset value.
To ensure that I didn't lose the saved Interactive Reports on subsequent imports of application 70000 to application 70001, I included the computed offset before importing this application via SQL*Plus:
begin apex_application_install.set_application_id( p_application_id => 70001 ); apex_application_install.set_offset( p_offset => 1573299003458268419 ); -- -- set the alias so it doesn't collide with the alias from app 70000 -- apex_application_install.set_application_alias( 'F' || apex_application.get_application_id ); end; /
@f70000.sql
That's all there is to it. Note that I didn't have to call apex_application_install.set_workspace_id above, because application 70000 and 70001 are in the same workspace where I performed this test.
As I stated earlier, this isn't the most elegant solution on the planet and most people don't want or need to know about meta data IDs or offsets or any of this complexity. But for those experienced users who are stuck with this problem of losing saved interactive reports when migrating from one application ID to another or across workspaces or instances, this is a supported and feasible solution.
Oracle Application Express provides two ways to import an application into an Application Express instance:
Upload and installation of an application export file via the Web interface of Application Express.
Execution of the application export file as a SQL script, typically in the command-line utility SQL*Plus
Using the file upload capability of the Web interface of Application Express, developers can import an application with a different application ID, different workspace ID and different parsing schema. But when importing an application via a command-line tool like SQL*Plus, none of these attributes (application ID, workspace ID, parsing schema) can be changed without directly modifying the application export file.
As more and more Application Express customers create applications which are meant to be deployed via command-line utilities or via a non-Web-based installer, they are faced with this challenge of how to import their application into an arbitrary workspace on any APEX instance.
Another common scenario is in training classes, to install an application into 50 different workspaces, all using the same application export file. Today, customers work around this by adding their own global variables to an application export file (never recommended and certainly not supported) and then varying the values of these global variables at installation time. However, this manual modification of the application export file (usually done with a post-export sed or awk script) shouldn't be necessary - and again, not supported.
In Oracle Application Express 4.0, there is a new API available named APEX_APPLICATION_INSTALL. This PL/SQL API provides a number of methods to set application attributes during the Application Express application installation process. All export files in Application Express 4.0 contain references to the values set by the APEX_APPLICATION_INSTALL API. However, the methods in this API will only be used to override the default application installation behavior.
APEX_APPLICATION_INSTALL Summary
Workspace
Used to set and get the workspace ID for the application to be imported. This number can be determined by querying the view APEX_WORKSPACES.
procedure set_workspace_id( p_workspace_id in number );
function get_workspace_id return number;
Application ID
Used to set and get the application ID for the application to be imported. The application ID should either not exist in the instance, or if it does exist in the instance, it must be in the workspace where the application will be imported into. This number must be a positive integer and must not be from the reserved range of Application Express application IDs.
procedure set_application_id( p_application_id in number );
function get_application_id return number;
Generates an available application ID on the instance and sets the application ID in APEX_APPLICATION_INSTALL.
procedure generate_application_id;
Offset
Used to set the offset value during application import. This value is used to ensure that the metadata for the Application Express application definition does not collide with other metadata on the instance. For a new application installation, it's almost always sufficient to call generate_offset to have Application Express generate this offset value for you. This number must be a positive integer.
procedure set_offset( p_offset in number );
function get_offset return number;
procedure generate_offset;
Schema
Used to set the parsing schema ("owner") of the Application Express application. The database user of this schema must already exist, and this schema name must already be mapped to the workspace which will be used to import the application.
procedure set_schema( p_schema in varchar2 );
function get_schema return varchar2;
Name
Sets the application name of the application to be imported.
procedure set_application_name( p_application_name in varchar2 );
function get_application_name return varchar2;
Alias
Sets the application alias of the application to be imported. This will only be used if the application to be imported has an alias specified. An application alias must be unique within a workspace, and it's recommended to be unique within an instance.
procedure set_application_alias( p_application_alias in varchar2 );
function get_application_alias return varchar2;
Image Prefix
Sets the image prefix of the application to be imported. The default can usually be used, as most Application Express instances use the default image prefix of /i/.
procedure set_image_prefix( p_image_prefix in varchar2 );
function get_image_prefix return varchar2;
Proxy
Sets the proxy server attributes of the application to be imported.
procedure set_proxy( p_proxy in varchar2 );
function get_proxy return varchar2;
Clear
Clears all values currently maintained in the APEX_APPLICATION_INSTALL package.
procedure clear_all;
Examples
Using the workspace FRED_DEV on the development instance, you generate an application export of application 645 and save it as file f645.sql. All examples below assume you are connected to SQL*Plus.
To import this application back into the FRED_DEV workspace on the same development instance using the same application ID:
@f645.sql
To import this application back into the FRED_DEV workspace on the same development instance, but using application ID 702:
To import this application back into the FRED_DEV workspace on the same development instance, but using an available application ID generated by Application Express:
begin apex_application_install.generate_application_id; apex_application_install.generate_offset; apex_application_install.set_application_alias( 'F' || apex_application_install.get_application_id ); end; /
@f645.sql
To import this application into the FRED_PROD workspace on the production instance, using schema FREDDY, and the workspace ID of FRED_DEV and FRED_PROD are different:
declare l_workspace_id number; begin select workspace_id into l_workspace_id from apex_workspaces where workspace = 'FRED_PROD'; -- apex_application_install.set_workspace_id( l_workspace_id ); apex_application_install.generate_offset; apex_application_install.set_schema( 'FREDDY' ); apex_application_install.set_application_alias( 'FREDPROD_APP' ); end; /
@f645.sql
To import this application into the Training instance for 3 different workspaces (each workspace with their own schema):
declare l_workspace_id number; begin select workspace_id into l_workspace_id from apex_workspaces where workspace = 'TRAINING1'; -- apex_application_install.set_workspace_id( l_workspace_id ); apex_application_install.generate_application_id; apex_application_install.generate_offset; apex_application_install.set_schema( 'STUDENT1' ); apex_application_install.set_application_alias( 'F' || apex_application_install.get_application_id ); end; /
@f645.sql
declare l_workspace_id number; begin select workspace_id into l_workspace_id from apex_workspaces where workspace = 'TRAINING2'; -- apex_application_install.set_workspace_id( l_workspace_id ); apex_application_install.generate_application_id; apex_application_install.generate_offset; apex_application_install.set_schema( 'STUDENT2' ); apex_application_install.set_application_alias( 'F' || apex_application_install.get_application_id ); end; /
@f645.sql
declare l_workspace_id number; begin select workspace_id into l_workspace_id from apex_workspaces where workspace = 'TRAINING3'; -- apex_application_install.set_workspace_id( l_workspace_id ); apex_application_install.generate_application_id; apex_application_install.generate_offset; apex_application_install.set_schema( 'STUDENT3' ); apex_application_install.set_application_alias( 'F' || apex_application_install.get_application_id ); end; /
@f645.sql
Now a final word of caution - with great power comes great responsibility. You should almost never set the offset value yourself unless you absolutely know what you're doing. One of the primary benefits of letting Application Express generate the meta data offset value for you is you avoid the possibility of any "collisions" with the meta data of any other application on any other APEX instance on the planet. If you have no known reason to manually set the offset value, then simply let Application Express set it for you.
In summary, the APEX_APPLICATION_INSTALL API in Application Express 4.0 now enables you to overcome a limitation in all previous versions of Application Express - namely, to take an arbitrary application export file and import it into any workspace on any arbitrary Application Express instance using SQL*Plus or any other command-line tool.
My manager since 1999, Mike Hichwa, has finally decided to join the blogosphere. Mike is the visionary and driving force behind Oracle Application Express and has been since he authored the very first line of APEX (then called "Flows") in 1999. Mike is the Vice President of Database Tools and is responsible for Application Express, SQL Developer, .NET tools, Java in the database, and others.
A customer filed a Service Request with Oracle Support, asking the following:
In Apex 4, Irrespective of the Client OS / Locale / Browser Language settings, the Language picked up the interface shows as “ Language: en “ . Where as from the same browser/client if I login into Apex.3.2.1, it shows the correct language as "DE" , "TH", "FR", etc.,
Has anybody seen this issue? Am I missing something?
This is expected behavior. In Application Express 4.0, the development environment uses the new "Session" language derivation, bringing it in line with modern Web applications which do not use the browser language as the primary language preference. This new language derivation type is documented briefly here and additionally in the item-level help.
If you go to the Login page of apex.oracle.com, you’ll see the language bar at the bottom. This language list is determined by the translated versions of Application Express which are installed in the instance. You can change your language preference from this language bar or within Application Express too. The language preference is "remembered" via a persistent cookie.
Oracle Application Express 4.0 is now available for download from the Oracle Technology Network here. What began in 2008 has culminated in the most ambitious release of Oracle Application Express since the very first version of Oracle HTML DB in 2004. Major enhancements include:
Websheets
Dynamic Actions
Plug-Ins
Team Development
Improved Charts, including Maps and Gantt Charts
Support for RESTful Web Services
Enhanced Interactive Reports
Dramatically improved themes/templates
Tabular form validations
Dynamic calendars
and many more...
You can read about the new features of Application Express 4.0 here.
If you wish to kick the tires of Oracle Application Express 4.0, feel free to sign up for a free workspace at http://apex.oracle.com. We're currently averaging around 600 new workspaces per week on apex.oracle.com, so the interest in the APEX Community is growing every day.
Our thanks go out to the thousands of customers who participated in the three different Early Adopter releases since December 2009. Your feedback, bug reports and suggestions have all made this a far better release in terms of quality and functionality.
Tonight, I patched apex.oracle.com to version 4.0.0.00.46. This is our proposed final release candidate of the software.
All translated versions have been installed too, which includes German, Spanish, French, Italian, Japanese, Korean, Brazilian Portuguese, Simplified Chinese and Traditional Chinese. Unlike previous releases of Application Express, the language for the Application Builder is no longer determined by your browser language setting. You can simply choose your language from the Login page or from within the home page in Application Express (after you login).
It has proven extraordinarily useful to upgrade apex.oracle.com and gather the feedback prior to release. There were a number of bugs which were uncovered and fixed that would have otherwise been missed. Thanks to all who reported any issues.
A few weeks ago, I attended an event in Columbus, Ohio called "IT Martini Hour 10: Agile of All Trades", sponsored by IT Martini. It's a very well organized event, gathering a few hundred people from the local IT community. I also was interested in going because a friend of mine from Pacejet was part of a discussion panel, hosted by Amazon Web Services. We've had such smashing success with Amazon Web Services in the hosting of http://tryapexnow.com, I just simply wanted to meet them and thank them.
During this event, I ran into a gentleman I worked with 20 years ago, where he and I were both in the same product development organization. This gentleman, "Mr. G", was a smart guy 20 years ago and is a smart guy today. Today, "Mr. G" works for a large financial institution where he is an architect for corporate IT. After glancing at my name tag which said "Oracle", he asked what I was doing and I gave him the 20-second story of Oracle Application Express. I even went so far as to say that his own company is running over 100 internal applications, all built with Oracle Application Express. I was expecting a positive reaction. That's not what I got.
In a rather abrupt and candid response, "Mr. G" said that he learned of Application Express just a couple weeks ago. He said it was stupid. It's RAD and RAD is bad. It's for "quick and dirty applications that don't scale". When I told him what organization was a primary user of APEX in his company, he referred to them as "the business users", and of course they'd use APEX. He wasn't surprised. They tend to use one of everything, whether or not it's the IT standard. He went on - a problem with APEX, like other frameworks, it's that it's a black box, and when there's a problem with the black box, you're stuck. Of course, I asked him if he doesn't use any framework, since presumably all frameworks are bad - but of course they do.
Another problem he had - he said I'd be surprised if I looked at what crappy systems the "business users" run these systems on. Then, when they fail, it becomes an IT problem. I had to point out that this wasn't a criticism of Application Express but a flaw within their organization.
So I asked him what alternatives are provided by "corporate IT". He said they have a bundle of software, some of it open-source, that is the official development platform distributed amongst the various businesses, which corporate IT can support. When I asked him if this can be used by the "business users", of course he said no. To which I concluded that he'd rather have the business users not solve their problems.
This went on for a few more minutes until the beer and testosterone kicked in. I finally blurted out how he was arriving at conclusions based upon no knowledge or experience. Surprisingly, "Mr. G." agreed. I offered to come to his place of business and give him a personal demonstration, being as honest and forthcoming as I can be about the positioning of Application Express and its strengths and weaknesses.
When the dust of Oracle Application Express 4.0 settles, I'll be visiting him.
Oracle Application Express at http://apex.oracle.com has been upgraded to a pre-production version of Oracle Application Express 4.0. There's nothing like upgrading an instance of 8,000 workspaces and 31,000 applications to ensure that the upgrade works perfectly and what used to work in Application Express 3.2 continues to run flawlessly
As most users in the APEX Community have come to realize, this is one of the final milestones in our development cycle before release. So we're getting close. You can read about what's new in Application Express 4.0 here.
The participation of the thousands of people in the Early Adopter program since December has been overwhelming. We are grateful for all of the work and feedback and suggestions and bugs reported by everyone. The APEX Community is alive and well...and growing!
The third (and hopefully final phase) of Oracle Application Express 4.0 Early Adopter is now available. A new instance with the latest build of Application Express 4.0 is now available on http://tryapexnow.com.
If you had used the second Application Express 4.0 Early Adopter instance, your workspace and schema have not been migrated to this instance. You will need to sign up for a workspace but you shouldn't have to take the survey again. The original Application Express 4.0 Early Adopter 2 instance is available at http://184.73.244.154/apex, and it will be available for the next couple of weeks.
Thanks to everyone who has participated and provided feedback, as the feedback and suggestions have been invaluable as always.
Marcie Young, from Curriculum Development, has just released the Oracle Learning Library. This is an application which she developed on apex.oracle.com and is a directory listing of free online training from Oracle - Oracle By Examples, Tutorials and Demonstrations. This application lets you search for free training covering numerous product and functional categories. Product categories include Database, Beehive, Enterprise Linux, Enterprise Manager, Fusion Middleware, JDeveloper and Oracle VM.
. This book is authored by my friend Arie Geller and Matthew Lyon. Many people have been helped by Arie on the Application Express discussion forum on OTN for years, and I can easily say that Arie is one of the foremost experts in the world on creating multi-lingual and globalized applications in Oracle Application Express. I've even learned a few things from Arie about properly developing applications which support RTL (right-to-left) languages like Hebrew and Arabic.
