Loading...

Follow FOEX Blog on Feedspot

Continue with Google
Continue with Facebook
or

Valid

Inspired by Stack Overflows annual development survey, in December of last year, we ran a survey of 25 questions to better understand the state of APEX development in the community. A big thank you goes out to all the 318 participants for taking the time to contribute. From the survey results we have compiled the following report which you can download by clicking the image below:

We would like to thank Joel Kallman and Jürgen Schuster, for their input on the survey and helping promote it.

If you want to see other question for the 2019 edition, please leave a comment on this post.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
Some Background First

Web application development is now the No.1 development choice for new application development and Javascript is now the No.1 developer language. This can be attributed to the explosion of mobile devices and a global adoption of modern browsers and web standards.

Stack Overflow 2018 Developer Survey Results

The old issues of cross browser support and browser limitations are long behind us now paving the way for this meteoric rise. There is now an ever growing demand for more sophisticated and complex web applications to replace desktop applications or modernize legacy web applications. The building of these sophisticated applications introduced a new design approach, namely Single Page Applications (SPA).

Stack Overflow 2018 Developer Survey Results, both Angular & React are SPA Frameworks

Did you know that most modern desktop/mobile applications these days are actually SPA web applications that are then wrapped into a desktop application using tools like Electron or Cordova? How can you tell? Well you can’t really as they have the same behaviour characteristic of a native desktop application, the only telling sign is that they are way better looking thanks to CSS3. Skype and Visual Studio Code are two very well known and widely used tools. Did you know they are both built using Javascript and Electron? Haven’t the tables turned? The browser’s rendering engine really is the modern evolution of the JVM, write once deploy everywhere.

Isn’t it great to be a web developer?

Well “Yes” and “No”, due to an explosion of frameworks/tools/libraries, it makes choosing the right tools for your project(s) really hard. Many frameworks have come and gone whilst others have undergone complete rewrites. The reason is that web development is hard, and the job of making it easier is still being figured out, so everything is constantly evolving. We all use frameworks/tools/libraries as we want to make our jobs as easy as possible whilst giving our users the best possible application we can, within the budget and time constraints enforced on us. Low code and rapid application development frameworks are (becoming) more favourable, we just want one that will have longevity and be flexible enough to meet our current and future requirements that we’re not currently aware of. When building data centric applications, we personally think Oracle APEX fits that bill and we will explain why….

Web Application Design Patterns

Before we talk about APEX, first, let’s talk about web application design patterns in more detail. What are the web design approaches available to us? Well, there three main application design patterns that you can follow:

  1. Multi-Page applications (MPA)
  2. Single Page Applications (SPA)
  3. Hybrid Approach that is a multi page variation of single page applications (MSPA)

Multi-Page Applications

MPA development is the traditional style of development that has existed since the birth of the internet, HTML pages are rendered via a browser GET request and the Saving form data is done via submitting the page using a POST request and then the browser re-rendering the page again.  This type of application is noticeably different to how a desktop application behaves. Could you imagine reloading your desktop application every time you made a change? The reason for this distinct difference is that the web was not designed for application development, application development was adapted to the design of the web. Applications following the MPA  design pattern, their HTML/Pages are traditionally generated on the server. Think ASP, PHP, JSP, or our personal favourite Oracle APEX.

Multi Page Application Design

Single-Page Applications

SPA development is a more modern approach that evolved around 11 years ago, quite some time after the introduction of XML HTTP Request (XHR/AJAX) around the year 2000. In an SPA, all necessary code – HTML, JavaScript, and CSS – is either retrieved with a single page load, or the appropriate resources are dynamically loaded and injected into the page as necessary, normally in response to some user interaction. This decreases the size of the requests, because instead of returning HTML and data combined, the server returns the raw data in JSON format and the browser merges this with an HTML template defined in a framework Javascript file. This means that the data is now separated from the presentation, allowing more reusability and flexibility. Your page is never POST(ed) and re-rendered. HTML content is dynamically injected into the page. Because of this avoidance of page reloading, an SPA application provides a much better user experience, increased performance, whilst maintaining screen context i.e. the user is not interrupted and does not lose their position on the page. Users of these applications are far more productive using this type of application (if it’s designed well, of course). So we can say that this type of application is suited for an application that is heavily used by its users or when fast access to a lot of related data is required.

Single Page Application Design

Hybrid Approach

The hybrid approach is basically an application made up of multiple single page applications which are more likened to business modules. All interaction is done via AJAX, you just might switch your main viewing page to another when visiting a different part of the application. This helps reduce complexity and the footprint in the Browser/DOM. Could you imagine how much HTML would be rendered if E-Business suite was in one HTML document?

Client Vs Server

Lastly, whilst we finish the topic of design, there is one additional dimension which we should mention i.e. where are the web pages/code generated? Are they in static files or generated on the server? Generating HTML/Javascript on the server adds additional overhead on your server but allows for you to tailor the page design based on who the user is or what role they have or other changing variables/conditions. The downside to SPA applications is that they are made up of static files which require all conditional logic to be built-in and exposed on the client, resulting in a larger download requirement i.e. Javascript files are larger.

Did you know? The overhead of the APEX engine generating an APEX page is less than .02 of a second. There have been many discussions on the scalability of APEX, none better than the usage of Oracle itself mentioned here by Joel Kallman.

So what type of framework is APEX?

APEX was first designed in 1999, and by design is a multi page application (MPA) framework, since this was the only design pattern at the time. APEX is now almost 20 years old and has constantly evolved. It is a great low code development tool that allows us to create many types of web applications or websites declaratively. APEX, over the years, has included more and more feature rich functionality and adopted more and more AJAX capability i.e. partial page refresh which is the cornerstone of an SPA design but this capability is only limited to refreshing/filtering/saving reports or charts, or executing PLSQL Code. DML Forms require a page submit.

To explain the concept behind APEX in a bit more detail,  the applications we build with Oracle APEX are a set of HTML “Pages” which we navigate between to view data or submit to save the data. We design our applications with the concept of shared components that we define once to show up on each page so that it appears like a regular application. e.g. navigation menu, top toolbar etc. Pages have to reload every time a user performs a submit action to save a FORM, or when navigating to other another page. The following is a demo showing this multi-page concept and how disruptive it can be for the end user when switching between pages.

[This post contains video, click to play]

There are many types of applications or websites that APEX is suited for, but building a sophisticated Single Page Application is not possible “out of the box”, and thus limits you to building an MPA style application. The reason is that it was simply never designed for this purpose.

What are the main SPA frameworks?

There are many open source and commercial Javascript frameworks/libraries, and many have already come and gone, but the current main players are Vue, React JS, and Angular. The thing about using these frameworks is that you will actually end up using several libraries together like React JS and Redux, plus you will use build tools like Webpack, Grunt, Gulp, Browserify, Yeoman, Brunch and you’ll need Node.js as well. In our opinion it’s a complicated set of tools/libraries to learn for beginners compared to getting started with Oracle APEX.

Fortunately there are builders/IDEs that make SPA development easier which are using these frameworks underneath, such as Outsystems, Vaadin, Appery.io etc. Oracle has also introduced it’s own rival cloud service named Visual Builder Cloud Service (VBCS) built on top of its own Javascript framework Oracle JET (Javascript Extension Toolkit). The JET toolkit is a component library built on top of jQuery, jQuery UI, Knockout, and Require JS. The main characteristic of these builders is that they generate all the client side code and access the data via REST. By rendering everything client side they miss out on the benefits of serverside rendering. Client side rendering will mean that all the business logic and code must be downloaded to the client, whilst serverside only presents the generated HTML/CSS/Javascript, keeping the business logic more secure. Serverside rendering can also make showing customized displays much easier and reducing the clientside code footprint and complexity. So switching to a client side rendering approach does have some negatives.

Lastly, Javascript frameworks can be quite complicated to understand and learn, especially if your background is functional programming like PLSQL. They use Object Orientated Programming (OOP) and design patterns like MVVM and MVC. If we consider APEX, it’s still thriving after almost 20 years and is a safe bet and a very productive and cost effective one as it’s simple to learn and use. The main reason for this simplicity is it’s declarative/low code, but also gives experienced developers full control. With APEX, everyone does not need to be an expert to get started and be productive.

Why would I want to build a Single Page Application in APEX?

APEX has many unique characteristics that you won’t find in any other framework. The following 6 characteristics sets it apart from every other development framework.

No.1: it runs within the Oracle Database, it’s at the same level of your data negating the need for a middle tier (Java need not apply). It’s perfect for data centric applications. You have full access to all database capability, and as of 18c the Oracle database packs a very long comprehensive set of features.

No.2: it’s meta data driven. Using SQL you can query everything that is designed on your page, or in your application, and you can do this at the point of page rendering or in every AJAX callback. You can even generate applications/pages/regions etc. using the same API’s the APEX builder uses to create your applications. The power and solution capability this gives you as a developer is not widely publicised and in our opinion is really underrated. There is no other development framework out there that has this design, APEX is truly unique!

No.3: is serverside generation, you can programatically output HTML, CSS and Javascript on the fly. This can be on page render or for AJAX callbacks. The benefits of server generated Javascript is not widely publicised either. Again it can reduce your client side foot print drastically as well as reducing client side coding complexity.

No.4: we can build visual appealing applications really fast with APEX, and they are super easy to deploy and maintain.Thanks to the universal theme and Theme Roller you can achieve a modern look and feel whilst adhering to corporate colour conventions. APEX has an extensive and mature PLSQL API, and also built-in REST support thanks to ORDS (Oracle REST Data Services). As shown in the earlier infographic, APEX is continually evolving and adding more and more features.

No.5: the low code design makes it easy for beginners to become productive, whilst it provides full control for experts. Comparing this to a SPA framework, it caters for a much broader range of developer skillsets, even business power users can learn APEX! Think of the cost savings in training and development.

No.6: licensing cost, yes Oracle is expensive especially when compared to the many open source databases and development tools out there, but if you don’t have a data foot print above 12G you can use 18c XE, ORDS, and APEX for free. You can also deploy this on cloud providers that can charge as little as $5 a month for hosting. So for people not using Oracle yet there is no entry barrier for adopting APEX. You could even use REST to access data in remote databases if your data requirement exceeds 12G. There are solutions to keeping costs to a minimum for small businesses. For everyone else already using the Oracle database it makes sense to use APEX, it’s really crazy if you don’t.

Lastly there’s also productivity apps that come with it like Quick SQL which is a markdown editor that can quickly build your data model and also generate a dummy dataset. You can also quickly build prototypes using APEX, comparable in time to using a wireframe tool. The difference being you have a functional application to preview, making the choice to use APEX that much easier.

What is a SPA user experience like?

If you are still wrapping your head around a single page application design style, let’s consider the APEX Page Designer introduced in 5.0. Whilst the APEX builder is not a single page application the Page Designer is modelled on a single page design style. Prior to APEX 5.0 there used to be a set of pages that were used to edit pages, regions, items, buttons etc. and you would find yourself navigating from page to page to page. This requires many clicks and page reloads to make your changes.

[This post contains video, click to play]

With the new page designer you can do everything on one page without interruption including saving Form data without reloading the page and keeping your screen context. It makes you somewhere along the lines of 5x more productive and in some cases like the multi-selection/editing capability of items/regions you can be 20x more productive. This is the type of performance benefit end users get from a SPA application over an MPA application. It’s this type of user experience and productivity benefits we want our customers to have in the applications we build. How much more efficiency can be gained and time and money saved when both developers and the application users are more productive using an SPA design over an MPA design? It can be quite a lot!

Can I build a single page application in APEX?

Using out of the box components you can build a single page application in APEX but everything would need to be created on one page. It literally is a single page application (minus the login page). You could argue that you can use dialogs to edit report content defined on this one page but from a technical point of view they are separate pages opened within an iframe within the dialog so they still mimic a single page design but are still using the MPA model since a page with a form is still POSTed back to the server. It’s a very limited design choice and is only really applicable for very small and simple SPA applications. If you start expanding on this iframe approach you will still end up hand crafting a lot of code (just look at the APEX dialog code).

So for the majority of applications you’re then back to building a multi-page application. For many developers this design pattern is fine with them and their customer base. For others, that want/need to build more sophisticated applications using the SPA design pattern, they’re going to have to learn a Javascript framework or look at an alternative GUI option e.g. Oracle’s Visual Builder Cloud Service, or Outsystems. However these frameworks are very different in terms of design because they are static and miss the whole dynamic nature of APEX, so you will be making tradeoffs.

If you are wanting to use APEX to build a sophisticated application, you are going to have to make some design trade-offs following the MPA design. These tradeoffs have an impact on end user productivity. You can however reduce theses trade-offs by implementing your own customizations, but your low code app starts to become a high code app that will take longer to build and maintain, which results in much higher costs. This results in the SPA frameworks looking like the better choice.

So what if you wanted to build a real SPA application in the same way you would a regular MPA application in APEX without losing productivity? Is it possible? The answer is: Yes you can!

Ok, so how can I build a complex Single Page Application in APEX?

APEX is extendible thanks to the plugin architecture. Using the APEX plugin architecture you will hook straight into the page designer and it’s no different to regular APEX development if you follow the same approach of providing support for conditions, authorizations, build options, read only etc. Currently the majority of APEX plugin developers are using it for single functionality use cases like nested reporting, multiple file upload, new LOV items etc. but you can take this a step further and plug-in an existing SPA Javascript framework and provide a reusable declarative set of regions, items, processes, and dynamic actions that are designed to work together to form a single page application design approach to building your application. This is what we did, building the FOEX Plugin Framework for Oracle APEX. Using our framework you can build a single page application in APEX using everything that APEX has to offer. You can choose either design style where it fits best, even within the same application.

This means that the complex applications that would have normally gone to other technology groups i.e. the Javascript, Java, .Net, Angular, React team, could now be “Built with ❤ using APEX“, and in much less time. Think of how much time could be saved on developing these complex applications when we use APEX? Here’s a recent quote from Joel Kallman on this exact subject:

Real customer quote today:

“We also produce more quality app dev output than any other team I’ve met in less time, with lower budget and fewer people – I have to be diplomatic when I point this out, lest any feathers be ruffled. The opportunities for us with #orclapex are vast.”

— Joel R. Kallman (@joelkallman) December 13, 2018

In summary if we look at the features for the design patterns available to us, it makes sense that we choose tools that are flexible and supports both our needs now and for the future. APEX, combined with FOEX ticks this box!

 
MPA Framework
✔ Serverside..
Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
FOEX Blog by Peter Raganitsch - 5M ago

A great feature that has been introduced with Oracle APEX 5.1 is a new way to install / upgrade an existing APEX instance to a new version.

Previously installing a new version of APEX meant shutting down access to that server for your end users for the entire duration of this installation.

Now it is possible to reduce downtime to a short part of that installation.

Here is how this works

Instead of using the script apexins.sql to install APEX into the database, there are 3 scripts to initiate each phase of the installation process. For sake of similarity, all scripts take the same arguments as the original apexins.sql

  • @apexins1.sql – creates the new APEX schema (ie. APEX_180200) with all tables, views, packages, but no data. In this phase the old APEX version is still active and can be used without limitations.
  • @apexins2.sql – now all application metadata is migrated from the old APEX schema to the new one. The old APEX version is still active, but in a readonly mode. No applications can be modified, but everything can still be used. In terms of a production system all apps continue to work and all end users are happy
  • @apexins3.sql – is the final phase and needs the usual webserver shutdown. Now the new APEX schema is being activated and the old one retired. Some leftover metadata (like the activity log) is migrated from old to new schema.

Wonderful Carsten Czarski wrote a great post about this feature and explains it in more detail. See also the documentation about Maximizing Uptime During an Application Express Upgrade.

Using this staged installation process we could minimize downtime of our live systems to less than 3 minutes.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

The evolution of Oracle APEX over the past few years was astonishing and it keeps getting better with each new version.

But, what about the developers and organizations using APEX? How do they deal with it, what do they value, what do they wish for?

Nobody really knows, this is why we set up a Survey (of course using the “Survey Builder” Packaged App) to learn more about the State of Oracle APEX Development.

We want to invite everyone to participate in the survey over the next few weeks. After that we will compile a report and give that back to the community, so everyone has a better understanding.

Please remember this link: https://www.foex.at/state-of-apex-development it is the starting point of the survey and will also host the report, once it is available.

Before we published this survey, we also reached out to Joel Kallman and Jürgen Schuster, to get their input and improvements to the questions we ask.

If you want to see other question for next years edition, please tell us in the comments.

There is more: just as we wanted to start the survey, Mike Hichwa sent out a tweet poll which you also should definitely answer.

The Oracle APEX development team greatly values your feedback! Please take a moment to answer this question:

What do you most frequently use Oracle APEX for?

Thanks in advance!#orclapex @OracleAPEX @OracleDevs @OracleDatabase

— mike hichwa (@mikehichwa1) 30. November 2018

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

FOEX was founded in May 2012, since then we operated under the tryfoexnow.com domain. We felt it is time for a change and to make things simpler.

The time for trying is over, welcome: foex.at

Everything else stays the same: our dedication to improve APEX, to support our customers, and to build #enterpriseAPEX applications

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

A rather common challenge we keep hearing about at conferences, meetups or in 1-on-1 discussions with other Oracle database professionals: How do I convince my company’s management (or even some of my fellow developers) to try / start developing with Oracle APEX?

While the typical myths surrounding Oracle APEX have been debunked in various articles which you can easily find online, how to you get the buy-in from your management (and fellow developers) remains an open-ended question.

Here are 5 key points that you can use to inform, educate and get the internal buy-in about using Oracle APEX as a development tool:

1. It comes with the Oracle database, at no additional cost

This one’s a bit iffy:

1. If your company is already using the Oracle database, then APEX comes pre-installed and ready to use. You essentially have access to a powerful development tool at no additional cost. Why not take advantage and get the most bang for your buck?

2. If your company doesn’t use the Oracle database – worry not: you can still get the Oracle Database Express Edition (XE). It is a free, small footprint version of the Oracle database that has been around since 2006.

Although it is limited to 11GB of user data, 1GB of memory and using no more than 1 CPU on the host machine, it’s a good starting point to begin developing your first app(s) with APEX. The Oracle Technology Network has plenty of articles on how to set up Oracle XE in different environments.

Note: we do not explicitly endorse one or the other option. Ultimately, it is up to you & your organisation to decide what setup fits your requirements best.

2. Build a prototype

Speaking of developing your first APEX application. One of the best ways you can introduce APEX internally is to build a prototype. Either start from scratch or simply use one of the packaged apps and tweak it to your organisation’s internal needs.

In addition to getting familiar to the key concepts of developing with Oracle APEX, you’ll be able to produce useful applications much more faster than you could with using other development tools.

3. Leverage your skill set

If you’re working with the Oracle database you already know how to work with SQL and PL/SQL. These skills will give you a big head start when in comes to building applications with Oracle APEX.

So, why should management care?

Think of it like this: it could save your company valuable time and money with (re)training the development team if they decide to change development technologies – especially if your company has a team of Oracle Forms developers.

4. Its functionality can be easily extended with plugins

One of the great things about using Oracle APEX is that you can extend its functionality with: either free plugins like those provided by the community on apex.world, or commercial plugins such as our own solution – FOEX Plugin Framework or the APEX SmartPivot Plug-in if they meet your requirements better.

Should your users’ requirements evolve and become more complex, using plugins is a great way to provide extra features without needing to write & maintain the functionality yourself.

5. The APEX community

This one’s probably a no-brainer, but seriously, check out the community that is being built around Oracle APEX. In addition to the official Oracle page here are some other resources to get you started:

  • Twitter – use #orclapex when asking an APEX-related question and chances are that you’ll get an answer pretty quick
  • apex.world – there you’ll find a wealth of info & resources: slack channels, job postings, conferences, meetups, trainings, free plugins and much more
  • BuiltWithAPEX – a community-powered website showcasing apps developed with Oracle APEX, that are being used around the world
  • Conferences – throughout the year you can attend different events where the APEX community gathers to share their knowledge. Although this is not a comprehensive list, check out at least one of the following events: APEX World, APEX Connect, APEX Alpe Adria, Kscope, DOAG, UKOUG and take the pulse of how APEX as a development technology continues to improve.
  • Blogs & Books – there’s plenty of technical APEX know-how shared by the community. If you face an issue while developing an APEX app, chances are there’s a book chapter or blog article out there providing the answer. Either that, or go on Twitter and ask your question!

Why should management care?

A well supported tool and an active community are key to getting as little headaches as possible when developing new applications, especially if you are transitioning from other technologies.

We’d love to hear from you and how you’ve introduced APEX to your organisation. Let us know what worked in your case in the comments below.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

That Oracle APEX is an amazing tool and rocks low-code development is public knowledge, still we often encounter developers which waste a lot of time and don’t use APEX to its full potential.

You will be amazed how easy it is, try to follow these 10 points:

1. Use the wizards

In APEX you can build up pages manually or by using the Create Page wizard. Usually the wizard is way faster and will build all pages in the same fashion. This helps in achieving a consistent look and feel of your application. It also does some extra work by adding a page to the menu, creating breadcrumbs, and so on.

Sometimes it is also faster to delete an existing page and rebuild it through the wizard, rather than adding new fields manually, ie. when the underlying table has changed.

2. Stick to the standard Oracle APEX functionality

By using APEX wizards you automatically use standard functionality. As such this will have the highest probability to work flawless also in future versions of APEX. Once you deviate from the “APEX way” of doing things, you will slowly drift into a potentially unstable application.

Wow, that sounds cryptic, right?

Here is an example: when you create a form page in APEX, you end up with a default Automatic Row Fetch process on process point Before Header. You now could decide that process point “After Header” is so much nicer and move the process over there.

With a bit of luck your application still works, but might break at some point in the future because Oracle APEX adapts its behavior and decides that this Automatic Row Fetch process has to run “Before Header”.

3. Use settings

All APEX components have many declarative settings to influence their behavior. Always try to stick to use those settings, before you try to code around it with PL/SQL or (even worse) Javascript.

Let’s take the “Server-side Condition” as an example. It exists for almost all component types and decides, whether a component is being available/processed, or not. As condition type you can choose a myriad of different options like “Item = Value” or “Request = Value” or “PL/SQL Expression”, where PL/SQL Expression should always be the last resort, as all other declarative options are actually faster processed.

Using a setting rather than coding around it has the advantage of being stable. If a future Oracle APEX version introduces some changes, those declarative settings will be adapted to continue to work.

4. Avoid custom code

As with the settings, custom code should always be avoided, where possible. Why is that? Every single line of code has a certain cost associated to it: you need time to write this code, to fix this code, test this code, and to maintain the code in the future (APEX/DB/… upgrades).

Also every line of code, no matter if it’s PL/SQL, Javascript or CSS has a risk of failure. Either now, or in the future. Are you the one on your team who understands JS and therefore use it everywhere? Good job, now nobody else can maintain this code anymore, because they do not understand what you did there. Unless you write a plugin and make it easy to use.

5. Use plugins

Plugins are a great way to extend Oracle APEX and teach it new tricks. Need a new chart type? A dropzone file upload functionality? Extending the Interactive Grid toolbar? A multi-column LOV? These and many more plugins can be found on apex.world or with commercial providers like our FOEX Plugin Framework, or the APEX SmartPivot Plug-in.

In APEX almost everything can be extended as a plugin, which is also a great way of modularization to re-use code. Writing plugins isn’t too hard and there are many great examples among all those open-source plugins on apex.world. So it is absolutely possible for everyone to look at an existing plugin and change it to fulfill your needs.

6. Leave UI fidgeting to the end

Especially for beginners who often try to accomplish a certain look: don’t get hung up on that and leave it be until everything else is done. Then ask yourself if it is really vital to achieve what you have in mind.

The APEX Universal Theme is pretty awesome and provides an up-to-date and modern web look. It also gets updated with each release of APEX and introduces additional features. That means the feature you are looking for might be introduced in the next version. It can also mean your handcrafted workaround (custom CSS) might not work anymore in the next version.

In case you don’t know what’s already possible, take a look at the “Sample Universal Theme” Packaged Application, which can also be accessed via apex.oracle.com/ut

7. Stay lean

This is more a general advise, rather than APEX-specific. You might be confronted with lots of requirements and you try to (over-)achieve. Take a step back and start with a minimum viable version of your application. Show it to others, customer, business unit, and take their feedback. It might already be doing what they want. And this way you can avoid to implement too many pages and features.

8. Reduce complexity

You know this one: let’s say there is a requirement for a form. And another one for a very similar form, with just a few changes. And maybe a third similar form with some additional unique behavior. Which way do you go? One form to rule them all? Or three very similar forms?

This is a tough nut to crack. In retrospect, after being caught in this trap myself quite a few times, I’d say go for the multiple pages/copies route. It seems to be a waste and duplication, but it also allows for very simple duplicates. Once a single case changes, you only have to adapt this one, not the entire (huge and complex) form.

9. Forget your past

Have you just started with Oracle APEX? Are you coming from some other background than web apps on top of databases? Chances are, that your existing experience and expectations influence what you want to achieve now with APEX. Don’t try to replicate Forms, don’t think of Excel, don’t mimic Notes, Foxpro or whatever.

Clean slate, new start. Use the right tool, but also use the tool right!

“Use the right tool, but also use the tool right” – How to develop faster with Oracle APEX
Click To Tweet

10. Question requirements

Business units or customers often wish for things they actually can’t comprehend. They don’t know if what they want is feasible, easy to achieve, within the technology limits, or even simply physically possible. Maybe they don’t know yet, that the old client-server days are over and we can now offer different solutions.

Go back and ask them about the requirement(s) and show them some APEX beauty. They might like what they see and forget about old stuff.

What else would you add to this list?

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

How to set up a Grid to Grid master detail in FOEX is part of the FOEX beginner tutorials series – an introduction guide for developers with no or limited experience in building apps using Oracle APEX and the FOEX Plugin Framework.

Prerequisites:

The end result will be a screen that displays two vertically stacked grids with the top one (an editable grid) showing a list of customers and their contact details and the bottom one (a read-only grid) displaying customer orders.

Here’s how it will look like:

Step 1: Copy the FOEX Template Application

The first thing that we’ll do after logging in to our trial workspace is to make a copy of the FOEX Template Application – Theme 42. We’ll rename the new app as My First FOEX App and assign it a new application ID (in this case: 112233)

Step 2: Create a new page in your application

If you have the FDA (FOEX Developer Addon) installed you’ll notice the new Create FOEX Page button that is now visible within the App Builder.

Go ahead and create a new FOEX page!

Step 3: Create the Customers region

You’ll notice that the new page you just created has a Viewport and Center Pane region set up by default. Select the Center Pane, then use right click to select Create FOEX Sub Region.

Our first grid will display customer info, so let’s name it Customers and select Grid as the component that we’ll use.

Since we want to edit the customer data we’ll change the Allowed Operations field to Create, Update, Delete , instead of Read Only.

In the Table/View Name field add: DEMO_CUSTOMERS . As you click out of that field, you’ll notice that the Primary Key Item and the Select Statement get automatically filled in for you (pretty neat, right?).

Now click Create and your editable grid is all set up.

Note: By default this editable grid is set to Row Editing mode. FOEX provides you with the option to switch to a cell editing mode in your grid, should that suit your users better.

To make this change:

  • In the App Builder from the left side panel select Attributes, under the Customers region;
  • from the right side panel, under Settings, find the Edit Mode field and change it to Cell Editing
Step 4: Create the Orders region 

To set up your Orders grid simply repeat the process from step 3 (select the Center Pane, then right click and select Create FOEX Sub Region) and make the following changes:

  • The name of your region should be: Orders
  • Leave the Allowed Operation field set on Read Only
  • For the Table/View Name use: DEMO_ORDERS

Step 5: Stack your regions vertically 

At the start of this article we mentioned that we’d like to stack the two grids vertically, therefore we need to change the Layout settings for our Center Pane.

Note: If you run the page at this point your Customers and Orders grids will get displayed in separate tabs (as seen below)

To get them displayed on top of each other select the Attributes section for the Center Pane and change the Layout field to Vertically Stack Regions (vbox).

Step 6: Setting up the Grid to Grid master detail 

Up until now we just created two regions Customers and Orders – but there is not connection set between them. Our Orders grid displays all records, independent of which customer is selected in the Customers region.

Let’s change that and make sure that when we click on a row in the Customers grid, our Orders grid displays only the information associated with that particular record. To achieve this we will create a Master-Detail relation between our Customers and Orders regions.

In the App Builder right click on the Customers region and select Create Master-Detail Relation. 

Note: In a regular APEX development environment, where the FOEX Plugin Framework is not installed, this Master-Detail wizard is not be available.

We have now created a new dynamic action, named by default Customers – Master Detail Relation. All we have to do now is to go on the right side of the screen and find the Affected Elements section, where we’ll set the Region field to Orders (FOEX Grid [Plug-In]).

Because we also want to make a distinction between these two regions, let’s change the UI settings for the Customers grid.

To do this:

  • select Attributes under the Customers region;
  • on your right side panel, scroll down and click the FOEX Config button;
  • change the UI field value from None to Success;
  • click Ok and run the page

Your end result should now look like this:

Congratulations!

You now have a functional grid to grid master detail relation between Customers and Orders!

Try selecting some of the records in the Customers region and see how your selection influences the results that get displayed in the Orders region.

Although this is a fairly simple example, it serves as a good reference point from which you can start exploring the development flexibility and additional functionality that the FOEX Plugin Framework brings to Oracle APEX.

There are many more types of master detail relations that you can set up by using FOEX components and we’ll explore them in future articles.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

We are happy to announce the release of FOEX 4.0.1 which is now officially compatible with the latest version of Oracle Application Express: APEX 18.1. This patch set release is a minor release that contains primarily bug fixes and the following enhancement:

You can now choose to ignore grid column filters and sorting from state saving by adding the following additional JSON config settings to your grids:

"saveSortState": false,
"saveFilterState": false

We’re now busily focusing on v4.1.0 of FOEX and looking to introduce new features like:

  • Drag & Drop between multiple grids and trees
  • Drag & Drop re-ordering of grid rows
  • A new screen capture dynamic action
  • New color picker item plugin
  • New toggle switch button
  • New signature region plugin
  • Next page scrolling pagination for grids and LOVs
  • FDA Improvements
  • Plus more….

Finally we’re also doing some R&D on whether we can load JET charts into the current page i.e. Single Page Application mode. If we can, this will be a big step in terms of complex dashboard capability with optimal performance.

Read Full Article
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 
FOEX Blog by Cristian Anechitei - 11M ago

APEXIA is an Australian IT company specialised in using Oracle technologies. They have been using the FOEX Plugin Framework to build complex business applications for some years now.

We had the opportunity to speak with Raymond Allo, Principal Consultant at APEXIA, and got to know more about his business and about how his team uses FOEX to meet customer requirements and deliver complex business applications with significant time and cost savings.

Q: Hi Raymond! Can you tell us a bit about APEXIA?

Absolutely! APEXIA is an Australian-based IT company with over 25 years of Oracle experience. We specialise in developing business solutions using Oracle APEX and offer a broad range of other services in the areas of Oracle Database, Middleware, eBusiness Suite and Hosting.

Q: You are using FOEX for some years now. How did it all start?

Let me start by giving you a bit of background: our customers have been traditionally larger organisations who have used Oracle Forms / Reports over the years. As these companies began their transition to the Web, things started to change and since Oracle Forms was not suited for creating web applications many of them started to look for alternatives and began developing new applications with Java or .NET .

From our perspective, we felt that building applications with Java or .NET was not playing to our strengths, nor did it make sense since Oracle was providing us with an already great tool: Oracle Application Express (APEX), previously known as HTMLDB.

We used it on a number of projects with great success, including one where we replaced an Oracle Portal project. But realistically HTMLDB/APEX was not very well suited to replace the more complex applications what could be built in Oracle Forms.

We had a good tool to cover our basic development needs, all that was missing were the plugins that would add the custom functionality requested by our customers.

In our research we stumbled across the FOEX Plugin Framework. The functionality you offered was just what we were looking for but at that time the licensing model wasn’t the right one for us, so we went with another tool which was pretty much PL/SQL based and gave us the ability to write complex transactional applications. Similar to FOEX, it was also using Ext JS in its framework.

Q: What made you re-evaluate the FOEX Plugin Framework?

Our productivity wasn’t as good as we’d initially hoped for with this PL/SQL based tool, even after using it for more than 1 year. Furthermore, we noticed that the vendor had no plans to upgrade the Ext JS version used by their product, so we ran the risk of missing on the functionality that later versions of Ext JS would introduce.

Fast forward 15 months later, we touched base with FOEX again and found out that the licensing model had changed. It made an interesting proposition, since we liked the product and could see how much time & money we could save for our customers.

We reached out to the FOEX team and after a detailed discussion I decided to give myself one week to evaluate FOEX and make a decision. At the end of the evaluation I was hooked.

I could go back to using APEX, and with FOEX I could build the complex transactional applications required by ourselves and our clients.

Still we were facing the daunting task or rewriting the application we began building with the previous development tool. It took us 12 months to develop it and now we had to redo all of that – it was not an ideal situation for us. Surprisingly, it took us about 5 months to rewrite the whole application by using APEX and FOEX.

It was the best decision we could have made!

Q: What about your customers? Weren’t they expecting to use the app already?

Of course they did. On our side the decision was easy, but before switching technologies we also had to discuss and get the OK from our customers.

I presented them with a POC of the application that we built with FOEX and told them they could keep on using the already developed application until we caught up, and only then switch over to the new APEX / FOEX app. They liked our POC and agreed with making the change once the functionality was built.

We managed to rewrite 80% of the application in about 3 months’ time.

The added benefit of going with FOEX was that it gave us a much richer UI and had the flexibility to redesign parts of the application in order to take full advantage of that.

Q: Tell us a bit about the app you have developed?

Well, there are actually two applications which we developed. A multi-level marketing application that integrates with a web shop, accounting software, has apps for web sign-ups, sales consultants and for the head office. It integrates with MySQL, SQL Server and Oracle.

The other app, the one that I’ll talk about in a bit more detail, is a SaaS application that will be publicly available in the near future. Currently it is still being developed using FOEX 2.x, but we plan to upgrade to FOEX 4.0 soon. This also allows us to implement a number of nice new features which are on our to-do list.

To describe it: this SaaS application is focused on small/medium businesses which handle repairs. The concept was born out of the requirement of a computer repair company specialising in repairing and refurbishing Apple equipment. We found that we could make the application more generic so that it can be used by other repair and service companies.

APEXIA’s SaaS application built with Oracle APEX and the FOEX Plugin Framework

Since switching to APEX and FOEX we created pre-built templates for a number of different vertical markets, like computer repair, bike shops and small manufacturing. We also developed a special module which is optimised for the car service industry where more specific details for service and repair management are required.

It also handles all sides of a repair and service business: scheduling, inventory, purchasing, sales, invoicing, job and time management. The app has interfaces to a number of cloud based accounting software solutions (XERO, MYOB, SAGE) and to desktop versions of Quick Books and MYOB through simple CSV files.

The system also has interfaces to a number of spare parts supply companies for the car industry for ordering part on business accounts.

At the moment we are still in a closed beta trial with several dozen companies across different industries as our early adopters. One of these companies is a large franchise with 180+ shops across Australia.

Q: What FOEX components were most helpful for building these apps?

The FOEX Form and FOEX Grid were among the most heavily used components, but the FOEX Content Loader was the plugin which provided the most value to our applications.

We found that one of the most loved features of our application is that a user can open up multiple sales orders at the time. This is such an incredible time saver in sales and invoicing.

Let me give you an example: a sales consultant is working on a sales order and gets a phone inquiry from a customer about other order. In most web applications you will have to save the order you were working on, open the sales order that the customer inquires about and when finished, bring back the initial sales order to continue to work on it.

With FOEX we can open multiple sales orders in tabs and work individually on them.

Q: How did you get up to speed with how to build apps using FOEX?

We certainly had some challenges to overcome initially, but the FOEX forum provided us with incredible support during our development – and, of course, it still is one of our first points of contact with the FOEX development team.

Q: What advice would you give to anyone new to FOEX?

In the beginning we needed some help getting our head around some of the FOEX components and how they work in combination with APEX.

What helped us the most was the demo application / cookbook that FOEX made available in their documentation app. It allowed us to look in detail at how things worked and taught us some good development practises.

We also found that some of the apps that we need to develop now with FOEX require less coding, as more and more can be handled declaratively by the FOEX Plugin Framework.

Q: What about results? How do you measure the success of your projects?

There are many moving parts in each of our projects, so obviously you cannot point the finger and say ‘that one thing alone made me more productive’.

What I can say though is that FOEX allowed us to build applications with a main focus on increased flexibility and a user interface that provides measurable time savings for our customers. One of our customers told us that the average time to service a client has decreased from 10 minutes to 5 minutes since working with the app we developed with APEX and FOEX.

That is a great time reduction for their business as it takes the pressure off the sales consultant and customers waiting in a queue get the support they need much quicker.

FOEX allows us to actually focus on the business solution instead of having to spend time on the technical side of things.

We do not need to build plug-ins or extend the applications functionality with JavaScript. So far, we never had the need to go down that path and anything we wanted to do we could do with FOEX. This results in an application which is very easy to maintain and extend.

In addition to this SaaS solution we have used this tool to develop a number of applications for external organisations. One of the things that our clients like is that the FOEX Plugin Framework is a commercial product.

For a number of large clients this is extremely important.

Conclusion

We’d like to thank Raymond for taking the time to speak with us and share an insider’s view of how to successfully develop business applications with Forms-like functionality using the combination of APEX and FOEX.

This is yet another example of the flexibility and additional functionality that the FOEX Plugin Framework brings to Oracle APEX, transforming it into a powerful tool with results comparable to other, better established development frameworks.

We are thrilled to know that APEXIA considers FOEX a vital cog of their booming business and encourage anyone who is currently developing, or takes into consideration to develop complex business applications with Oracle APEX, to sign up for a FOEX free trial and take it for a spin.

For a more detailed overview of APEXIA’s SaaS application, please check out the FOEX Showcase Applications page.

Read Full Article

Read for later

Articles marked as Favorite are saved for later viewing.
close
  • Show original
  • .
  • Share
  • .
  • Favorite
  • .
  • Email
  • .
  • Add Tags 

Separate tags by commas
To access this feature, please upgrade your account.
Start your free month
Free Preview