Tuesday, April 22, 2008

A peek over the Application Express horizon

Well as Dimitri hinted at here we {The proverbial "we": I actually mean the development team ... I just talk about things - the rest of them actually make the magic happen :) } have been hard at work since releasing 3.1. and have lots of fun plans.

Once we have some more of our ducks in a row we will update our Statement of Direction on OTN. But here is some unofficial insight into what is on the drawing board (Not to be used in any way in making purchasing decisions).


With 3.1 we introduced a lot of new code and despite the best efforts of all of you wonderful Beta testers and our tireless QA team there were a collection of minor bugs found (I personally found a few very obscure undocumented features, why because when I develop applications I often use Oracle APEX in obscure ways). Therefore, we are busy developing a 3.1.1 release to fix issues.


Our team seems to get bored easily, it would seem, because we never seem to be content working on just one thing at a time. So while the push is on to get 3.1.1 out the door we are also working on Forms Migration. We already have a page, Application Express for Forms Developers, which addresses some of the key similarities of the two tools, but now we are working on a new whitepaper which should help you migrate your existing Oracle Forms applications to Application Express.

But that's not all! We are also working on additional built-in migration project capabilities. In much the same way we have the current 'Application Migration' section where you create a Project to migrate Access across we hope to provide the ability to provide tools support for migrating Oracle Forms applications. Using Oracle Form's XML conversion program we are looking to interpret the XML produced and derive the underlying design model to be able to generate Application Express components. As with the Access migration we don't expect to achieve 100% conversion but hopefully provide a valuable first-cut.

One very important difference between migrating Oracle Forms and Access is that Oracle Forms already utilizes the Oracle Database which means some of the messiest parts of migrating the Access application is simple not applicable. Another key differentiator between migration efforts is the developers. Oracle Forms developers have the perfect skill set for developing Application Express, namely SQL & PL/SQL used within a declarative framework. They already know all about the tables, views, packages, procedures, functions, etc. that the Forms were built on top of so most Oracle Forms developers should come up to speed very quickly.


We certainly haven't forgotten about Tabular Forms. Now that we have Interactive Reports and beefed up Printing & Report Queries to take care of many of the users viewing/reporting requirements it is time to focus on how the user maintains the data, and that means improving Tabular Forms. We hope to provide better declarative functionality to make it easier to meet your business requirements when entering data without needing extensive manual coding.


In the midst of all this we are also working on numerous other whitepapers on various topics. The first I expect to see on OTN (hopefully in the near future) is the APEX on RAC whitepaper.


Looking at what's on our plate and what we plan on doing next - I'm getting tired just writing this post. I hope this unofficial update helps to shed some light on what we're planning.

Regards,
David

13 comments:

Dimitri Gielis said...

Thanks for that David, now I don't need to finish that post ;-) instead I'll put a link to yours.

Dimitri

Marco Gralike said...

David,

it would be also great if it were possible to build in native support "xmltype" datatype support. This would "open up" a lot of native XMLDB functionality within APEX.

I would happily assist during testing for, for example an upcoming 11gR2 beta test period (if allowed).

Regards,

Marco
(http://www.liberidu.com/blog/?page_id=2)

Joel R. Kallman said...

Shouldn't this post have a title of "A Peake over the Application Express horizon"?

Joel

Joel R. Kallman said...

Marco - what kind of native XMLType support are you looking for? Can you provide an example of what you would want?

Joel

Marco Gralike said...

@Joel

probably the most easy way to start to implement (and the most exciting one regarding cool functionality) is using UriTypes

http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28369/xdb15dbu.htm

This will enabling out of the box html etc consumption, rss feeds, getting data directly in XML from relational tables etc (but I have a hunge that the APEX team already uses a small piece of this XMLDB functionality). If not, then I know a way which is way faster regarding exporting relational data via XML ;-) (I can do it via 1 URL "statement")

Directly accessing the Protocol Server functionality would be a cool feature anyway.

Regarding the XMLType Datatype. Implementing this is LOV's or drop down lists, besides strings, varchar, number, etc, would give us a direct method to enable XMLDB features from within APEX, without wrapping it in PL/SQL.

Mark Drake has made an example content management system app. featuring a lot of out of the box XMLDB functionality (including versioning and check-in / check-out functionality).

If you would set it up and try it then you would get an idea how APEX could replace all the javascript en UI stuff on top off it.

Mark's demo app. is called XFILES and a first glance (and possible followup URL's) can be found here:
http://www.liberidu.com/blog/?p=274

Forgive my enthousiasm on that post regarding APEX contra XMLDB remarks ;-)

Niels de Bruijn said...

Hello David,

I had a discussion with Carl Backstrom about the interactive reports. I really have to say that it is a great feature I have been using a lot, but it has one big disadvantage: except for the customizing features, you can't enhance the program code according to the customer reqs. This will often mean that I can't use the interactive reports feature, but have to build my one.

My opinion is, that in the Web 2.0 world we live in, it is imperative to make such code publicly available.

Friedhold Matz said...

Hello David,

really good news, many thanks !

As Forms programmer I prefer the migration way from Forms converted in XML to create static APEX PL/SQL Components.

Friedhold

haf said...

Hi,

Just want to know why you are going the XML route. It seems the JDAPI can give you pretty much everything you need to know about a Forms module. I already have done it with a migration tool (www.degenio.com) for forms 6i to 10g.

So the logic should be the same although the correspondence between Forms objects and APEX objects should be known beforehand.

Can you please comment on this correspondence ? Do you have something similar to JDAPI for APEX (I was told you can read the metadata for an APEX app).

Thanks

Hafed
www.degenio.com

David Peake said...

Haf,

We are using the Forms XML file rather than JDAPI as the XML contains all the information in a structure we can easily parse into Oracle Tables.

Once we have the information in Oracle tables we can interrogate the information to determine what is translated and how using PL/SQL.

APEX lives completely within the Oracle Database and its metadata is stored in Oracle tables, so yes it is possible to read the metadata, in fact we provide numerous views for just that purpose.

Regards,
David

haf said...

Thanks for the quick reply.

Is there a document that explains the architecture behind an APEX application ?

I am familiar with Oracle Designer and how the metadata is structured in the repository. It seems to me that APEX is using the same paradigm.

There is a document on OTN that explains everything as far as the Designer repository is concerned.

So my question (in order to spare me some time): Can you point me to something similar for APEX ?

I would love to try out a migration from Forms to APEX using the JDAPI. I am already testing my forms tool on a 1200+ mission-critical application (with close to 96% automated migration) and in my view the JDAPI would definitely be useful in a Forms to APEX migration.

Thanks.

Hafed
www.degenio.com

Friedhold Matz said...

Hello,

the Forms2XML converting process could also be a wonderful way to begin the declaration of APEX PL/SQL Components directly !
Other converter systems can not use PL/SQL generated code but we like it.

The XML declarativ programming, most only for GUI can you find by FLEX, XAML, XUL, Google Gadgets but we have the chance to declare the PL/SQL APEX Components with the GUI layout and action handling.
So you are going to see this by Suns JavaFX !

Here is a little Demo of a Forms2XML result presentation and so you can later present the APEX PL/SQL Components ;-)

Regards,
Friedhold

Friedhold's Oracle World

haf said...

Friedhold,

Yes, that's one very good way for handling APEX objects.

Hafed

David Peake said...

Hafan,

Our APIs are documented within the User Guide:
http://download.oracle.com/docs/cd/E10513_01/doc/appdev.310/e10499/api.htm#CHDIEDJH

Regards,
David