We've worked with various developers in the past and have found it to be enormously beneficial. We've decided that instead of hiding away our code as some people choose to, we are very open about how it all works. If you think you'd like to get involved in some aspect, let us know. We would ask that you have a look at the way the code is formatted for things such as variable naming and layout before you do though. We want to maintain consistancy throughout and so the standards that we are what we want to work with. You would also be responsible for the initial testing of any modules and we would expect you to provide documentation for your work. It might sound like a lot but we have found that most developers have no problem with this approach, especially if they are using the product themselves.
Design Manual - This is a document that contains information about the architecture of the project and how to create plugins among other things. It opens in a new window with ots own navigation.
The project began as an effort to provide free software tools that could help support activities in the developing world, the main motivation coming from humanitarian rather than commercial interests. We already earn a living from other software jobs we do. One of our main development goals is to make a small suite of robust tools that do simple things well. The other main development goal is to produce software that people can adapt without being forced to rely on us. Our experience is that open-source software has the greatest appeal when the people who use it no longer have to depend on the people who made it. We want people who use this to make it their own.
Normally it is difficult to maintain a large, complex software application without a significant and continuous source of resources. However, there are aspects of our development philosophy that make it possible for us to manage this project:
Perhaps the most important aspect of our philosophy is that we assume projects or requrements may outgrow the software. Project35 has well defined development goals and we know when we would like to stop feature development. We want to rapidly stabilise the code base for two reasons. First, we want developers to feel confident that the software won’t change much during the duration of their own projects. Second, we want to support having the learning materials written in multiple languages.
Eventually, your needs may go beyond what the software supports. In these cases, you can either make your own version of it or reduce your dependence on it. To help you stop using the application, we have designed Project35 to support different levels of “buy-in”.
In Project35 the schema concepts correspond to records and fields you would see in an electronic form. You can use a c Configuration Tool to associate other properties with those form concepts. The tool can use both the schema and the configuration options you set to produce a functional specification of what the data entry tool should do. The specification is an HTML document that you can print out and give to people at meetings. Your groups can refer to the document when they are discussing what the prototype should support.
At the end of this prototyping phase, you can use the prototype and the functional specifications to guide the development of a custom built data entry application. If you like using Project35, you can continue to use it as a production line tool.
There is also one other important example that developers can use: the Configuration Tool. The forms for the Project35 Configuration Tool are generated from a schema that defines configuration options. The tool supports a number of plugins which you will use when you are building your prototype. If you want to know how those features work, you can inspect the code that is part of the main code base.
You can use Project35 as a standalone application or as a component that is launched from another application. You can also generate forms to suit the screens of either a desktop monitor or a PC Tablet screen.
You can also develop program for extracting information from the file. Each .PDZ file is actually a ZIP file that contains at least two small XML files – one that contains just the form data and another that contains other file information. You can open a .PDZ file with a tool such as WinZip and take the information you want.