summaryrefslogtreecommitdiff
path: root/libopie/pim/DESIGN
Side-by-side diff
Diffstat (limited to 'libopie/pim/DESIGN') (more/less context) (ignore whitespace changes)
-rw-r--r--libopie/pim/DESIGN50
1 files changed, 50 insertions, 0 deletions
diff --git a/libopie/pim/DESIGN b/libopie/pim/DESIGN
new file mode 100644
index 0000000..d878f45
--- a/dev/null
+++ b/libopie/pim/DESIGN
@@ -0,0 +1,50 @@
+Hija to the DESIGN of our OPIE PIM stuff
+
+This design was firstly discussed in the train
+from Frankfurt to Hannover between me (zecke ) and eilers.
+
+We had a look at our pim implementation and the one from
+trolltech and we looked what was missing.
+
+GOALS:
+ - clean implementation
+ - share code
+ - ObjectOriented Design
+ - Scalable
+ - Integration into common solutions like STL and Qt
+ - Addition
+ - Ease of Use
+
+GENERAL:
+ - use templates
+ - have a common base class for all Records OPimRecord
+ - use references instead of pointers
+ - make use of QShared internally memory consumption
+
+We've a 'public' and 'private' part in our lib
+OPimAccessTemplate is the public part. This will be used
+by 3rd party developers to access the PIMs.
+OPimAccessBackend is the backend. You could also call it
+resource.
+
+Both things need to be implemented for different kind of records.
+By using templates we can make sure we share code and the reason
+not to use simple inheretance is that we can specialise quite easy.
+
+For example we have OTodoAccess : public OPimAccessTemplate<OTodo>;
+the we would do
+OTodoAccess::List list = otodoAccess.all();
+OTodoAccess::List::Iterator it;
+for( it = list.begin(); it != list.end(); ++it );
+
+
+as you can see from here it just behaves like you expect from Qt or STL.
+
+The kewlest thing is that List and List::Iterator is free to use if you
+want to implement your own OPimAccessTemplate.
+You just have to sub class it and voila you're done
+
+
+Hope you enjoy using OPIE PIM
+
+regards Holger 'zecke' Freyther \ No newline at end of file