A solution to adding checkboxes to reports was presented in the The Complete Guide: Checkboxes in APEX Interactive Reports article. Now, in the current article we present another way that checkboxes can be added in a report. This solution however does not work for an interactive report, so if you need a checkbox in an interactive report then the solution to use is the one in the article mentioned above.
This solution is fairly simple and we would recommended it if you need a report with a checkbox and want to process multiple records of the report at the same time. For example, let's consider that there is a list of comments that need to be moderated, and we want to be able to select multiple records at the same time and set them a certain value: published, deleted, draft, etc. Like we've said before, the solution to do this can become simple. Use the tabular form properties, an "instead of" trigger and context calls to set parameter values. A little blurry? Let us explain ourselves:
Uploading images as BLOB columns
To upload an image in a table, first make sure you have created a BLOB column. For example, the table that would store the images could look like this:
CREATE TABLE "IMAGES"
( "ID" NUMBER NOT NULL ENABLE,
"IMAGE_NAME" VARCHAR2(90) NOT NULL ENABLE,
CONSTRAINT "IMAGE_PK" PRIMARY KEY ("ID") ENABLE)
The image will be stored in the CONTENT column of type BLOB. The other columns will be necessary for identifying the image and the MIME type. Multipurpose Internet Mail Extensions (MIME) is an Internet standard that extends the format of email to support Non-text attachments, Message bodies with multiple parts, Text in character sets other than ASCII and Header information in non-ASCII character sets. The MIME type will instruct the web browser how to handle the uploaded image file.
Joel Kallman, who manages apex.oracle.com, was kind enough to post a breakdown by countries for all the apex.oracle.com visitors, as an answer to our ApexNinjas previous post. The Google Analytics on the apex.oracle.com login page differ slightly that our analytics, probably because itrafic.eu is not that accurate (6% visitors are from Europe, not saying which country?) and because visitors which hit ApexNinjas.com are already using APEX and may not need accounts on apex.oracle.com, a valid point made by Joel in his post.
But the main idea is that most APEX users come from the US. Second place is taken by India and Romania occupies a fair 6th place:
Caching of pages and regions has been around since APEX 3.0 and my personal opinion is that it is still an underrated and less-used feature. I haven’t found complex caching systems in APEX applications I have worked with and that’s probably because most people don’t know how APEX caching works and they prefer implementing other caching solutions.
Why would you use caching? Because it greatly improves performance. APEX renders each HTML page from the database and this could prove slow, when getting hit really hard by lots of users. To avoid that, you can cache pages/regions, so that HTML pages are retrieved directly from the APEX cache (still stored in the database, but as HTML files, not as metadata), but without re-generating the pages/regions altogether.
We are using caching for www.apexninjas.com and it works like a charm. But this is just some simple caching, for the regions we know that do not change so often:
So if I were to interpret the itrace.eu statistics for www.apexninjas.com, the conclusion would be simple: Most of the APEX developers come from the US and Germany, with a staggering 57% of all APEX developers searching technical stuff on the web (and landing on ApexNinjas.com). Maybe ApexNinjas is not so relevant after all, but maybe the guys who manage apex.oracle.com (or the defunct tryapexnow.com) can confirm this…
The sad news is that Romania, where ApexNinjas.com is based, is not in the top 20 countries listed below :(
The good news: we get 2500 – 3000 visitors from all around the world per month! :)
We haven't published anything in a month on ApexNinjas. We haven't run out of ideas or anything like that. It's just that, between going to weddings, getting married myself, going on a holiday, working really hard, me and Claudiu have started working on an APEX Reporting book, that is due at the beginning of next year! How great is that?
The easiest way to create a mobile version of your web application (particularly, your APEX web application) is to use a tool to generate it using the RSS feed. Presuming you already developed an APEX web application with an RSS feed, you can use of the may (free or not) tools to generate the mobile version of your website in just a few minutes.
A list of some of these tools is available here: http://spyrestudios.com/10-great-tools-to-create-a-mobile-version-of-your-site. We’ll use Mofuse (a 14 day free trial version) to demonstrate how we can create a mobile version in just 5 minutes for www.apexninjas.com. Our RSS feed is available at http://localhost:8081/apex/rss.
Using the simple wizard available at Mofuse.com, create a trial account, log in, create a new website, at a RSS element, choose a layout and design and that’s all! Just check out http://apexninjas.prohost.mobi on your mobile (available on free trail 14 days beginning in June the 14th). The result is a mobile app generated from the RSS feed, that looks like this:
Every APEX developer using the embedded translation mechanism (a white paper on this, relevant for APEX 3.x versions, here: http://localhost:8081/apex/f?p=100:1:2::::P1_ARTICLE:1560) must check out the tool developed by Peter Raganitsch called ApexLib XLIFF export tool. You can read all about this tool and download it here: Create better XLIFF Files for Oracle APEX Translations.
The simple picture goes like this: When translating an APEX application, using the embedded mechanism (Application Builder -> Shared Components -> Translate Application) you will export the meta data (the translatable text) from your application in the XLIFF format, translate it, import it back into APEX and then publish the translated version of the application.
Currently, APEX exports a XLIFF version 1.0, making it rather difficult to use a Translation Memory tool (such as the industry's leading SDL Trados Studio), because the translator doesn't know the relevance (the application screen, page name etc) of the string he/she is translating. But XLIFF 1.2 version stores all this information, so when translating a string that says "Please enter your username", you will also have the relevant information that this string appears in the login screen from page 120, for example. Something like this (the application structure in the "Editor" screen, the translatable text in the center panel):
Peter Raganitsch developed the aforementioned tool that integrates with APEX Application Builder and exports the XLIFF in the proper 1.2 version, making the translation of APEX meta-data a lot easier. I recommend dowloading Peter's ApexLib XLIFF Export Tool and then give it a try using SDL Trados Studio. You can get a SDL Trados Studio 2009 30-day free evaluation license from here: http://www.sdl.com/en/language-technology/products/translation-memory/studio-downloads/sdl-trados-trial-version.asp
Consuming a Web 2.0 resource has never been easier, since REST (Representational State Transfer) has become a widespread standard. All the web giants offer RESTfull web services: Facebook, Flickr, Youtube, LinkedIn, Xing, MySpace and many more. As more and more applications tend to interconnect with all of these social-media-life-sharing services out there, there is no doubt that you will not be able to develop anything in the near future without knowing how to “consume” or “produce” RESTfull Web Services. Fortunately, APEX 4.0 has a simple and straightforward way of consuming Web Services.
1. Identify the Web Service you wish to use
In our case, www.deviceidentifier.com, a web site that provides a web service based on the user agent, that identifies what kind of device was used to access your website. We will use this site to identify if the user is accessing www.apexninjas.com from a mobile device, in which case we will redirect to a mobile version of ApexNinjas (stay tuned). DeviceIdentifier.com has a simple page describing how to use it’s web service: http://www.deviceidentifier.com/rest/
From the documentation, we must pass 3 parameters (sitekey, format, user-agent) to http://www.deviceidentifier.com/rest/capabilities-base.php as a GET request, and the response will be returned in XML or JSON format in the
response_dataout put parameter.
Probably one of the most overlooked feature of APEX is the use of supporting objects. I have just run into them (the supporting objects, that is…) after realising that my application images were not exported when doing a simple application export. Turns out that static files, css and static files must be defined as supporting objects and have installation scripts created. And then, during the import, you have the option to run the install scripts for the supporting objects.
From the beginning:
1. Create installation scripts from the application images