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: