I was going to start the new year with something a little more light-hearted, but this has been sitting as a draft for a while and I thought I better not hold onto it for too long.
As I'm sure many people do, while developing with the APEX tool, I occasionally come across improvements that I would love to see in a future version of Apex.
And, as I'm sure many people do, I keep meaning to note these little feature improvements down so I can provide feedback to the APEX development team.
Recently I managed to pull my finger out and actually compile a list - some training recently has highlighted some of these features so I made sure I took note when I could.
Some of them are really minor - aesthetic or workflow adjustments that would facilitate more fluid development. Others are probably a touch more complicated... I think most are for the benefit of the developer more than the end user.
Some probably need more thinking over, and some I may have gotten wrong and there isn't a problem anyway - feel free to correct me where I'm wrong. I'm also going to steer clear of any mobile development issues. Here we go...
Minor - little improvements I don't think would take much effort:
- Navigation bar entry subscriptions - currently when you attempt to define a subscription for navigation bar entries, the list of values displays the alt image text - not the navigation bar label.
I don't have too many entries with this optional field completed, so it becomes annoying. - Hide quick picks on read only - it would be nice to have a declarative feature that facilitates this - possibly turned on by default.
Currently, if you conditionally set an item to read only, any quick picks are still present and clickable - hence updating the field. - Display date/time in form as read only: I didn't investigate this one in depth - a last minute discovery in v3), but short of changing application date format to date/time - I had a strangely difficult time presenting a date column in a form page as read only with full date/time - I often received ERR-1079 Error in item post calculation computation.
Feel free to direct me to an example of how this done, it wasn't a showstopper so I moved on.
Intermediate - slightly bigger, more involved improvements, but some of them may be easily achieved:
- Dynamic quick picks - this is a nice to have as we can fairly easily provide this using shortcuts (such weird terminology!)
However since we have the option to define static quick picks for an item, why not be able to alternatively provide a query to dynamically supply the quick pick options, or associate an LOV shared component. - API for page/item help - it is so often requested to facilitate the user to enter their own page level or even item level help. This requires it's own set of tables, template modification, supporting pages etc.
If we had an API to the Apex core to update these values, all we'd need are pages to allow the user to read/update the help text so we can retain out-of-the-box functionality. - View consolidating all comments - I originally thought this would be handy when playing around with the Forms migration tool. The annotations were great, but I thought how much handier would it be to be able to query one view to scan for relevant annotations.
Ditto (and more-so) for component comments. We have an integrated page level comments that are actively visible to the developer, but as component comments can very easily be lost, ignored, forgotten about - I think it would be useful to run a query over any comments found in any of the application components. - Greater usage of page alias - I think the use of a page alias instead of it's number should be more welcome within the development environment. This could apply to anywhere the link attributes are presented. This may also improve accuracy for users who bookmark pages within the application.
- Hierarchical validations - This was the first term I could think of. Currently we can tentatively apply conditions on validations based on failures of prior validations in the sequence using apex_application.g_inline_validation_error_cnt
I think if we were able to define some form of hierarchy for validations, just like breadcrumbs or parent regions, this would make a lot of Apex developers very happy.
I had a quick search for Apex wish lists before posting this, and Dan McGhan used the term validation chaining here. - Validating file uploads - recently I needed to validate a file loaded using the File Browse widget. These validations included file size (we had a small limit, thanks to Report Queries) & mime type.
I got there in the end, but it didn't seem very elegant. I'm not sure how easy it would be to provide settings for upper/lower bounds similar to those that numeric/date fields have. - Minimum date setting - relax the format restriction on the date when using substitution syntax.
- Report Layout update process - currently if you need to update a report layout, you need to delete the layout record; re-upload the layout document; then re-associate the layout with any Report Queries.
These are currently managed in separate areas of the Shared Components section, and if I remember correctly it takes 20+ clicks to achieve this process for one report. I jumped with glee when I found out recently I needed to update 50 layouts for 57 reports... not. It can't be too hard to re-jig these maintenance pages to allow a better workflow. - Dictionary views for Report Layouts/Queries - are these the only components without associated dictionary views? I thought I'd be able to whip up a query to see which Report Queries used the same Report Layouts, but alas... I had to come up with a fresh technique.
I got there in the end, and my update process for those 57 reports was impressively efficient, but both these improvements would make life easier. - Form limits - my colleague wanted me to include extending the number of items per page from 100. She encountered the limit recently, but I'm not sure the context -
- Multiple item copy - my colleague also would like the ability to copy more than one item at a time.
- Sequencing of next / previous buttons - when using the "<" and ">" buttons, ie - next / previous to scroll through Regions / Buttons / Branches etc, there seems to be no discernible order. If there is method to the madness, I haven't yet identified it. It should follow the sequence order. If that's what it's supposed to do, it's not evident in the behaviour.
- Build option enhancement - currently we assign a build option to a given component. This is great if it's new - but often there are minor tweaks on various attributes that we'd like to incorporate into a build. I find this even with template modifications. There are a few annoying workarounds, but I was trying to work out if it would be possible to incorporate a change to the Apex development environment.
What came to mind (without thinking too hard about the underlying core structure - but I don't think it's too far fetched) is instead of (or in addition to) being able to allocate a build option to a component, it would be great to be able to have a select list perhaps on the side-bar, or near the "apply changes" button that would allow the developer to snapshot those changes against a given build.
From another angle, when the developer is reviewing attributes for a component, they could view the current version (by default), or use the option to refresh the view for a given build option.
That seems an decent scenario for the Apex developer - but as I said, I haven't yet put thought to the implications is would have on how Apex would manage this meta-data, and possibly more curious - how it would decide what to render.
Perhaps the build option maintenance needs to be expanded to define chronology - and/or precedence. - Saved IR reports retention - While I have not had too many problems in the environments I've been working in, it's definitely an area that needs attention, and the Apex product managers are aware of it. The basic premise of my issue with it is some life-cycle plans rotate through application IDs - this means there needs to be a method of transferring saved reports in production from one application to another. The export process leans towards the idea of migrating saved reports from one workspace to another - which to me seems limited as saved reports are typically not going to be in your dev/test workspaces.
- Expand XML size for Report Queries - this was the cause for my file upload validation request. If you would like to send an image to a BI publisher report via a report query, you are currently limited to a files size of approximately 22k. After a little chat with Tim Dexter, and a lot of trawling through OTN - it seems there is a limitation of 32k per "record" sent via XML.
I can't remember where I put the sole forum reference, but after a quick search I found this 2008 posting by Marc Sewtz acknowledging the limitation and promising an update. It seems this limitation may affect charts also. I did attempt to use the print API instead as it seemed like a great alternative, however I came across what seems like some internal (Oracle end) scripting issues and I ran out of patience to persist. - More declarative options for charts - I'm not a heavy chart user, but it seems the AnyChart infrastructure offers more customisations than the declarative nature of Apex allows. For instance - the graduated colouring on dial charts, and adding links for the same.
Don't get me wrong, it's fantastic that it's possible to customise the XML sent to the engine, but I wonder how much work it might be to add context sensitive settings for the chosen chart style - even if it's done in a flexible manner similar to user-defined attribute pairs for Feedback.
Added since initial posting from comments / forum post - limited to only those I like - Jeff (2012/1/5) - New substitution strings such as APP_PAGE_ALIAS - and variables to return previous page details.
- Scott (2012/1/5) - New component in apex_application_install to accept clob that defines an exported Apex application
- Trent (2012/1/5) - Subscription module to team management
- Scott (2012/1/6) - Install supporting objects (stored as installation scripts) when running app install as script
- Wes (2012/1/7) - Filter objects in page definition by conditions; more options with search
- Andy 2012/1/7) - Declarative options for sub-totals in reports
- Matt (2012/1/12) - region/page level read only; row level cascading lov; extended APIs for tabular forms
- Greg (2012/1/15 - Documentation! - this is my favourite. I'm a huge fan of the db documentation, and the Apex documentation is still in its infancy. This includes item help - some are awesome and concise, some are not so much - typos in the help don't help the cause.
Oh, and please revert back to 10g style doco - I hate the new 11g doco with the "expand all" option, and the local doco that attempts to hit the Oracle website - I need to configure an extension to stop that... - Kofi (2012/1/13) - declarative popups
- Sas (2012/1/13) - alternate lov source for item
- Andy (2012/1/20) - Session expiry notificication
- Andy (2012/1/31) - (essentially) SQL based lists
Update: I gave up - replies went on for 6 months, 264 posts!
No doubt the APEX development team already have their 4.2 scope fairly set for an early 2012 release thanks to the jQuery mobile hype, but I'm sure there will be time to slot a few of these in if not target already - otherwise I can wait for 4.3 ;-)
Happy new year, everyone!
ScottWe
No doubt the APEX development team already have their 4.2 scope fairly set for an early 2012 release thanks to the jQuery mobile hype, but I'm sure there will be time to slot a few of these in if not target already - otherwise I can wait for 4.3 ;-)
Happy new year, everyone!
ScottWe
6 comments:
I added this on the Apex forum on OTN, and I thought I'd included this comment:
If I was to pick out 5 I'd like to see added, in order of preference:
1 - Lifecycle management (clear number one)
2 - Hierarchical validations
3 - API for help
4 - Report layout/query process
5 - Sequencing of next/previous
Scott
Can you add two for me - some new standard Apex variables:
&APP_PAGE_ALIAS.
&APP_PREVIOUS_PAGE_ID.
&APP_PREVIOUS_PAGE_ALIAS.
The first would fill in some nice gaps so I can use aliases everywhere; the last two would make it easy to add "go back to whatever page you came from" behaviour to pages that have multiple entry points. Apex would somehow have to keep track of the page history for the session so that when the user goes "back", it pops the previous page off a stack or something.
I concur with that idea. APP_PAGE_ALIAS would go hand-in-hand with more thorough usage of page alias instead of page numbers; and previous page would certainly be very handy for cancel buttons and the like!
Hi Scott,
Nice post. Some of these have been on my list for a while but others I've never thought of.
Can't wait to see what makes it into future releases!
Regards,
Dan
Thanks Dan.
Indeed, who know what surprises the Apex team will be creating as well!
- The ability to be able to change the application start page.
- More help on the various page types when selecting them. Currently there isn't any (I'm a relatively new user).
- Ability to convert a Wizard Report to an ordinary report. I NEVER use Wizard Reports now, but learned this the hard way.
- Ability to have more than 1 interactive report on a single page.
- Improved support for the date popup which doesn't like non-US date formats very much.
- An Oracle Forms type LOV. That LOV was one of the bext things about Oracle Forms - please can we have something very similar in Apex.
- The ability to make a field disabled and also have the value readable.
Post a Comment