Author: jmorliaguet Date: Sun Jun 18 00:03:22 2006 New Revision: 3444 Added: cpsskins/branches/paris-sprint-2006/doc/locations.txt (contents, props changed)
Log: - added some initial ideas about locations and how to recreate local site information Added: cpsskins/branches/paris-sprint-2006/doc/locations.txt ============================================================================== --- (empty file) +++ cpsskins/branches/paris-sprint-2006/doc/locations.txt Sun Jun 18 00:03:22 2006 @@ -0,0 +1,104 @@ + +$Id$ + +========= +LOCATIONS +========= + +Locations are used to store local site data in a central place. + +Background +---------- + +By design, themes are stored entirely in a Theme Management Folder. + +This has the following advantages: + +- the application can run on virtually all zope-based platforms since the + contact surface against the underlying application is limited to a single + folder. + +- themes can be designed and tested before the actual site exists. + +- theme-related security policy is kept entirely separate from the + application's own security policy. + +- high performance since the data is directly available (no traversals, or + complex catalog queries are necessary) + +- the import and export of data is very straightforward (see cpsskins.setup.io) + + +The downsides are: + +- all "local" information must also be stored in a central location. + +- all locations used by the underlying application must be identifiable, and + modifications must be monitored. + + +Implementation +-------------- + +We have to maintain a mapping between locations and some data. + +We assume that objects are locatable, i.e. by knowing the object we can know its +location reliably. + +Containment +........... + +Given a location we can find the set of locations that are contained in it and +another set of locations that it contains. + +Locations contained in a given location are called 'sublocations'. + +Since we can't keep information about *all* the locations of a site we +must store some information about how locations and related to sublocations + +Rules of inheritence +.................... + +The "standard" behaviour for locations is to follow some sort of inheritence, +i.e. what is true of a given location is also true of its sublocations. + +This behaviour can be declined into rules: + +- what is true of a location applies only to the location itself + +- what is true of a location applies only to its sublocations + +- what is true of a location applies only to the parent location + +- ... + +In order to avoid conflicting statements we must assume that some rules +have precedence over others. To determine the order in which rules are to be +applied in a given context we look for the nearest locations first. + +Nearest location in a context +............................. + +All location information will be looked up from a given context which can +considered as the sublocation of a nearest location. + +For instance in the context of folder1/folder2/folder3, among the following +locations: + + - folder1 + + - folder1/folder2 + +the former is the nearest location, because the context is contained in it and +because it is contained in all other locations. + +We can sort locations as: + + folder1 > folder1/folder2 > folder1/folder2/folder3 + + (with '>' meaning 'contains') + +If no nearest locations can be found in a given context then no rules will be +applied, and the context will contain no local information. + + -- http://lists.nuxeo.com/mailman/listinfo/z3lab-checkins
