There are many new features in Oracle Application Express 4.1, including
- Data Upload - add functionality to your application so your end users can upload CSV data (similar to what you can use in Application Express SQL Workshop)
- Error Handling - Dramatically improved error handling, where you can define how exceptions are handled in your application instead of being constrained by the APEX engine itself. Patrick discussed this in detail here and here.
- ROWID - Instead of being constrained by one or two element primary keys, you can simply use ROWID as the unique identifier for Automatic DML forms and tabular forms.
- Websheets - Websheets have undergone a complete overhaul of the user interface, as well as some interesting new features, like the ability to create reports on SQL queries against DataGrid data.
- Tabular Forms - Many new features with tabular forms, including tabular forms processes and tabular form validations.
- Plug-Ins - Support for Authentication and Authorization plug-ins
- Calendars - Enable editing of data directly from links in a calendar, and also support drag-and-drop to move rows from one day/time to another.
- Dynamic Actions - Support added for dynamic actions against buttons, and other enhancements.
- Accessibility - Numerous accessibility improvements have been made in the templates and HTML produced by Application Express.
- Translations - Complete overhaul of the user interface, previously discussed here.
One obvious question is going to be "where is mobile support?" When jQuery Mobile becomes production software, we will include it in the very next patch set of Oracle Application Express. The infrastructure is there in APEX 4.1 to support it. And Marc Sewtz has promised to blog about how you can drop in the jQuery Mobile Beta into an APEX 4.1 installation. The jQuery Mobile Beta portion can't be supported by Oracle Support, obviously.
Our many thanks to the countless people who participated in the Application Express 4.1 Early Adopter program and provided feedback, suggestions and bug reports. We also owe a special thanks to the many Oracle employees who run their mission critical applications on apex.oraclecorp.com (an internal instance of Application Express, but for production applications, used by virtually every business unit in the company). They reported many issues and endured some outages while we rectified flaws in the upgrade process and Application Express engine itself. It is thanks to their patience and problem reporting that we were able to avoid embarrassing and reputation-breaking occasions for our customers.
13 comments:
Joel,
Congrats to you and the team - can't wait to go for a test drive!
Dan
and no support for Aix6!
that rules it out for us in future...
@Noons,
>> and no support for Aix6!
Is there a version of the Oracle Database that is supported on AIX6? If yes, then APEX should be supported there as well.
Joel
Thanks Joel and of course the rest of the team!
Learco
11gr2 is supported in 6. But the doco for 4.1 says it only supports Aix 5...
Ah well, I'll give it a try anyway.
After upgrading to 4.1, export application fails with "Error exporting flow 103. ORA-06502: PL/SQL: numeric or value error: character string buffer too small", only if setting "export translations" to yes. I could not find anything about this on metalink or google. Any suggestions?
Joel,
querying WWV_FLOW_TRANSLATABLE_TEXT$ helped to find "large" translation units. It was a region source with more than 7k length (a rather large select I would say). Deleting the region and re-seeding made the export problem go away. I think this maybe considered a bug by some - at least it should be mentioned in Apex limits.
Keep up the good work and thank you.
Hi Joel,
still struggling with importing application exported with translations. Two things:
1.the import creates the mapping but it can choose a translated application id ending with zero, which could cause a possible conflict in the decimal part of ids of translations
2.the imported translations in WWV_FLOW_TRANSLATABLE_TEXT$ retain the decimal part of the original mapping (the integer part is changed OK) so publishing the newly imported app won't use the imported translations although they can be seen in the manual edit of translation repository. For example let's say that I have an app with app_id 123 in primary lang 'de' and there's a mapping with app_id 1231 in 'en'. Export this with translations and import it back again to a different app_id. Let's say the new app_id is 543 and the mapping id (chosen automatically) is 131. Then
select to_char(translate_from_id),to_char(translate_to_id)
from WWV_FLOW_TRANSLATABLE_TEXT$
where flow_id=543 and translated_flow_id=131
produces:
...
18466620755357406 18466620755357406.1231
...
but this should be
18466620755357406 18466620755357406.131
Manually changing the decimal part of column translate_to_id fixes it and the app publishes all right. that is:
update WWV_FLOW_TRANSLATABLE_TEXT$ set translate_to_id=trunc(translate_to_id)+0.131
where flow_id=543 and translated_flow_id=131;
commit;
I'm not very comfortable with this...
@ltornyi,
Thank you for reporting these issues. These are actually two distinct problems within the translation process.
The issue with a translatable element greater than 4K is a complete blunder. This is logged as Bug 12927199 and will be fixed in the 4.1.1 patch set.
Also, the issue with the incorrect decimal portion of the translatable text ID after import is filed as Bug 12927540 and will also be fixed in the 4.1.1 patch set too. I believe an easy workaround to remedy this would be to edit and modify the translation mapping ID within Application Builder Shared Components.
Due to the egregious nature of both of these bugs, I have uploaded patch set exceptions ("one-off patches") for both of these to My Oracle Support. These can be applied to a 4.1.0.00.32 instance. You should be able to locate them by the bug number.
Thanks again for reporting these bugs and sorry for the issues created by these problems.
Joel
Joel,
thank you for your incredible support.
Joel,
I'm really sorry but it seems that when I change the translation application id on the "Application Language Mapping" page, the decimal portion of translate_to_ids in WWV_FLOW_TRANSLATABLE_TEXT$ does not change (translated_flow_id is updated correctly). I have not applied your patch yet.
Hi ltornyi,
Okay - thank you for letting me know. I guess even the suggested work around doesn't suffice and the patch will be required.
Joel
Hi Joel,
Very well presented. I'd like to publish your post about oae 4.1 at cloud apex www.cloudapex.com.
Post a Comment