A typical APEX URL looks like this:

http://tryapexnow.com/apex/f?p=2500:1:1016153158259880

That means:
open Application 2500 on Page 1 using Session 1016153158259880

But there can be much more…

Most of this stuff here is described very well in the Oracle Application Express Application Builder Users’s Guide, Chapter “Understanding URL Syntax“, nonetheless i try to explain it using my own words.

The complete APEX URL Syntax looks like this:

http://apex.oracle.com/pls/apex/f?p=AppId:PageId:Session:Request:Debug:ClearCache:Params:ParamValues:PrinterFriendly

Let’s take a closer look:

• http:// – the protocol, can be http or https
• apex.oracle.com – your domain/host/server, whatever you want to call it. Can also be localhost.
• /pls – indicates that you are using Oracle HTTP Server with mod_plsql. If you are using APEX Listener or Embedded PL/SQL Gateway this part is obsolete/missing.
• /apex – the entry from your dads.conf file (this a file on your application-server or EPG where the target database is configured) – in case of EPG its just one entry pointing to localhost, in case of an OAS you can have multiple entries, each pointing to an other database
• /f?p= – procedure “f” is called and parameter “p” is set to the complete rest of the string. Remember: APEX uses mod_plsql. “f” is a public procedure, this is the main entrypoint for APEX. Or you could say: “f” is APEX.
• AppId – the number or the Alias of the Application
• :PageId – the number or the Alias of the Page
• :Session – unique Session ID, can be 0 for Public Pages or empty (then APEX creates a new Session)
• :Request – a Request Keyword. This is basically free text, just a string you can specify to react in a process or region condition on. e.g. you could pass the keyword “CREATE” and have a condition on the delete button of your page saying “dont’t display this button if request is CREATE”.
  In other words: use the REQUEST to control the behaviour of your page.
  When pressing a button, the button sets the REQUEST to the button-value (e.g. SAVE), so that you can control the processes in the page processing (Submit) phase.
• :Debug – set to YES (uppercase!) switches on the Debug-Mode which renders debug-messages and timestamps in your Browser window. This helps to detect wrong behaviour of your page or performance issues and everything else. Every other value then YES turns the Debug-Mode off
• :ClearCache – you can put a page id or a list of page ids here (comma-separated) to clear the cache for these pages (set session state to null, …). But there is more: RP resets the pagination of reports on the page(s), a collection name deletes the collection, APP clears all pages and application-items, SESSION does the same as APP but for all applications the session-id has been used in.
• :Parameters – comma seperated list of page-item names. Good practice is to set only those page-items which are on the page you are going to. Accepts page-items as well as application-items.
• :ParamValues – comma separated list of values. Each value is assigned to the corresponding Parameter provided in ParamNameList (first value assigned to first parameter, second value assigned to second parameter, and so on…).
  The trick here is not having values which contain either a comma “,” or a colon “:”. Both would lead to side-effects and errors, as APEX gets confused when parsing the URL. Using a comma works, if enclosed by slashes: e.g. /123,89/.
• :PrinterFriendly – set to YES (uppercase!) switches the page into PrinterFriendly-Mode, uses the Printerfriendly template to render the Page. You can also hide regions or other elements in PrinterFriendly-Mode using the PRINTER_FRIENDLY variable in a condition.

There are also some more Blogs dealing with URL Syntax, take a look at some of them: MattsBits, Oraclenerd, Burleson .

When displaying error messages in the notification area the rest of the page is shifted downwards a little. This is no problem most of the time, except in this case:

1. you have a form with required fields
2. you enter some of the fields and then realize you don’t want to enter more but leave the form
3. so you press the “Cancel” Button while your cursor is still in an empty required field
4. before the Cancel Button is processed the field validation displays the “Field is required” Message
5. displaying the Error shifts the button downwards, the mouse cursor isn’t hovering above the button anymore
6. the browser decides, that you clicked into empty space and discards Button processing

Long story short, you have to press the button a second time if an error message is displayed in the notification area when pressing the button.

I haven’t found any satisfying solution to avoid this problem in a programmatically way, so this leaves us with few options:

1. ignore it and let your users click a second time
2. have a fixed size notification area (this is kind of complicated, since you never know how many error messages you need to display)
3. my favorite: let the notification area hover above the rest of your form

Solution 3 can look like this, depending on your layout or used theme you’ll have to implement it in a different way.

See a working solution online in the Demo-Application.

All I had to do, was modifying the CSS Settings for the notification area:

.t7notification {
 background:none repeat scroll 0 50% #FFFFCC;
 border:1px solid #FFD700;
 color:#333333;
 font-size:11px;
 font-weight:bold;
 left:25%;
 margin:4px auto;
 opacity:0.8;
 filter:alpha(opacity=80);
 padding:2px;
 position:absolute;
 text-align:center;
 width:50%;
}

Looking for a certain application can be time consuming if you don’t remember what the workspace this application belongs to is called.

At this point you could either check the repository using a SELECT

SELECT *
  FROM APEX_APPLICATIONS
 WHERE APPLICATION_NAME LIKE '%XY%';

Or you could login into the administration section (workspace INTERNAL) and look there.

Way easier is having a listing of all applications right below the login fields:

This makes finding the right workspace faster and easier, having the listing of all applications in your database is like a directory listing of all your files you are working on.

Warning: Displaying information about your applications is a potential security risk, you should use this on internal development systems only, never on a public system!

How does it work?

As you may know, Oracle APEX is written in Oracle APEX. An APEX Builder page is just like any other page you  may design for your application. That means you easily can add a reports region to the login page.

The only downside here is that you can’t edit internal applications with the APEX Builder, you just can’t login to the INTERNAL workspace in edit mode.

But no need for that, we just use the same API that’s used in the Application export files.

Check out the script over here. It basically adds a reports region to the (english) login page, thats all.

Disclaimer: Enhancing/changing the internal applications may not be intended by Oracle, so there is no warranty at all. Whatever you do is own your own risk.
Go for it :-)