Started a new job, so there has been no progress on RPHelper for a month. Have made progress on using controller classes. The ZipStore now has read and write caching. Have been looking at building in group working support by having a project be controlled by a Group object with a helping project meta-data object which can contain author info. Am also looking at adding a 'time modified' field to the base item as a prelude to version control (which would be needed for group working).
Starting to get a problem through doing too much processing in the graphical components. This came about because I'm still learning and experimenting, but now that the application feels like it's settling down I need to sort out the untidiness that's creeped in. The code has already separated the data parts from the graphical parts, but I'm now more strictly applying a design pattern known as Model View Controller. I'm also hoping to further simplify the field editing system, using controllers will help reduce the number of classes currently used.
On a side note, I finally took the time to learn a little CSS. If only I had made the time sooner! Both of these pages have now been converted as a learning experience.
Spent some time fixing little problems. Default item viewers now have the background of the item name part set to the colour of the base type. Each of the three base types have a Color associated to make them more distinguishable, so having the viewers use this colour will tie in nicely with the graphical navigation viewer (when it's done).
Added a new edit type: Color. I shall document the process when I add the Date edit type to help identify areas for improvement and to provide a guide for those wishing to expand the program.
The inter-viewer communications need optimising, and the store needs a read cache.
Can now create, view and edit all items. All items can have fields set using simple XML templates loaded from disc. Custom components are provided for most edit types, though these haven't been polished. Templates can be set on item creation and can be created manually. There is a universal field editing component, so fields are editable regardless of their inclusion in a template or their specifying an unknown edit type.
Bit of a donut award for this one... After deciding that all items would have the ability to use extra fields (by implementing in the root item, RPItem), I found a problem with some fields repeating. This problem was caused by sub classes of RPItem keeping their programmed extra fields (such as a quote body for Data) in the root XML element which meant they were picked up as fields by RPItem. My first attempt to solve this invloved requiring each class to declare which field names it reserved. Whilst battling through an implementation of this, I realised that any programmed extra fields can just be stored as normal extra fields: being mandatory just meant that the class had to make sure it was initialised and that it saved the values if they hadn't already been added. This simplified matters for creation and editing, and it works lovely too.
Have now started making the item FEC able to link to items. Currently have problem with the Data sourceid field which is set to point to itself.
Can now use an option dialog to set the read only/write enabled state of the store. Also can set the display format of some labels. The frames (windows) now appear where their parents are, will be making the application start in the middle of the screen as opposed to the top left corner at the moment. Added a StoreEvent system and most components now check for read/write status and to see if the item they are displaying has been removed.
Templates (holds TemplateFields) with accompanying TemplateFields (which define individual fields) and FieldEditingComponents (FECs) (provide edit types which the fields use to determine their editing behaviour) are now almost finished.
The default item viewer now uses the FECFactory class to get editing components for the fields it finds in any given item. Fields which don't have a specified edit type are covered by a universal edit type (currently a single line text editor).
The template system is working well so far. I've defined a couple of normal templates, a test one which includes all available edit types, and a default template for Data which covers it's programmed mandatory fields.
Can now generate xml file detailing available base types, edit types and templates.
Getting close to the old program size. Nothing to worry about yet as I've not made a conscious effort to optimise yet, and it's not yet time to do so. As the addage goes: Make it work. Then make it right. Only then make it fast :)
Decided that all RPItems can have extra fields, hence all can now have Templates applied. This was made in the belief that RPHelper would thus be able to handle a more flexible approach to meta data without recoding.
There is now a dialog to add items which offers a choice between the base types and any templates which can be applied to the chosen base type. Templates now know if they can be applied to a particular base type, though if not specified they default to being applied to any base type. The default item viewer now uses the default group viewer when viewing a group. Found odd problem where occasionally an array index out of bounds exception is thrown: a preliminary look made me notice quite a bit of room for optimisation and polish, but not wiser as to the cause. This isn't a major problem so will wait until all functionality is present. Also tidied up the test class and now the licence is viewable. Added simple store flush thread along with means to stop and start it.
Having problems with Templates. Templates determine which fields a data item should have. I originally thought that of the three basic data types (Source, Data and Group), only Source would require templates. Now I'm wondering if they should all be allowed to have templates as in particular I don't want to restrict the way rphelper can be used, and the templates seem like a good idea.
There's a singleton class which loads and makes available Templates which are loaded from a templates directory. The Source object can have a Template set to it either exclusively (only fields from that template are held) or additionally. The small Test class which allows creation of a new testing project and varying other things now has a little command prompt menu.
Can now remove items. The store defaults to read only, this state can be changed whilst running. The default item displays now allow 'holding' the view to the currently selected item.
The store reads and writes to a zip file. Rather than load all items into memory at once, they are only constructed when needed and are taken from the zip file. Items are saved individually in the zip with their id being used as their zip name. This allows use of the zip index to store the store index.
Currently there are simple implementations of a Group viewer, a general RPItem viewer and a navigation viewer. These are being used to test the application and gui ideas.
