Jan 05

New Year, New Designs!

By mnolan APEX Templates, ExtJS Integration, Widgets No Comments »

I’ve been busy upgrading to Ext 3.1, and with that have come a number of welcomed design changes in our framework. Previously we were dynamically building a viewport and using renderTo and applyTo to create most of the widgets within, which is a bit of problem with layouts, so we’ve gone back to the drawing board and have re-engineered the viewport design.

Essentially now we build the entire viewport and components in a single function call, which when you think of it is a bit of a nightmare when you have 20-30 components on a page, so we’ve cut the amount of code/config down by calling our custom javascript functions and reusing some meta objects defined in the header, we’ve simply replaced “widget.render” with “return widget” in our js functions, meaning we haven’t had to recode much at all, as Ext supports the defining of “items” as Mixed, meaning it could be config or an instantiated object.

The benefit we now get from this is that all the widgets are managed by a Layout Manager and are dynamically resized when the size/display of the layout changes. This is the big difference between jQuery and Ext (@ the APEX community) when you see the beauty of your widgets being resized based on the change of the screen size, collapse of regions/panels etc, you’ll understand why Ext is a much better way to go than jQuery widgets, which are mostly working independently of each other.

At the moment we are supporting the grouping of regions/widgets into “Panes”, “Tab Panels”, “Accordions”, & “Panels”. However this is only at one level, i.e. we can’t support a “Tab Panel” inside an “Accordion”, however we’re working on a design change that will work recursively, so you will be able to do this infinitely by using something like a simple dot notation for the REGION_STATIC_ID e.g. tabpanel1.accordion2.panel1 which I’ll try and translate into:

  • rendering a region/widget within the first panel that is within the second accordion slot within the first tab within the pane. (We use the REGION_POSITION to define what pane the region/widget belongs to)

It all sounds well in theory but I’ll have to run some tests to see how deep we can go with the nesting of widgets. The other new functionality that has been introduced is allowing custom config to be defined for all layouts and widgets in APEX development runtime mode. We simply use a Property Grid to achieve this. We’ve separated the config between widget config and layout config for group level widgets, here’s a screenshot to give you an idea.

APExt JS - Widget Customization

The other new bit of functionality that w’ve introduced is Accordions, it’s basically the exact same design as our Tab Panel code, so it’s been really quick to implement and use. You simply set ACCORDION[Sequence No] in your REGION_STATIC_ID. Here’s a few screenshots from our dev environment.

APExt JS - Accordion

An here’s what the page looks like in the IDE

APExt JS - Behind the Scenes

The next big area of focus is back on the Editable Grid and using the row editor!

Tagged with: • •
Sep 18

APExt JS – Customized Viewport/Layout – In Progress

By mnolan ExtJS Integration, Widgets No Comments »

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.)….

APExt JS - Customizable Viewport

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

APExt JS - Customizable Viewport APEX IDE

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….

Tagged with: • • • •
preload preload preload