As an Apex developer you won't go very far without hearing the name Joel R. Kallman. Joel is the Oracle's Director of Software Development for Application Express. He is a long time contributor and friend of the Apex community and has participated in many conferences and workshops. Best of all, he is always willing to assist developer as a passionate evangelist of Apex.
I recently had the opportunity to pose a number of questions to Joeal and wanted to share his responses with you. Joel, thank you so much for taking the time for this and for sharing some key information.
Q : For those who may not know, what is your role as it relates to Oracle APEX?
A: Good question. APEX is something that Michael Hichwa (Vice President, Database Tools) and I started back in 1999. Mike is the inventive and creative one, and I just happened to be employee #1. He architected the first framework, and I concurrently wrote the first application in this framework, proving and pushing the framework. Starting from a blank slate, in 3 months time, we developed and deployed a Web Calendar application for all of Oracle (used by 25K people, at the time). This framework became HTML DB and then ultimately Application Express (APEX), and is used by thousands of customers worldwide.
Today, I am responsible for both the product development and product management of Oracle APEX. I’m blessed to have a very hard-working, focused, experienced and professional team, and all of us contribute to Oracle APEX.
Q: What you consider some of the more exciting new features in Apex release 18.1?
A: A lot of this is presented in our blog post announcement: https://blogs.oracle.com/apex/announcing-oracle-apex-181. Probably the two biggest features are Application Features and the enhanced REST support.
For many years, our team has developed and delivered productivity applications as part of Oracle APEX. Some examples include Group Calendar, Project Tracking, Survey Builder, etc. In the development of this “fleet” of applications, we found
ourselves desiring the same features over and and over again – they were common features that someone would want in any APEX application. So we extended the concept of what you could create from the APEX application builder, and elevated it to higher-level features to be added to your application. It can consist of multiple pages and components which are employee in an app. Some good examples include user access control, activity monitoring, user-selectable UI (theme), and user feedback. Just by checking a box during application creation time, you can include very high-quality, polished application features which we use ourselves. These features can also be added to existing applications.
APEX 18 is also a dramatic leap forward in the support for remote data sources over REST. APEX has always had support for REST Web services, but in many cases, the support was programmatic. In APEX 18, there is now a completely declarative interface to remote data sources over REST. You can create Web Source Modules (a new shared component type) in APEX 18, and Web Source Modules can be the data source for reports, charts and calendars. Anyone can use this functionality today on the free site https://apex.oracle.com. I wrote a recent Oracle Magazine article which includes an interesting (and fun!) step-by-step tutorial. https://blogs.oracle.com/oraclemagazine/beyond-the-database.
APEX 18 also “unifies” the REST Services with Oracle REST Data Services (ORDS). There used to be a separate repository for the REST Services that you could create with APEX. ORDS, which is the next generation of REST Services for the database, had a separate repository. In APEX 18, these are now unified, and the REST Services that you can create in the REST Workshop of APEX 18 can also be edited via SQL Developer or even in the ORDS-supplied PL/SQL API
Q: What has been the feedback from the Apex community on release 18.1?
A: There has been tremendous uptake of APEX 18 by our customers. It has proven very reliable and stable, and there have been very few upgrade issues from prior versions of APEX. And in many cases, the applications themselves are faster too.
Q: Release 18.2 followed quickly after 18.1. Is there anything key to release 18.2 that we ought to know about?
A: The biggest thing you should take note of is the “cadence” we wish to achieve with APEX releases. Gone are the days of these very large, monolithic releases of APEX. Instead, we are opting for a release of APEX every 6 months. There are a number of more modest features that went into APEX 18.2, but it gets us and our customers in the process of this frequent release process. To accommodate this, we also made great strides in APEX 18.2 with the near-zero downtime APEX upgrades.
Q: Some people were running applications in Apex 5.1 and using the compatibility mode to run applications created in older Apex versions. Will these still work after upgrading?
A: We still support the same level of compatibility modes as we have done in the past. However, ideally, people should not rely upon these forever. The compatibility mode is an opportunity for you to have your applications run in a legacy mode, but there is a very good reason why we introduced a change in behaviour. With this said, there are many customers who directly upgraded from APEX 4.2 and APEX 5.0 to APEX 18 with literally zero issues.
Q: I know that John Snyders has upgraded his IG Cookbook, but can you highlight some of the improvements and new features?
A: There is new “Copy Don” support, which can be used to copy data from one row to other rows. There is integrated “Copy to Clipboard” support for a row or cell range selection. There are new Dynamic Action events which directly support Interactive Grid, namely Mode
Q: Are JET Charts still the same in this release, or are there new features theras well?
A: The version of Oracle JET which is included with APEX is updated with every release of APEX. This allows us to include new data visualizations in APEX, as well as remain on a supported JET release. In APEX 18, we upgraded to JET 4.2. And that had the additional effect of upgrading the version of jQuery and jQuery UI included with APEX 18 (jQuery 2.2.3 and jQuery UI 1.10.4). All native functionality of APEX has been upgraded to work with these newer libraries.
In terms of new charts in APEX 18, we have introduced Gantt Charts, Pyramid and Box Plot.
Q: Have customers encountered any issues with upgrading that might help us to know?
A: Nothing really significant. We always keep the Known Issues of a release up to date, as customers report issues which we believe have broad relevance to the community. https://www.oracle.com/technetwork/developer-tools/apex/downloads/apex181-known-issues-4478237.html
Q: Why was there such a dramatic lead in release numbering from Apex 5 to Apex 18?
A: This was solely to be consistent with the rest of the product naming and numbering with all other products & services from Oracle. Oracle provides a vast number of service offerings on the Oracle Cloud, and instead of having large, lengthy release cycles, there are releases every quarter, and in many cases, numerous times in a quarter. Oracle switched to this yearly product numbering for all Oracle Cloud Services. Other products available both on-premises and on cloud went to this same numbering (e.g., Oracle Database, Oracle REST Data Services, SQL Developer). We changed the release numbering of APEX to be consistent with this.
Q: The Oracle Application Express Statement of Direction indicates that there will no longer be patch set releases such as 5.1.4. Does this mean that we will have to wait for the next major release to see issues resolved that developers have identified?
A: Not particularly. Between cycles, we will release a cumulative “Patch Set Exception bundle” on My Oracle Support. We did this for APEX 18.1 and are doing so for APEX 18.2. We won’t include every bug fix in the patch set bundle, but we will include those which we believe impact a large number of customers. The upside to this frequent release cycle is you may see new features sooner. In the past, we could never alter translations or UI in a patch set. But we can do this in full releases. So this will ultimately result in us being able to deliver highly sought after functionality sooner.
Q: So without playing all of your cards, what lies ahead for Apex?
A: The APEX statement of direction for APEX 19.1 is available at https://apex.oracle.com/sod. In general, though, things have never looked brighter for the APEX platform or community.
By the way, if you have a moment, you may wish to listen to the recent APEX podcast with Executive Vice President Andy Mendelsohn (this podcast is recorded by the community, and not us). http://apex.press.
Again, my thanks to Joel.
Sunday, 13 January 2019
Sunday, 4 November 2018
5 Client Excuses For Not Upgrading Apex
In case you live under a rock, the latest release of Apex is Apex 18.2. This update was released on September 28, 2018. In case you missed it, you can find the release announcement here. But even when there is a new Apex release, it seems that many Apex customers neither celebrate the release nor upgrade to it very quickly. Now I am in no way suggesting that you throw you production applications into Apex 18.2, but merely that you begin using it in your dev environment.
I have been working with a lot of Apex clients. In some case they do not know that there is a new release. For others, there is a huge reluctance to update.
As I work with my clients, I hear a lot of excuses that they repeatedly use for not upgrading to the latest release of Apex. In this post, I try to present the top 5 excuses I hear, and to respond to them as thoroughly as I can.
Excuse 1
I am sure you have heard this one before. It really has no merit. I don't know of any release of Apex to be so so buggy as to cause it to be pulled back or immediately followed by another major. Most often, I see the Oracle Apex team respond to any issues by releasing a patch release. The patch is released sometimes to address some unintended behaviour.
Sometimes, Apex hosting companies will also give this same excuse. But, the excuse is not really the right reason for them not to upgrade. The more valid reason, I suppose, is to avoid a sudden change of the Apex hosting environment. They want to give their clients time to upgrade their own apps. Wait a minute! This is another important reason for those clients to upgrade.
No matter how you slice it, this excuse is simply that - an invalid excuse.
Excuse 2
I am sure you've heard this one too. It is said over and over again.
One of my recent larger clients were working in an Apex 5.1 environment. At least they upgraded to that version. Right? Wrong. While they upgraded to 5.1 most of their apps were built in 4.2, 4.0 and one even in 3.2. These apps were running in a 5.1 environment using the compatibility mode. Sure, the apps are working now, but for how much longer. While the Oracle Apex team is really good at supporting legacy versions, there will simply come a time that the version is so old that they surely break.
Apex 5 was such a watershed release, it is crazy to have apps in any earlier version. Apex 5 significantly changed the performance of apps and introduce a whole new way of structuring applications. And, if you apps were built using Apex 5, it will be a snap to do the upgrade to release 18.2. So, to me, this excuse also has no validity.
Excuse 3
This excuse is pathetic. There is always a lot of good documentation, articles and blog posts that will help you as a developer to make the transition. But if your developers have never even transitioned to Apex 5 then that failure rests entirely on you.
When you think of it, this excuse is quite insulting to the ability of your developers. If they have any skill at all, they surely won't find the transition difficult.
Let's say you just got the latest iPhone. Would you just leave it sitting on the table until someone from Apple comes along to show you how to use it. No. You play, explore and discover for yourself. If something has changed so much that you just don't know how to use it, you check web articles or forums to get the information you need. Surely it is like that with a new release of Apex. As developers, we are used to experimenting and poking around. For us, it is fun to learn and to discover new answers to old questions.
Stop blaming your developers. Any developer that can't learn new things are really not developers anyway.
Excuse 3
Really? Do you even know what the new release has to offer?
Usually those who use this excuse know very little about the new release They have not read the release notes. They haven't looked at the new features. And they haven't at least taken a cursory look at the version 18.2 documentation. Until you have done all of this, you simply can't use this excuse.
Excuse 4
This excuse is a bit like excuse 3. Sure, if you are in the middle of a large project, now may not be the right time. However, if are just thinking the upgrade will take hors and hours - you are simply wrong.
You can start my upgrading your development environment. Check out the level of effort to do the upgrade. Usually, it's a breeze. If it causes issues, just rollback to your pervious version. But rolling back should be your last choice. Look at the issues and try to resolve. It is not likely that you have been the first to come across the issue. Head on to the Apex forum.
If you need to continue with the active development, create a new 18.2 environment to check things out.
Excuse 5
If you've ever upgraded an Apex environment, you'll know that the Oracle Apex team has made the job pretty straight forward. In other words, the upgrade is not rocket science. It is not as if you are upgrading the database! With proper planning, it won't take a DBA or upgrade expert to get the job done.
Luckily there are a lot of good resources to help you. One of the best blogs on upgrading that I have come across is Dimitri Gielis's Safely uprade to Apex 18.1.
I have been working with a lot of Apex clients. In some case they do not know that there is a new release. For others, there is a huge reluctance to update.
As I work with my clients, I hear a lot of excuses that they repeatedly use for not upgrading to the latest release of Apex. In this post, I try to present the top 5 excuses I hear, and to respond to them as thoroughly as I can.
Excuse 1
I am waiting for the new release to be stable
I am sure you have heard this one before. It really has no merit. I don't know of any release of Apex to be so so buggy as to cause it to be pulled back or immediately followed by another major. Most often, I see the Oracle Apex team respond to any issues by releasing a patch release. The patch is released sometimes to address some unintended behaviour.Sometimes, Apex hosting companies will also give this same excuse. But, the excuse is not really the right reason for them not to upgrade. The more valid reason, I suppose, is to avoid a sudden change of the Apex hosting environment. They want to give their clients time to upgrade their own apps. Wait a minute! This is another important reason for those clients to upgrade.
No matter how you slice it, this excuse is simply that - an invalid excuse.
Excuse 2
Eveything is working fine now
I am sure you've heard this one too. It is said over and over again.One of my recent larger clients were working in an Apex 5.1 environment. At least they upgraded to that version. Right? Wrong. While they upgraded to 5.1 most of their apps were built in 4.2, 4.0 and one even in 3.2. These apps were running in a 5.1 environment using the compatibility mode. Sure, the apps are working now, but for how much longer. While the Oracle Apex team is really good at supporting legacy versions, there will simply come a time that the version is so old that they surely break.
Apex 5 was such a watershed release, it is crazy to have apps in any earlier version. Apex 5 significantly changed the performance of apps and introduce a whole new way of structuring applications. And, if you apps were built using Apex 5, it will be a snap to do the upgrade to release 18.2. So, to me, this excuse also has no validity.
Excuse 3
Our developers don't know the latest version
This excuse is pathetic. There is always a lot of good documentation, articles and blog posts that will help you as a developer to make the transition. But if your developers have never even transitioned to Apex 5 then that failure rests entirely on you.When you think of it, this excuse is quite insulting to the ability of your developers. If they have any skill at all, they surely won't find the transition difficult.
Let's say you just got the latest iPhone. Would you just leave it sitting on the table until someone from Apple comes along to show you how to use it. No. You play, explore and discover for yourself. If something has changed so much that you just don't know how to use it, you check web articles or forums to get the information you need. Surely it is like that with a new release of Apex. As developers, we are used to experimenting and poking around. For us, it is fun to learn and to discover new answers to old questions.
Stop blaming your developers. Any developer that can't learn new things are really not developers anyway.
Excuse 3
We don't need anything in version 18.2
Really? Do you even know what the new release has to offer?Usually those who use this excuse know very little about the new release They have not read the release notes. They haven't looked at the new features. And they haven't at least taken a cursory look at the version 18.2 documentation. Until you have done all of this, you simply can't use this excuse.
Excuse 4
We can't stop development to do an upgrade
This excuse is a bit like excuse 3. Sure, if you are in the middle of a large project, now may not be the right time. However, if are just thinking the upgrade will take hors and hours - you are simply wrong.You can start my upgrading your development environment. Check out the level of effort to do the upgrade. Usually, it's a breeze. If it causes issues, just rollback to your pervious version. But rolling back should be your last choice. Look at the issues and try to resolve. It is not likely that you have been the first to come across the issue. Head on to the Apex forum.
If you need to continue with the active development, create a new 18.2 environment to check things out.
Excuse 5
We don't have anyone who knows how to do the upgrade
If you've ever upgraded an Apex environment, you'll know that the Oracle Apex team has made the job pretty straight forward. In other words, the upgrade is not rocket science. It is not as if you are upgrading the database! With proper planning, it won't take a DBA or upgrade expert to get the job done.Luckily there are a lot of good resources to help you. One of the best blogs on upgrading that I have come across is Dimitri Gielis's Safely uprade to Apex 18.1.
Conclusion
Okay. The decision to update is not one to take recklessly. It requires evaluation and planning. Nonetheless, it is unwise to remain on an older release indefinitely. It is even worse to continue to have applications that were built in very old versions of Apex. And, if it is not yet time to upgrade, remember that as developers we can request a workspace.
Just stop using excuses. They make you look silly.
Drop me a comment and let me know your thoughts on upgrading Apex.
http://www.applinks.co.za
http://www.applinks.co.za
Sunday, 5 July 2015
Apex 5.0 - Getting Down With Dialogs (Part 1)
A part of any modern day web application is the use of dialogs. With the release of Apex 5.0, the development team has obviously put a great deal of work into this functionality and made it an integral part of Apex. Through the use of JQuery UI, the team has given us some feature-rich components and processes to use to support our need for dialogs.
In their simplest terms, dialogs are interactive modal popups that can be used to give additional information to the user, assist them in processing selected steps, or guide them through a wizard of nested steps. They offer the user the sense of "staying" where they are and not having to navigate around to accomplish a task. Dialogs are immediate, dramatic and captivating.
In previous versions of Apex, we had to use plug-ins or write considerable javascript to build these kind of dialogs into our applications. Now, with Apex 5.0, the full power of dialogs is rigt at our fingertips.
There are several types of dialogs available in Apex 5.0. In this first post in the series, I will discuss only one of them - the inline dialog.
Inline dialogs are really just regions on a page that function like a modal "popup" dialog. They are distinct from their more powerful cousin, the modal dialog page, in that they are simply a region and not a page. This, while it may seem obvious, is a key point. As a region on an existing page, the inline dialog does not need all of overhead involved in page rendering and processing. The region is in fact rendered as part of its containing page and therefore can be displayed very quickly. This lightweight "here I am" power of the inline dislog is also a bit of a weakness. As a region on a larger page, it lacks the validation and processing power of a separate page and is therefore not really suited to complex operations.
Before we go into the details of how to create an inline dislog, we ought to understand what in fact it will do.
As you can see from the above image, an inline dialog looks and feels much like a modal page. When the dialog is opened, the launching page is dimmed to highlight the modal region. The dialog awaits the users interaction before continuing and the underlying parent page is "frozen". Much like a modal page, it can have buttons to invoke actions, but it is important to understand that the whole page, not just the modal region, will be submitted when the button is clicked. More about that later.
It may help if I take a moment to explain my specific use of the inline dialog here. My application tends to be very dynamic. I am always adding new functionality and need a way of highlighting the new features to users. So, what I have developed is a page messaging franework. I have a database table where I store the messages that I want to display referenced by page number. When a user launches a page in the application, a process checks to see if there is a message to be displayed to the user for that page. If the user has not viewed the message before, the inline dialog is displayed with the message and title from the database table. Once the user clicks the "Got It" button, I record that the user has viewed this message and it will not be displayed for the user again. The framework allows me to set messages for any page in my application in order to help users find and use new features.
So, how do we create the inline dialog? It is really pretty simple. Create a new region on the page and set the region template to "inline dialog."
In my case, because I need the title and content to by dynamic, I have two hidden page items that I reference for both the region title and the content.
Once you have selected the region template of "inline dialog, you can open the Template Options where there are a number of settings to further control and appearance of the region.
Once you have the region the way you want it, it is time to trigger the display of the modal region. You need to determine under what circumstances the region will be displayed. Here, I want the region to be displayed on the loading of the page if there is a message to be displayed and the user has not viewed the message before. As I mentioned earlier, I have hidden page items for the title and content of the inline dialog message. These page items only get values assigned to them if there is a message to display for that specific page and if the user has not yet viewed the message. This then gives a mechanism for displaying the dialog. If the hidden items are not null, then I want to display the dialog. So, I have an "on change" dynamic action that references the hidden page item and fires if the item is not null:
Then, as part of my dynamic action, I use a true action of "Execute Javascript Code" to open the dialog:
Notice that I pass the static id for the region to the openModal function. And that's it! The inline dialog will be displayed. Of course, your triggering action may be quite different, but you get the idea.
Let's return to my earlier point about the entire page being submitted. An inline dialog region is different from a "modal page" in that it is simply a component of the parent page. Consider my "Got It" button that is part of my dialog region. The button has the behaviour of "Submit Page." When it is clicked, because the inline dialog is part of the parent page, the entire page will be submitted with all of its items etc. Therefore, it is important that you control the processing and branching based only on the single button being clicked. There are several ways to do this, but the most common would be to use the "When button pressed" condition processes and branches.
There are some other important issues associated with the fact that the inline dialog is simply a region of the parent page:
1. It will display very quickly as it is rendered with the parent page.
2. Unlike a modal page, it shares its processing with the parent page.
3. It is best suited for static content and limited user interaction.
There are lots of ways you can effectively use inline dialogs. You can use them for messages (as I hve), for alerts, confirmations or for quick popups that display additional information when the user opts to view it. They are very slick and can really contribute to a positive user experience.
Modal regions have been a part of Apex for quite a while. But now, with Apex 5 and the built-in use of JQuery UI, they are easier than ever and offer the developer a great deal of options of customization and control.
Add a comment to this blog and let me know how you are making use of inline dialogs. And watch for Part 2 in this series where I will discuss the more powerful and feature-rich modal dialog page.
In their simplest terms, dialogs are interactive modal popups that can be used to give additional information to the user, assist them in processing selected steps, or guide them through a wizard of nested steps. They offer the user the sense of "staying" where they are and not having to navigate around to accomplish a task. Dialogs are immediate, dramatic and captivating.
In previous versions of Apex, we had to use plug-ins or write considerable javascript to build these kind of dialogs into our applications. Now, with Apex 5.0, the full power of dialogs is rigt at our fingertips.
There are several types of dialogs available in Apex 5.0. In this first post in the series, I will discuss only one of them - the inline dialog.
Inline dialogs are really just regions on a page that function like a modal "popup" dialog. They are distinct from their more powerful cousin, the modal dialog page, in that they are simply a region and not a page. This, while it may seem obvious, is a key point. As a region on an existing page, the inline dialog does not need all of overhead involved in page rendering and processing. The region is in fact rendered as part of its containing page and therefore can be displayed very quickly. This lightweight "here I am" power of the inline dislog is also a bit of a weakness. As a region on a larger page, it lacks the validation and processing power of a separate page and is therefore not really suited to complex operations.
Before we go into the details of how to create an inline dislog, we ought to understand what in fact it will do.
As you can see from the above image, an inline dialog looks and feels much like a modal page. When the dialog is opened, the launching page is dimmed to highlight the modal region. The dialog awaits the users interaction before continuing and the underlying parent page is "frozen". Much like a modal page, it can have buttons to invoke actions, but it is important to understand that the whole page, not just the modal region, will be submitted when the button is clicked. More about that later.
It may help if I take a moment to explain my specific use of the inline dialog here. My application tends to be very dynamic. I am always adding new functionality and need a way of highlighting the new features to users. So, what I have developed is a page messaging franework. I have a database table where I store the messages that I want to display referenced by page number. When a user launches a page in the application, a process checks to see if there is a message to be displayed to the user for that page. If the user has not viewed the message before, the inline dialog is displayed with the message and title from the database table. Once the user clicks the "Got It" button, I record that the user has viewed this message and it will not be displayed for the user again. The framework allows me to set messages for any page in my application in order to help users find and use new features.
So, how do we create the inline dialog? It is really pretty simple. Create a new region on the page and set the region template to "inline dialog."
In my case, because I need the title and content to by dynamic, I have two hidden page items that I reference for both the region title and the content.
Once you have selected the region template of "inline dialog, you can open the Template Options where there are a number of settings to further control and appearance of the region.
Once you have the region the way you want it, it is time to trigger the display of the modal region. You need to determine under what circumstances the region will be displayed. Here, I want the region to be displayed on the loading of the page if there is a message to be displayed and the user has not viewed the message before. As I mentioned earlier, I have hidden page items for the title and content of the inline dialog message. These page items only get values assigned to them if there is a message to display for that specific page and if the user has not yet viewed the message. This then gives a mechanism for displaying the dialog. If the hidden items are not null, then I want to display the dialog. So, I have an "on change" dynamic action that references the hidden page item and fires if the item is not null:
Then, as part of my dynamic action, I use a true action of "Execute Javascript Code" to open the dialog:
Notice that I pass the static id for the region to the openModal function. And that's it! The inline dialog will be displayed. Of course, your triggering action may be quite different, but you get the idea.
Let's return to my earlier point about the entire page being submitted. An inline dialog region is different from a "modal page" in that it is simply a component of the parent page. Consider my "Got It" button that is part of my dialog region. The button has the behaviour of "Submit Page." When it is clicked, because the inline dialog is part of the parent page, the entire page will be submitted with all of its items etc. Therefore, it is important that you control the processing and branching based only on the single button being clicked. There are several ways to do this, but the most common would be to use the "When button pressed" condition processes and branches.
There are some other important issues associated with the fact that the inline dialog is simply a region of the parent page:
1. It will display very quickly as it is rendered with the parent page.
2. Unlike a modal page, it shares its processing with the parent page.
3. It is best suited for static content and limited user interaction.
There are lots of ways you can effectively use inline dialogs. You can use them for messages (as I hve), for alerts, confirmations or for quick popups that display additional information when the user opts to view it. They are very slick and can really contribute to a positive user experience.
Modal regions have been a part of Apex for quite a while. But now, with Apex 5 and the built-in use of JQuery UI, they are easier than ever and offer the developer a great deal of options of customization and control.
Add a comment to this blog and let me know how you are making use of inline dialogs. And watch for Part 2 in this series where I will discuss the more powerful and feature-rich modal dialog page.
Sunday, 28 June 2015
Apex 5.0 after two months
I have been using Apex 5.0 for two months now and figured it was high time I start blogging about it. So, here are some thoughts after eight weeks of exploration.
At first I found the new builder features a little difficult. There had been so much hype about the new Page Designer. I guess I was just so comfortable with the old component layout that it would have been so easy to stay with what I know. But, yes, I stuck with Pagc Designer and now can't imagine a world without it. I love that you can change component attributes in bulk and that you only have to click save once for the entire page. It is so easy to drag regions and items where you want them. So, while Page Designer might intimidate you at first - stick with it. Your productivity will soar.
I am thrilled with the new code editor. You can write code exactly as you would in any tool such as SQL Developer with all the feateres you need and can validate the code without leaving the editor. This is another huge productivity gain.
Modal regions and modal pages are very powerful and easy to implement. I must say that I am using them more than I ever had in my applications and they contribute to a great user experience. I will try and post a blog just about modal dialogs soon.
The Universal Theme and Themeroller are really inspiring and have a lot to offer. The user response has been good though many have suggested that the apps have adopted a "Microsoft" look - oh no!
There are some things that took me a while to come right with and I will blog about those in the hope of saving others time and frustration.
Most important of all, my apps in Apex 5.0 are running about 20% faster. Page and report refreshes are faster. Chart rendering Is faster and even database processing seems faster.
Now for a few complaints. There have been long-standing issues with Tabular Forms and no work has been done in this area. Some of the IR customization capability seems to have been removed. Report layouts seem somewhat less flexible but I an still exploring here.
So after all is said and done I love Apex 5 and feel renewed and excited as an Apex developer.
At first I found the new builder features a little difficult. There had been so much hype about the new Page Designer. I guess I was just so comfortable with the old component layout that it would have been so easy to stay with what I know. But, yes, I stuck with Pagc Designer and now can't imagine a world without it. I love that you can change component attributes in bulk and that you only have to click save once for the entire page. It is so easy to drag regions and items where you want them. So, while Page Designer might intimidate you at first - stick with it. Your productivity will soar.
I am thrilled with the new code editor. You can write code exactly as you would in any tool such as SQL Developer with all the feateres you need and can validate the code without leaving the editor. This is another huge productivity gain.
Modal regions and modal pages are very powerful and easy to implement. I must say that I am using them more than I ever had in my applications and they contribute to a great user experience. I will try and post a blog just about modal dialogs soon.
The Universal Theme and Themeroller are really inspiring and have a lot to offer. The user response has been good though many have suggested that the apps have adopted a "Microsoft" look - oh no!
There are some things that took me a while to come right with and I will blog about those in the hope of saving others time and frustration.
Most important of all, my apps in Apex 5.0 are running about 20% faster. Page and report refreshes are faster. Chart rendering Is faster and even database processing seems faster.
Now for a few complaints. There have been long-standing issues with Tabular Forms and no work has been done in this area. Some of the IR customization capability seems to have been removed. Report layouts seem somewhat less flexible but I an still exploring here.
So after all is said and done I love Apex 5 and feel renewed and excited as an Apex developer.
Wednesday, 2 January 2013
Email and Subscription IR Reports in Apex 4.2
There has been a problem for some time with regard to email and subscriptions of IR reports. Prior to Apex 4.2, the "from" address for these reports when sent by email has always be the same as the "to" address entered by the user. In other words, if the email report was being send to john.smith@yahoo.com, it would have the from address set to john_smith@yahoo.com.
Having the "from" address the same as the "to" address, often resulted in issues on mail servers. Some mail servers have policies set that do not allow external emails to come from an internal server address. Other times, mail servers will treat these sorts of a mails as junk or span and not direct them to the inbox. Further, it just looked weird!
Now, Apex 4.2 allows you to explicitly set the "from" address either at the instance level, or at the report level itself.
Navigate to a page that has an interactive report, and view the Report Attributes. Scroll down to Advanced Attributes. Here, you can specify the "Email From Address":
You can also set the from address at the application level. In Application Builder, edit and application and click the Edit Application Properties button. Scroll down to the Properties section, here you will find a property where you can special the application's "from emal address."
Sometimes it is just the little things that make a big difference!
Having the "from" address the same as the "to" address, often resulted in issues on mail servers. Some mail servers have policies set that do not allow external emails to come from an internal server address. Other times, mail servers will treat these sorts of a mails as junk or span and not direct them to the inbox. Further, it just looked weird!
Now, Apex 4.2 allows you to explicitly set the "from" address either at the instance level, or at the report level itself.
Navigate to a page that has an interactive report, and view the Report Attributes. Scroll down to Advanced Attributes. Here, you can specify the "Email From Address":
You can also set the from address at the application level. In Application Builder, edit and application and click the Edit Application Properties button. Scroll down to the Properties section, here you will find a property where you can special the application's "from emal address."
Sometimes it is just the little things that make a big difference!
Tuesday, 1 January 2013
A Response to Responsive Design in Apex 4.2
I have been following with a lot of interest the discussions regarding implementing Responsive Design using Theme 25 in Apex 4.2. In case you are out of the loop, Responsive Design has to do with building applications that are fully functional across many different devices with various "viewport" sizes from the small screens of smartphones to the largest desktop screens.
My journey begin by reading Shakeeb Rahman's blogs on Responsive design here. I downloaded the presentation slides and worked my way through them. To me, this was exciting stuff. I was beginning to explore new approaches to web applications and it was quite cool had it all worked. I then downloaded Apex 4..2 and began to play with them 25 to see how it all fit together.
Not being convinced I had all the tools and information I needed, I purchased the book Responsive Web Design with HTML5 and CSS3 by Ben Frain that you can find here. It is a really great book and leads you through the whole implementation of a practical Responsive web application. I learned a tremendous amout about HTML5 and CSS3 and how to enhance what theme 25 already tries to accomplish. I built a couple of good test applications that worked very well on various deI vices.
Now here is where my response comes in.....
I have a large application that is used by many concurrent users. And, as you might expect, I thought "hey, why not make it responsive?" I set about to do just that. Not as simple as you might think. The big issue for me is that the application is primarily a series of real-time reports. Many of these reports are quite large and consist of up to fourteen columns. Some of the reports include drill-downs where the data is displayed on modal pages for ease of use and navigation. These reports simply are not suited for small screens - you can't avoid scrolling and the reports are almost useless in a small format. I just didn't make sense to try and make the application work all small viewports. Here is a case where it would be far more productive to have 2 separate user interaces, one for desktop and one for mobile (fully supported in Apex 4.2). The mobile application can present streamlined reports with only critical columns while the desktop version can support the full reports.
There is, of course, a greater cost to having two separate interfaces (one for mobile and one for desktop). You need to support both versions of the application. The logic may in some places be duplicated. You may need to maintain separate CSS files and so on. But, in my case, no other approcah seems to make sense. I am open to comments from others that may suggest I am wrong. After all, I am new at Responsive Design. Please do feel free to offer you own feedback.
I also did a bit of checking on my application. In Apex, you can monitor how your application is being accessed. You can monitor what OS is used and what browser. I found, dare I say it, over seventy percent of my users are accessing my application from IE (Yikes!!!!). This despite a message on the login page advising that the application is best used with Firefox. So, why spend oodles of development time (not to mention money) trying to make the application responsive.
I am not suggesting that we ought not to learn about and use Responsive Desgin. It has a clear role in making our applications future-proof. After all, more and more users today access websites via a device other than a desktop. What I am suggesting, however, is that creating "responsive" applications is but one approach. There are instances when it will be appropriate and instances where is simply won't achieve great results.
Perhaps the key lies in planning the design from the very start. If instread of simply following an approach and layout dictated by our client, or worse, by a graphic designer, we take the position from the start that it would be ideal to have a responsive application. In other words, we approach the whole project from a responsive point of view and try to desgin and build an application that can in fact be independent of the device on which it is viewed. To do this, you need to understand some of the concepts, techniques and tools involved in creating responsive web applications. There is no doubt this is the future. In my view, it is one more tool in our toolbox and not the solution to every situation. Thankfully, Apex 4.2 gives us a number of approaches to consider and to implement.
My journey begin by reading Shakeeb Rahman's blogs on Responsive design here. I downloaded the presentation slides and worked my way through them. To me, this was exciting stuff. I was beginning to explore new approaches to web applications and it was quite cool had it all worked. I then downloaded Apex 4..2 and began to play with them 25 to see how it all fit together.
Not being convinced I had all the tools and information I needed, I purchased the book Responsive Web Design with HTML5 and CSS3 by Ben Frain that you can find here. It is a really great book and leads you through the whole implementation of a practical Responsive web application. I learned a tremendous amout about HTML5 and CSS3 and how to enhance what theme 25 already tries to accomplish. I built a couple of good test applications that worked very well on various deI vices.
Now here is where my response comes in.....
I have a large application that is used by many concurrent users. And, as you might expect, I thought "hey, why not make it responsive?" I set about to do just that. Not as simple as you might think. The big issue for me is that the application is primarily a series of real-time reports. Many of these reports are quite large and consist of up to fourteen columns. Some of the reports include drill-downs where the data is displayed on modal pages for ease of use and navigation. These reports simply are not suited for small screens - you can't avoid scrolling and the reports are almost useless in a small format. I just didn't make sense to try and make the application work all small viewports. Here is a case where it would be far more productive to have 2 separate user interaces, one for desktop and one for mobile (fully supported in Apex 4.2). The mobile application can present streamlined reports with only critical columns while the desktop version can support the full reports.
There is, of course, a greater cost to having two separate interfaces (one for mobile and one for desktop). You need to support both versions of the application. The logic may in some places be duplicated. You may need to maintain separate CSS files and so on. But, in my case, no other approcah seems to make sense. I am open to comments from others that may suggest I am wrong. After all, I am new at Responsive Design. Please do feel free to offer you own feedback.
I also did a bit of checking on my application. In Apex, you can monitor how your application is being accessed. You can monitor what OS is used and what browser. I found, dare I say it, over seventy percent of my users are accessing my application from IE (Yikes!!!!). This despite a message on the login page advising that the application is best used with Firefox. So, why spend oodles of development time (not to mention money) trying to make the application responsive.
I am not suggesting that we ought not to learn about and use Responsive Desgin. It has a clear role in making our applications future-proof. After all, more and more users today access websites via a device other than a desktop. What I am suggesting, however, is that creating "responsive" applications is but one approach. There are instances when it will be appropriate and instances where is simply won't achieve great results.
Perhaps the key lies in planning the design from the very start. If instread of simply following an approach and layout dictated by our client, or worse, by a graphic designer, we take the position from the start that it would be ideal to have a responsive application. In other words, we approach the whole project from a responsive point of view and try to desgin and build an application that can in fact be independent of the device on which it is viewed. To do this, you need to understand some of the concepts, techniques and tools involved in creating responsive web applications. There is no doubt this is the future. In my view, it is one more tool in our toolbox and not the solution to every situation. Thankfully, Apex 4.2 gives us a number of approaches to consider and to implement.
Friday, 19 August 2011
Enabling and Disabling Classic Report Columns
Sometimes a classic report with many columns takes up too much space on the screen. There are a number of options for dealing with this issue, but one that I like is to provide the user with the ability to turn on and off individual columns or groups of columns.
I have seen several different ways of providing this functionality. For instance, Denes Kubicek has a solution in his sample application, but it does not handle column groups and is somewhat more awkward. So, for what it is worth, I thought I would share my solution.
First, I create a series of checkbox items representing the columns (or column groups) that I want to allow the user to "turn on and off." I put these items in a hide and show region so that they are accessible but not necessarily displayed until the user wants to change the columns.
Next, I modify the report. I set the Conditional Display attributes of each column in order to reference the related checkbox.
In some cases, I have more than one column being controlled by a single checkbox. My report has several columns that display dates. I use a single "date" checkbox to turn off and on the entire group of columns.
Next, I create a dynamic action for each of the checkbox items. The dynamic action is triggered by the "Change" event of the checkbox.
There are two true actions. The first, Execute pl/sql Code simply serves to put the value of the checkbox item into session state.
The second action simply refreshes the region containing the classic report.
You will need to repeat the above steps to create an dynamic action that will trigger on the change of each of the checkbox items.
The result allows the user to quickly enable or disable columns. Due to the use of the dynamic actions, the report quickly responds to the user changes. You can set defaults for the checkbox items so that some of the columns will show on page load and others will wait for the user to select the column for display.
I have seen several different ways of providing this functionality. For instance, Denes Kubicek has a solution in his sample application, but it does not handle column groups and is somewhat more awkward. So, for what it is worth, I thought I would share my solution.
First, I create a series of checkbox items representing the columns (or column groups) that I want to allow the user to "turn on and off." I put these items in a hide and show region so that they are accessible but not necessarily displayed until the user wants to change the columns.
Next, I modify the report. I set the Conditional Display attributes of each column in order to reference the related checkbox.
In some cases, I have more than one column being controlled by a single checkbox. My report has several columns that display dates. I use a single "date" checkbox to turn off and on the entire group of columns.
Next, I create a dynamic action for each of the checkbox items. The dynamic action is triggered by the "Change" event of the checkbox.
There are two true actions. The first, Execute pl/sql Code simply serves to put the value of the checkbox item into session state.
The second action simply refreshes the region containing the classic report.
The result allows the user to quickly enable or disable columns. Due to the use of the dynamic actions, the report quickly responds to the user changes. You can set defaults for the checkbox items so that some of the columns will show on page load and others will wait for the user to select the column for display.
Subscribe to:
Posts (Atom)