What Puzzles Me About Apex

Question

Recently I needed to rearrange nearly 50 columns in a "classic" type report in one of my Apex 4.0.1 applications. It was so laborious and tedious. In the "Report" tab, one by one I had to click the up or down arrows on each successive row, all the while keeping my eyes focused on where I was in the report lest I overshoot my target destination and, horrors, lest I mistakenly move the "wrong" column. It was an exercise in patience. How I longed for a simpler way to do this. Even having the option to move an item entirely to the top or entirely to the bottom of the column stack (as supplied for a "shuttle" item, for example) would have helped. But, alas, not even this amenity exists.
After finally completing this task, I began dwelling on other areas in Apex that I (and if one searches through just this past year's posts in this Forum, others as well) find frustrating. I wanted to know what others and, especially, members of the Apex development team, think about these things. Hence, the reason for this post. I am puzzled why the following things have not been addressed.
1) As mentioned at the outset, there is not an easier way to rearrange column ordering in both "classic" and IR reports. When reports (commonly) have 25 or more columns, and especially if one requires one or more columns to be moved from one end of the stack to the other, this is a productivity killer.
2) The Apex API makes it easy to create all sorts of objects within a region: text fields, display only items, dropdowns, popups, and now even JQuery like dynamic actions. But the one item that Apex does not make it easy to create is a hyperlink. This has always puzzled me. Surely one of the fundamental constituants of the web is the hyperlink. All Apex offers are fields (on forms, within SQL queries, etc.) in which the developer may construct a link. But there is no interface that walks the devleoper through the process of creating a link. One may say that creating a link should be one of those basic things every Apex/web developer ought to know. But one may equally apply that logic to most of the other aforementioned items. And I believe creating a hyperlink is more complex than creating, say, an input text field. Instead, one must muddle through the docs or look at previous examples to figure out how to construct an appropriate link. Why is there no step-by-step interface in the Apex API to help with this? There is for, say, a text field or a dropdown, but not for a link. Strange.
3) You need to create a form with 10 columns and 15 rows. Forget it. Apex complains about "a 100 cell limit on a form". This is another one of those puzzlements. What is the rational for this limit? It is so un-realistic and does not jive with today's business requirements. I first ran into this limitation on a form way back in version 1.x. And here we are three major versions ahead and we are still looking at this limitation. Why?
4) A fellow developer recently needed to import a page (not the application, just one of the pages) from one workspace to another. These two workspaces happened to reside in different Oracle instances (Dev and Prod).
Unlike importing an entire application, there is no intuitive way to do this. Instead, one must go into the actual export .SQL file and modify several of the included parameters. And even this is not straightforward. Surely, there needs to be an easier way (meaning, automatic way as in clicking a few buttons).
5) Years ago I used Microsoft's FrontPage tool to create a website. One of its nice features is the ability to automatically generate a "site map" of your website. A diagram would be created in which one may easily see which page "calls" or "redirects" to another page. Over the years I have either created (or inherited) Apex applications that sport 50 or more pages. Starting with, say, page 10, have you ever tried to figure out what page(s) called or redirected to page 10? If your Apex app only has 5 pages total, this is not a big deal. But with 50+pages, this is a big deal. A sitemap would have proved an invaluable productivity enhancer at this point. You might think, well, this would be a great Apex plugin idea. And you would be correct. But what puzzles me is that shouldn't this be a builtin "feature" of the Apex API, especially in a fourth major release of the product? Yes, I'm aware that Apex provides views from which one could gather this type of "which page called another page" information. It's just that I am using an API for the main purpose of making database/web development faster/easier. From a business perspective, this means saving money. For example, strictly speaking one need not bother with JQuery. Everything JQuery can do can be done using straight Javascript. It's just that JQuery provides an API making it much easier to implement common Javascript tasks. It's the same with the Apex API. I should not have to wait for someone to create a "sitemap" plugin. I realize that creating such a sitemap is not trival. Still, the logic/algorithm has existed for years as seen in FrontPage, DreamWeaver, and other APIs. I am puzzled why the APEX API does not already include this feature.
6) Recently, I needed to position several text fields within a given region of a page. It proved to be another exercise in patience. I needed to muddle with css style tags. Save my work. Refresh another browser window in order to see the results. Then go through the whole exercise over and over. Worse, while positioning a field I unitentionally moved other fields and regions into un-expected places on the screen. Worse yet, IE (version 8 and 9) caused these items to appear one way while Firefox (version 3.x) positioned them a different way. When the dust finally settled, I fould myself pining away for a tool like DreamWeaver in which I could just use my mouse to position items on the screen, all the while in the background the tool writes the necessary css style tags (cross browser compatible to boot). Yes, I realize that the Apex API is a "declaritive" environment, not a "GUI" based one. Still, in my code-tempered brain, I believe there is some way to meld the two and make it easier, more intuitive to position fields and regions on a page. This, too, is a great puzzlement to me.
Reading this, one might conclude that Elie is really "down" on Apex. This would be wrong. On the contrary, I like Apex quite alot and have been using it at my various work places over the past seven years. As mentioned at the outset, I wrote this out of my frustration in completing a task that I would have thought should not be so tedious.
Things like dynamic actions are, indeed, useful and even "cool". But in my experience I have found the more "mundane" tasks like rearranging report columns and positioning fields on a page and deciphering the page flow in a website are the things that developers spend the most time on. These are the things that any database/web development API should be attempting to streamline.
So, I am wondering why the above issues (and likely there are others) have not been addressed despite the fact that we are now in the fourth major release.
Thank you.
Elie

Answer 1

Hi, VANJ.
I want to thank you for your comments.
With respect to:
[1]: I did not realize that the "tree view" offers report column rearrangement. I'm so used to using the Component View that I did not bother to check the Tree View all that thoroughly. I guess, then, "I need to".
[2]: I was referring to an Apex interface that allows developers to create different types of links (absolute; relative; specify targets such as "_self", "_blank"; specify anchor tags; mailto links). Especially, I was looking for an interface making it easy to specify the various parts of an Apex link such as the debug flag, the printer friendly tag, and the "pass item/value" pairs tags. I realize none of these things are terribly difficult. Still, I at least cannot always remember the correct syntax for these different types of links. And this is especially true for the syntax needed for the Apex type links. I often need to refer to online docs and such. It just would be a time saver if the Apex API would offer such an interface much like it currently does for many other web ytype components like input fields and such.
[3]: I had always thought that the 100-item limit refers to"100 cells" in a form. I did not realize that this is referring to 100 page items. That said, I would have sworn that I had received an error about this limit on a form page. And I definitely did not have more than 100 page items on that page. I am not sure if the 100-page item limit also includes "page 0 "type items since these appear on every page in the application. In any case, I seriously doubt that I had anywhere close to 100 page items (page 0 or otherwise) on my form page when encountering this limit. Also, considering the numerous comments on this Forum about this "limit", I doubt that these unfortunate souls also had more than 100 page items on their page when they experienced this same "limit". In any case, it's an easy thing to check out, and so, I will do that.
[4]: What I had hoped for was a GUI type interface that just makes it "drop dead simple" to copy a page from one workspace to another, similar to the intuitive interface Apex provides to importan entire application. I had not heard of the apex_application_install utility. I'll defintely be checking this guy out. Thank you. You said it offers some flexibility. By this, do you mean that it offers a way to import a page from one workspace to another?
[5]: Ah. We do agree here.
[6]: Thanks for mentioning the drag-and-drop feature. I had tried this out and unfortunately it just doesn't really help with respect to positioning regions and items on a page in a cross browser compatible fashion. A WYSIWYG interface would be a great feature in such a robust API as Apex.
Since creating my post, I thought of yet another couple of "puzzlements" I have with the Apex API.
7) I wonder why one may include only a single IR report on a page. This has always baffled me. I am aware that one can create a page containing multiple iframes. And then populate each iframe with an IR report that really resides on its own separate page. I've tried this technique and it works very nicely. Still, I can only wonder if the good folks at Oracle/Apex will one day make multiple IR reports ona single page a builtin feature rather than having to rely on this iframe workaround or a JQuery set of page tabs workaround.
8) Again with respect to IR reports, I am puzzled why an IR report can be based solely on SQL as opposed to PLSQL. I did find a workaround to this limitation by using an Oracle table function as the underpinning of the IR report. This works. Still it is a kludge. And so, as with (7), I can only hope a future release of Apex will remove this limitation.
Thank you.
Elie