Introduction to PYXI Development
What is a PYXI application?
Welcome to the world of PYXI. PYXI gives you the power to develop solutions to yours or your clients’ business administration needs, without having to write any software code. You get the power to pick and choose from existing functionality already created by someone else, and to enhance that functionality or create something completely new. It all depends on the need you are fulfilling.
It is important to understand some basic terminology before we go much further.
Applications, Blueprints, Accounts, Users
PYXI is a software platform deployed over the internet. Neither you, nor your clients, ever need to install programs on a PC, or apps on their phones or other mobile devices. PYXI works directly in the browser on any device, whether fixed or mobile.
Each customer (an individual or, more usually, an organisation of some sort) using PYXI has their own Account. A PYXI Account is self-contained – the data in that Account is only accessible by Users of that Account. An Account is configured to provide the specific behaviour required by that customer. This configuration is most typically packaged up as an Application, which comprises one or more modules known as Blueprints.
An Account has one or more Users. The first User is always a System Administrator, with full powers to manage the Account, its billing and configuration, and with full visibility of all the data in the account. A System Administrator can add other Blueprints to expand the features of PYXI for their organisation. Additional Users are normally organised into Groups, which can be used to define who gets to see and do what across the application.
A PYXI Application is prepared by you. Once you have built and tested functionality on a test Account, you can deploy that configuration as a publically available Application. The Application has its own dedicated signup page to which you can point your existing or new customers using whatever marketing approach you like.
All customers that signup for your Application get their own Account with that Application applied to it. You get to choose how the customer pays for their usage of the Application – either we do the billing for you and pay you a commission, or you pay us for your customer’s usage and decide how you want to charge them.
Developing a PYXI Application
Most of the tools you need for Application development are available from the Control Panel, accessed from the link on the Home Page or always available from the System Menu at the top-right of the screen.
You develop your Application in a development Account dedicated to the purpose. This is separate from your main Account which you use to keep control of everything you are doing with PYXI. Create a new development Account using the Spawn Account option on the Control Panel. You can choose whether to include the configuration from this account or whether to create an ’empty’ account. Note that you would normally only copy configuration if you are working on modifications or enhancements to an existing configuration.
Your two main choices for actually setting up configuration are:
- Access all the main configuration records from the Control Panel and add/edit individual items using the User Interface. Tip – turn on the Dev Mode option in the System Menu – this will show extra links directly to the configuration record of Record Types, App Steps, Steps, Fields and views wherever they appear. Dev Mode is only available to Developer Users.
- Create, or modify an existing, Blueprint, then load it using the Load Blueprint option on the Control Panel.
You can, of course, mix and match these approaches as needed. You can also make good use of the Extract Blueprint option on the Control Panel. Use this to extract a Blueprint after you have added some of your configuration – it may then be quicker and easier to add to this Blueprint where you have more similar items, and re-load all or part of that Blueprint with your new additions. Note that you can almost always load up a Blueprint that already has existing records on it – these will be updated (if any fields have changed) rather than being duplicated, provided that the rules on Record Uniqueness are followed.
You should make a habit of extracting the Blueprint of your configuration anyway, and keeping it safe to ensure that it is always available if you spawn a new account to continue development at a later date, and ultimately for publishing it to the outside world as your own PYXI Application (Final details to be added)
As you build up your application, you should regularly check for any configuration issues using the Detect Configuration Issues option on the Control Panel. This will check for issues that might not be trapped when configuration records are first set-up, either on-screen or through Blueprint load. Generally, PYXI is fairly permissive about what can be entered or particularly loaded by Blueprint, otherwise it would be very challenging to ensure that all items are loaded in the correct order with their dependencies loaded prior. But once configuration is entered, the Issue Detector can do a more robust job of checking for issues such as calculation or script syntax errors, references to non-existent Record Types or records etc.
You must resolve any issues identified before you let loose your configuration on a client’s account or expect to publish it as a PYXI application.
You should read Interpreting Business Needs, which introduces most of the main concepts of PYXI Application setup by looking at things from the point of view of the Business Requirement being met. You are advised to read the whole of that page before you start delving deeper into other topics.
After reading this, you can dive in and start experimenting – the Beginning Development page will guide you through the basics. Or you could install one of the Available Add-Ons listed on the Account page in the System Menu, then take a look at the configuration records that it has created. This is a great way to learn by example – you can even extract a Blueprint and see the whole configuration in one place, but you should probably leave this until after you’ve had a first look through the records on-screen so it doesn’t look too daunting!
You should also take a reasonably early look at the Branding guide. This looks at how to provide a consistent look to your configuration using Colour and Icons. It does delve into slightly more detail and provides some worked examples, so it assumes some basic knowledge already. You would probably benefit from some initial experimentation guided by Beginning Development before looking at Branding in more depth.