ExtJs source control package strategy for a utility library

So, after (re)reading the sencha docs and forums a couple of times I have come up with an alternate strategy for maintaining a utility library as a package... Not sure if it will not change at some point but so far it seems to be ok-ish...

Anyway, the requirements were:

  • it should be possible to share the lib between apps / projects (obviously)
  • the lib should have its own source control storage without having to use workspaces and such
  • in should be possible to pack it and deliver as a package in the future (not sure it it will ever be the case though ;)
  • It should be ready for the ExtJs 6 universal app usage
So what i did was:
  • I created a package within one of my apps and moved it to a separate repo
  • I created 3 subfolders under the src folder: core, classic, and modern; they will hold the core code as well as the ui for both modes
  • in the app's packages folder I created a Junction to the new source controlled package folder
  • in the app.json I added my app in the requires array - at this stage it is ok to reference the classes through the PackageName (in my case gm) namespace

So far it looks like the package buids-in nicely into the consumer app and at the same time it is independently source controlled which were my primary concerns.
There are some problems building the package itself as it is not a part of an app or a workspace. I guess it can be simply copied over to a temp app and then built as required. Not too fancy indeed, though at this stage I have no drive to investigate it further.

[Edit]
  1. As of ExtJs 6, i leaned towards using universal apps. therefore the code organisation changes a bit and the code goes to src, modern and classic folders respectively
  2. When requiring a package class in the generic code (not toolkit specific) then there must be package equivalents for a required class for both toolkits - otherewise building will fail for the code not implemented for a particular toolkit
  3. And finally, made the package build as expected - instead of simply drilling down to the packages/local/packageName and running sencha package build (that throws errors related to missing Ext classes), the command should include the sdk param, so the cmd knows where ExtJs stuff actually is (obviously not in the default location in my case ;) 

Jasmine test runner for ExtJs

I have been thinking for a while on plugging Jasmine into ExtJs apps in an easy way. So here it goes an ExtJs TestRunner for Jasmine. This is more a PoC than a completed module, but so far it proved itself to be working as expected.

It can replace the app's viewport:

or work side by side:

The usage is rather simple:

//get the query params, so can dynamically adjust where the tests will be executed
//this may be handy if the tests need ui for example
var query = Ext.Object.fromQueryString(window.location.search),
    testRunnerCfg,
    tests = [
        'Jasmine.test.Simple',
        'Jasmine.test.Async'
    ];

//check if should handle the normal startup or kick in with the tests mode
if(Jasmine.util.TestRunner.isInTestMode()){

    //by default the test runner creates its own viewport that is displayed instead of the app
    //it is possible to customise this and display the jasmine output on the side or actually in any container

    //the default will run test runner with the standard output generated instead of the app
    testRunnerCfg = {
        tests: tests
    };

    //display tests on the side
    if(query.hasOwnProperty('testsonside') && query['testsonside']){
        this.viewport = Ext.create('Ext.container.Viewport', {
            layout: 'border',
            items: [
                {
                    xtype: 'panel',
                    region: 'center',
                    layout: 'fit',
                    items: [
                        Ext.create('Jasmine.view.main.Main')
                    ]
                },
                {
                    xtype: 'panel',
                    region: 'south',
                    height: 300,
                    html: '
', overflowY: true, split: true, title: 'Jasmine output' } ] }); testRunnerCfg.outputContainer = 'jasmine_output'; } Ext.create('Jasmine.util.TestRunner', testRunnerCfg); } else { //normal app startup //create the app's viewport this.viewport = Ext.create('Ext.container.Viewport', { layout: 'fit', items: [ Ext.create('Jasmine.view.main.Main') ] }); }

for details see the example app on github

Corel X7 .NET AddOn

Shelbym wrote some nice guides on how to create custom .NET dockers for CorelDRAW x6. There where some changes in X7 described here.

This post is pretty much about putting the above together, so one can quickly start playing with custom tools in X7.

The content of the attached archive is as follows:

  • TestAddOn - a ready to go X7 addon; just coy it to the CorelDRAW Graphics Suite X7\Programs64\Addons and review the Window\Dockers
  • TestAddOnSolution - an extremely simplistic project to give an idea on how to start with the addon customisation
  • TestAddonTemplate - UserUI and AppUI xslts that make orel create Window\Dockers entry and load the custom dll

AddonBase.zip (64.5KB)

OpenLayers.Layer.Panoramio

While working on one of our recent projects we came with an idea (or I should rather say - we eventually managed to spare some time on something not strictly project related ;) that giving some more context to a map should improve the perception of the map data itself:

More...

ExtJs 4 - avoid adding duplicate records

This is quick tip on how to avoid adding duplicate records to data store in ExtJs 4.

In my example I have Ext.grid.Panel which dynamically creates store for itself in constructor method from provided list of fields:

 More...