ELE Vision for Creating the P.V.Player
This is a menu of the topics on this page (click on any):
the Data Store
the Renderer .
Your pvPlayer project has to be split into several parts (which could become objects or sets of objects, each):
the Data Store
You need a data store to:
- - store your arrays (pvM property in M1M data structure)
- - store the arrays properties (all other properties in M1M data structure)
- - store M3Ms which are collections of M1M data structures
- - etc.
Knowing the hierarchical and non rectangular structure of several of these elements, it seems that APL+Win component files are the ideal data store receptacles which should be used to record all these data.
(its probably already the case in most cases for you)
You need an Editor to be able to:
- - display your pvM arrays, taking in account the various properties defined in their M1M data structure
- - edit/update the pvM data if necessary
- - edit/change the various properties defined in the M1M data structure
Unlike John Gregg, and more like you, I believe that this part is not only not trivial, but probably quite difficult to tackle well. But I have ideas.
I can see several approaches for writing this Editor:
- a. either, use a grid like the APL+Win grid to display the data and edit them, and design a complete set of Windows forms to allow defining/updating the various M1M properties
- b. or, use the best tabular Editor ever written, i.e. Excel to display the data, edit them and indeed simply make the array look like it should look
I think the b. case is interesting: here is how I think it could work:
- A. user tells he want to display/edit an M1M
- B. M1M is fetched from the data store
- C. an object pertaining to the set of objects attached to the Editor, would (1) display the pvM array and (2) use the various properties defined in the M1M to automatically format it, according to these properties
(I think I can write such an object)
- D. user edits the pvM data if necessary and more importantly, make formatting changes, like grouping headings, or grouping rows and adding subtotals to each section, etc. All this is easy to do in Excel: it is basic Excel formatting tasks in a worksheet
- E. user requests to save his changes
- F. another object pertaining to the set of objects attached to the Editor, would read the Excel sheet content, analyze it and convert the changes (whether made to the actual data or to the formatting) into properties values to be stored in the M1M data structure (this is a bit tricky, but again I think I can write such an object, because I have some ideas on how to do it)
So, if I had to write the Editor, I would select the b. approach.
Of course that would mean documenting precisely the various formatting actions allowed to be done by the user in an Excel worksheet and how they relate to each particular M1M property.
You need a Renderer to convert your M3M or M1M data structures into various types of nice looking reports (HTML, PDF, Excel, etc.)
Again I see this as a set of specialized objects which would each be able to render an M1M data structure into one of the desired formats. A detailed analysis of this problem needs to be done, but here are a few remarks:
- - it would be good to see if the Renderer could first blindly produce the report in the format in which it is the easiest to produce the report (Excel?)
- - then, the specialized objects would convert this report into the requested format (HTML, PDF, →)
There are very good conversion software out there which know how to convert a file format into another file format. Our job would be to select the best converter program in each category.
Here are a number of additional remarks:
to achieve such an ambitious project successfully, an extreme rigor must be adopted at each stage (analysis, development, documentation)
if you were to ask me to help you achieve this project, I would like to use the simple to more and more complex approach
This means, I would like to concentrate on M1M data structures only at first and within M1Ms, select only a few properties (maybe pvTXT, pvM, pvRT and pvCT) and build the Data Store, the Editor and the Renderer objects necessary to correctly handle these properties (or maybe we could decide the Renderer is really a separate project that can be done a little later). Anyway, I would like these objects to be perfect, i.e. that you do not let me start working on implementing other properties until you consider the work on the first properties and the accompanying documentation to be really perfectly done. Then we can add one more M1M property, and test it until it is considered perfect. Etc.
I am used to work on very complex projects like this one and I have learnt over years and years that this is an approach which leads to success.
as is recommended in all modern development systems, there should be a total independency of the various project modules (the Data Store, the Editor and the Renderer)
the latter point implies that the M1M data structure be revisited (this does not necessarily mean it should be changed, but maybe) because:
- it contains properties which are pure data (pvTXT, pvM, pvRT, pvCT, pvTTL3, etc.)
- it contains properties which are related to M3M only (pvDTS, pvVCOM, etc.)
- it contains properties which are pure formatting ones (pvFMV)
- it contains properties which concerns only the Renderer maybe (the print page headers, footers, etc.)
I have plenty of ideas that could allow to both reduce the number of properties to handle and make it much simpler to implement them.
The above is the result of my thinking made about your pvPlayer project during the weekend.
What do you think?
Do my ideas seem sound to you?
In order to give you a cost estimate for analysis and development of a first stage of pvPlayer, I would need that we precisely decide what this first stage should include, knowing that I would like to use the simple to more and more complex approach described above.
It would also help me if you could send me one of your existing APL file containing one or more M1M data structure.