|
|
楼主 |
发表于 2005-3-13 10:46:40
|
显示全部楼层
About
What is it?
phpDMCA is an set of functions that allows you to create and administrate the represent layer of modules (such as navigation, login, etc) and components (such as forum, blog, etc) of a PHP CMS. It provides a stable and flexible architecture with mere 2 layers. It is written in PHP (hence phpDMCA), a popular scripting language that is commonly used to dynamically create web pages. The DMCA part of phpDMCA stands for Dynamic Module and Component Administration.
Where can I cat it?
What do I need to run it?
phpDMCA requires a relational database to store the information about blocks and modules. It accesses this database via an abstract wrapper called ADODB or PEAR :: DB. This is compatible with databases such as PostgreSQL, MySQL and Oracle.
phpDMCA separates PHP from html thanks to Smarty template engine.
phpDMCA is written in the PHP scripting language. It requires PHP 4.2 and above.
Dynamic Blocks and Modules Administration is performed by a web interface, and therefore it is necessary to have a web server with PHP support, such as Apache.
Who is responsible for it?
Zhai Xiang legendren2008@yahoo.com.cn is the author and project manager, also did the documentation.
Introduction
Understanding about Dynamic Modules and Components Administration
The best way to explain modules and components administration accurately is to use real-life examples rather than trying to relate to cliché concepts.
When I was a small boy, a famous cartoon named ‘TRANSFORMERS’ (feel free to browse the official website http://www.hasbro.com/transformers/) attracted my sufficient attention. Buy a TRANSFORMERS toy was dream of children, especially, if he got a heroic COMBINER with INDIVIDUAL figure to form a super robot flight mode. Unfortunately, I did not have a combiner toy but mere an individual one without COMBINABILITY with other figures to form a big robot. When I saw neighbors played combiners named JETFIRE, IRONHIDE, etc from AUTOBOT or DECEPCON, I was full of jealousy.
Let’s assume from now on that INDIVIDUAL toy is an Object with such property: name, function, template, side, weight, and visible.
 The name of individual figure can be JAZZ, OPTIMUS PRIME, RODIMUS MAJOR, SILVERSTREAK, and ULTRA MAGNUS (the names of robots from AUTOBOT); CYCLONUS, THUNDERCRACKER, and GALVATRON (the names of robots from DECEPTICON).
 The function of individual figure can drive, fly, shoot, etc.
 The template of individual figure can be a sportscar, a semi-truck, a transport, a jet, a gun, etc.
 The side of individual figure can be left, center, or right and even center-left, center-center, or center-right.
 The weight of individual figure can be 1 to 10 for displaying individuals order by their weight.
 The visible of individual figure can be 0 (visible) or 1 (invisible) without middle ground.
If we mapped this statement into an individual matrix (blocks and modules matrix similarly) showing which one is visible, in which side and restricted order, it would look something like this:
blocks and modules matrix
Name Function Template Side Weight visible
JAZZ drive sportscar left 0 1
OPTIMUS PRIME drive semi-truck left 1 1
RODIMUS MAJOR drive sportscar left 1 0
SILVERSTREAK drive sportscar left 1 0
ULTRA MAGNUS drive transport left 2 1
CYCLONUS shoot gun right 0 1
THUNDERCRACKER fly jet right 1 1
GALVATRON shoot gun right 1 0
The columns list the property of each individual figure, and rows list the individual figure perform what function, what template, in which side, order by how weight, whether or not visible. Generally speaking, the “Name” is “block and module to be administrated”. We call it Block and Module Object (BMO). The “Function”, “Template”, “Side”, “Weight”, and “Visible” are “detailed administration of blocks and modules”. We call these Detailed Administration Objects (DAOs). The individual figure is administrated by function, template, side, weight, and visible, or in our terminology, BMO is administrated by DAOs.
Administrating blocks and modules using a blocks and modules matrix above has advantage and disadvantage.
Advantage:
 It’s very fine-grained. It’s possible to administrate individual figure if necessary.
 It’s easy to see which block and module is administrated by which function, template and other detailed administration. The answer is stored in the intersection of the block & module and detailed administration.
Disadvantage:
 It’s difficult to administrate on a large scale. 8 blocks & modules, and 5 categories of detailed administration information is fairly simple, but what if there were thousands of blocks & modules, and hundreds of categories of detailed administration, and you need to manage large group of them at once, but still retain enough fine-grained administration for an individual? That would mean a lot of fiddly and lengthy adjustment to the matrix, and it’s a difficult task to verify that the final matrix is correct.
 It’s hard to summarize or visualize. The above example is fairly simple to summarize in a few sentences (as how individual figures combine above), but what if the matrix looked like this?
Name Function Template Side Weight visible
JAZZ drive sportscar left 0 0
OPTIMUS PRIME drive semi-truck center-left 0 1
RODIMUS MAJOR drive sportscar center-right 0 0
SILVERSTREAK drive sportscar left 1 0
ULTRA MAGNUS drive transport center-center 0 1
CYCLONUS shoot gun right 0 1
THUNDERCRACKER fly jet center-right 1 1
GALVATRON shoot gun center-center 1 0
This matrix is not obvious to summarize, and it’s not clear to the reader why does administrating decision have been made in the left block (there is no block or module in the left side).
Defining dynamic modules and components administration with phpDMCA
It seems that for a large or complex situation, this ‘blocks and modules matrix’ approach is clearly unsuitable. We need a better system that maintains the advantages (fine-grain administration and a clear idea of which block and module is administrated by which function, template and other detailed administration) but removes the disadvantages (difficult to summarize, and difficult to administrate large groups of blocks and modules at once). One solution is phpDMCA, perhaps there are better ones.
phpDMCA doesn’t describe administration from the ‘bottom-up’ like the Blocks and Modules Matrix above. Instead, it describes it ‘top-down’, like the individual figures combined to a heroic COMBINER. This is a very flexible system that allows you to administrate blocks and modules in large groups, it neatly summarize the blocks and modules’ property, and it’s easy to see which block and module is administrated by which function, template and other detailed administration.
A BMO tree defines a hierarchy of Groups and BMOs (blocks and modules administrated by fine-grained administration). This is very similar to a tree view of folders and files. The ‘folder’ are the Groups and the ‘files’ are BMOs.
heroic COMBINER’s individual figures Group
├AUTOBOT Group
├
This is tree by itself mere specify the side of individual figures; it only shows how we’re grouping the individual figures which might be administrated by detailed administration (DAOs).
We apply blocks and modules administration by assigning instruction about a particular individual figure (BMO) to Groups or DAOs in the tree. JETFIRE, a heroic combiner, says:” By default, no-one should be visible in any block or module on the heroic COMBINER. But the AUTOBOT should be visible in every block or module. The DECEPTICON should only be visible in a restricted (administrated by JETFIRE) block or module.”
To interpret this BMO tree, we start from the top and work our way down.
Firstly, the default visible is always to be invisible. Permissions have been overridden for the “AUTOBOT”, so they can be visible to everywhere (“ALL” is a synonym for all blocks and modules: “sportscar, semi-truck, transport, jet, gun”). |
|
IP卡
狗仔卡
发表于 2005-3-12 20:00:24
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡