create new tag
, view all tags
SvenDowideit didn't want me to create this topic, but I have to because my memory is very bad and I'll forget our conversation otherwise, and I need the topic for tracking anyway.

During the recent development on DevelopBranch I had been working towards turning Store.pm into an abstract base class, with alternative implementations of the ABC plugged in as required. Sven has argued (successfully) that we should instead employ Facade pattern in the Store.pm. This allows us to find a home for certain functionality that currently sits in other modules, is store implementation agnostic, but really should be a lot closer to the store - for example, TWiki::UI::Manage::rename. He argues - probably correctly - that this was JohnTalintyre's original design intent, but it got lost in the hacking.

CrawfordCurrie argues that it is key that the facade does not depend on any specific implementation detail, such as meta-data embedded in topics.

The proposal is to refactor the facade from the current codebase, by moving all filesystem specifics down into RcsFile and friends, and moving other store-specific implementations down into Store.

Open questions:

  1. What should move into the Facade?
    • TWiki::UI::Manage::rename is an obvious candidate
  2. Use of the User object should probably be pushed down below the Facade (into TWiki::Store::Rcs*) as specific impls will want to decorate with specific data e.g. ACLs. Currently Store maps to the wikiname.
  3. Should we aim for a more flexible store implementation selector now, or wait until Edinburgh? The advantages would be the ability to mix store impls. The disadvantage would be that it may force premature decisions about the web/topic/form data structures.

-- CrawfordCurrie - 25 Apr 2005

to add to the above "key that the facade does not depend on any specific implementation detail, such as meta-data embedded in topics.", there is some web releated meta data that is currently hard coded into StoreDotPm as file based, that breaks my Perl Hash implememtation of a dataStore too... This is obviously going to need to be pushed down to the implentation part of store.

I want to confirm before i go too far though - are we agreed that all data related to a particualr we will be in the same store backend? ie, if you create a web in a database, then attachments, topic meta data and web meta data will be in that database? - otherwise, there's a wole lot more abstraction we're going to have to build in..

Importantly - as we have just discussed on IRC, there are other things that are needed for Dakar, so I'm defering this work until EdinburghRelease - I will commit my changes into DevelopScratch as soon as I rattle up the docco on how to do it smile

-- SvenDowideit - 30 Apr 2005

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r3 - 2005-04-30 - SvenDowideit
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.