Wouldn't be a good idea to have abstract Page, PageEditor and User classes instead? Then in wikiconfig.py assign an instance of the desired subclass to the config? Or, less elegantly, assign a default FlatFilePageEdit instance in multiconfig.py if its missing from wikiconfig.py? As far as I can see, this doesn't really relate to MoinDev/PluginConcept, but I'm all ears if MoinDev/PluginConcept could be applied somehow. Any more elegant way /pointers on how to do this in python/MoinMoin? With a factory design pattern?
We need to collect the functions we will need in this storage class. What needs to go there and what is layered ontop of those base storage functions? Example: is diff base or above? On one side, diff is diff(store.fetch(v1), store.fetch(v2)), on the other hand a storage class like SvnStore could provide the diff on its own in a more efficient way... -- OliverGraf 2004-08-04 15:34:48
I would not do diffs in the storage class, because what svn gives as "diff" might be different from what cvs, tla, whatever, ... gives you as diff. So the easiest way of having some definite diff syntax/content is getting the content and doing the diff ourself. -- ThomasWaldmann 2004-08-09 09:53:56
I think the base class should have a diff method that fetches two objects and returns a diff, which is then marked up by the higher level methods; if any SVN storage class would like to provide the diff in a faster way it would be free to override the diff method. -- JohannesBerg 2004-10-06 13:44:41
I think it would be good to move all page related core functions (those which are now in different parts of moin) into the Page class, so they can be overloaded by a alternate storage class (MySqlPage, SvnPage, BundlePage, ...). One BasePage with just virtual methods (or perhaps flatfile is this base class?). And to get Users working the same way, the User needs to become a special page (like a DictPage or a AclGroup), so storage of User and Page data becomes the same. -- OliverGraf 2004-08-04 15:27:46
Addition: even stuff like AttachFile needs a Page method for storage (storeDataChunk). So we need basically stuff like: storePageText, storePageMetaData, storePageDataChunk (names are open for discussion). Essentially: everything that needs to store or access stuff connected to the meta-object called Page needs to go through some Page method.
There's been talk of using an abstract BasePage or something for storage refactoring, I think this should instead be done by aggregation. Another class (hierarchy) would provide the storage stuff, the Page would have methods that call its internal aggregated storage object. -- JohannesBerg 2004-10-06 15:52:50
It might be easier to move the storage handling into a seperate class. We already have Page -> PageEditor -> PageGraphicalEditor. To generate multiple storage backends we need to overload all three. Make all three using a given storage class will be much easier. Especially is we want to create even more Page subclasses for other mime types -- FlorianFesti
I recommend that the main body of the wiki does not have direct access to the objects in the abstraction layer. An example of this would be: se.page("WikiName")
The reason for this is that it makes the code dependant on the structure of the abstraction layer, causing problems in the future should it need to be altered - much like it is current. I firmly believe that the most suitable appoach to this is to create a proxy class for the storage engine that acts as a delegator to the storge engine. That way storage engine changes only need the proxy to be modified. Here are a collection of methods that I believe are needed. -- A 2024-04-28 15:50:43
se.get_page_data("Wikiname", index)
se.get_page_metadata("Wikiname", metaField)