Wednesday 24 February 2016

Stadium 4 custom screens

Stadium and Linx sometimes don’t have all the features you need to fulfill a client’s needs. It doesn’t always make sense adding those features to Stadium for once-off use, either.

In that case, we have to make custom screens to use in Stadium’s URLViewer.

For example, it wasn’t feasible to create powerful enough DataGrids in Stadium for one of the Nedbank implementations, so a portion of the Pricing project was built in custom screens. For Old Mutual Zimbabwe, we built a CSV importer that enriches transaction data already in Stadium.

The drawback of creating custom screens is the amount of time it takes to create them. We are essentially starting a project from scratch, and integrating it with an existing client project that is not part of our environment. Development can take a lot longer than adding functionality to an existing project, and comparatively even longer than creating ordinary Stadium 4 screens. This needs to be weighed up when choosing whether to go look at finding a different way to build something in Stadium 4, or making a custom screen for it.

So how do we create custom Stadium 4 screens?

Creating a custom screen (or group of screens) is essentially like starting a project from scratch. It’s a free-standing project, and Stadium’s URLViewer control is used to access it.

The following must be done to create a custom screen:
  • We make a number of design decisions, as if building a project from the beginning - including solution architecture, programming language, testing framework, and programming frameworks.
  • We need to integrate with your database. This is the trickiest part of the process – the central need of the software is usually to interact with a database, and that is stored in the client’s environment. If a decent database backup is provided, we work against that one, but there still needs to be coordination of changes between the development database and the actual database at the client.
  • We need to integrate with your Stadium solution. This often means negotiating the correct parameters to pass between Stadium and the custom screen. This is a fair amount of work for the implementation team at the client too.
  • Actual development is slightly more complicated than normal development, since we are integrating with an existing system the development team does not have comprehensive access to. There is no drag-and-drop functionality, and no actual environment to play around with. A dummy/mock environment needs to be created from scratch.
  • An implementation manual needs to be written – deployment of custom screens can sometimes be a tricky process, especially when database integration is involved.
  • Testing happens (and needs to happen) as a feedback cycle from the implementation team. Due to differing environments and misunderstandings that may arise from the spec, this is unlikely to be correct the first time.
  • This feedback cycle continues until the implementation team is satisfied with the solution provided.

Integration of Stadium 4 custom screens

Stadium 4 custom screens form part of your existing Stadium application it was built for.
  • The DLL goes in the Stadium web directory’s bin folder
  • A URLViewer is added to the Stadium 4 application. The URLViewer points to the initial custom screen that the user needs to navigate to.
  • The web pages (.aspx files) can theoretically go anywhere inside the Stadium web directory, as long as the URLViewer points to them.
Some custom integration needs to occur. This differs from project to project. For instance, some custom screens need to link back to specific Stadium pages. Some need to access more than one database. This integration can be tricky, and is often changed as the screens are being developed and more communication has happened between the development team and the implementation team.

More information: Our development process:

Wednesday 10 February 2016

Stadium 5.2.1484.3745 is available

If you already have Stadium 5 installed, the designer should prompt you to install it the next time you open it. Otherwise head over to the Stadium website and download it now!
  • ODBC Connections to databases like MySQL, DB2 and PosgreSQL are now supported
    • You'll need to set up a User DSN for connecting in the Designer and a Service DSN for connecting via the server
    • Only text queries are supported at this stage
    • Parameters are specified using a ? and display as Parameter1, Parameter2 etc in the Designer (eg select * from Products where ProductId = ?)
  • Cut Copy Paste has been reintroduced. It works on Pages, Scripts, Controls and Actions
    • When copying individual controls/actions across pages/scripts, page/script specific mappings will be lost
  • Validation messages in the designer for unmapped properties and events
    • Double click on the validation to bring the control into focus.
    • Once the property has been mapped, the validation disappears
  • Upgrade to .net Framework 4.6
    • the installer will download and install it if needed
  • Upgrade to IIS 10 Express
    •  the installer will download and install it if needed to run Generated Apps (no IIS on the PC)
  • Create a default Stadium5 App Pool and run all uploaded applications through it
  • Required Field Validator added to Checkbox List
  • Redesign of the Query Editor - see your parameters and fields on one screen
  • Rename query parameters - useful for ODBC queries where all parameters are written as ‘?’ in the query and display as Parameter1, Parameter2 etc in the Designer
  • Manually pull query fields and parameters
    •  they are no longer automatically refreshed
  • Connections - Only persist if a server or dsn is specified
  • Queries - only persist if SQL has been specified
  • Toolbox Controls listed in one section
  • Right-click context menu on open tabs with options to close all, float and dock tabs, close current tab and close all but this
  • Visible And Read-Only properties on Checkbox, Checkbox List, Date Picker, Drop Down, Panel, Radio Button List and TextBox can now be set using Query Fields, Page Parameters and Constants as well as a static True/False value
  • Better handling of Images
  • Fix security permissions errors when the Designer is not run as an Administrator
  • Security Certificate Updated

Thanks to Anton, Amol, Darshit, Greg and Shaun for all the dev work