We have received a lot of feedback on the evaluation version of our integration kit and the common theme is that it’s not flexible when it comes to page layouts (we kind of did this intentionally so we could gauge what people were wanting before developing something, there’s nothing worse then spending alot of time developing something no-one wants). So what are we doing about it?

It goes basically like this:

1. We will allow any one to create a new page template
2. You then register the name of this template in our viewport meta data table
3. Next you then register the viewport configuration parameters in our viewport config table, as per the config defined in the Ext API. Note: this excludes the “items” parameter. What this means is that you as the developer will have full control over defining the Ext config! Flexible?? We think so….
4. You then register the panes (i.e. any combination of North, South, East, West, Center) in a another config table and then set/map the corresponding region position. This is so we know what content to render where!
5. You then register all the individual Ext pane config in our pane config meta data table, and again you exclude the “items” parameter
6. Then for the APEX content you simply define it within the correct region position and set the region template to an Ext one we have defined (or leave it as an APEX one, your choice) and our integration code handles the rest. The great thing is that the content could be a grid, panel, form, tab panel, existing APEX region, interactive report etc.
7. Or for simplicity and development speed, you use one out of the gallery of pre-defined page templates we have already created!

Here’s a simple example from development environment as to how busy an APEX page can look (Click on it to see it in full size…). The brilliant thing is that our Tab Panel integration (see our old post) works really well within the customized viewport, and again you can control the tabpanel settings (e.g. tab position top/bottom etc.)….

And here’s a screenshot of the page definition…..

I have to say that we’ve just had a brain explosion from the above approach. It’s suddenly dawned on us that we can essentially write the framework so that we support almost (if not all) config settings Ext has defined in their API(s) i.e. for components we integrate (it would take quit a considerable amount of time to support the whole framework), and allow you the end user/developer the ability to manage every single one of these config settings. It will simply then become a config management task rather than a coding task when creating an Ext application in APEX.

What’s left to do on this piece is add the front end to manage the adding/modification of viewport meta data / Ext config….