Menu
▾
▴
phpwebsite-developers
|
From: W.D.Sumilang <wa...@on...> - 2001-04-09 18:06:15
|
Well, umm... Brian, is there a proposed roadmap on the way soon or are there some specific topics that must still be discussed? I think we're all waiting for some feedback. Cheers to all. Its been quite silent on the App' State side, roadmap wise ;) BTW, anyone using/testing xml-rpc from ezPublish or Usefulinc.com http://developer.ez.no/article/static/53 http://xmlrpc.usefulinc.com/ please comment. __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com |
|
From: Brian W. B. <br...@ap...> - 2001-04-09 18:38:25
|
> Well, umm... Brian, is there a proposed roadmap on the way soon or are > there some specific topics that must still be discussed? I think we're > all waiting for some feedback. > Cheers to all. Its been quite silent on the App' State side, roadmap > wise ;) Working on it at this moment. Last week was a very busy week for both myself and Matt McNaney or it would have been out last week. At the present time, I think additional discussion would not be beneficial to the Road Map (got to draw the line somewhere). We appreciate everyone's patience, please know that your discussions and ideas have made a huge impact on our decisions and I feel that phpWebSite will be much better for it in the end. Look for the Road Map very soon! (We promise). Kind Regards, Brian Brian W. Brown Internet Systems Architect, ESS Student Development Room 269, John Thomas Hall Appalachian State University Boone, NC 28608 vox: 828-262-7124 fax: 828-262-2585 |
|
From: clayton c. <cc...@ca...> - 2001-04-09 22:02:28
|
> At the present time, I think additional discussion would not be beneficial > to the Road Map (got to draw the line somewhere). Dang... too bad. i had an architectural suggestion ive been meaning to suggest for the past week and a half (basically a flexible way to attach any item in the database to any other - eg. attach a photo album to a comment, attach a comment to file, attach a file to a comment, add an addressbook to calendar event, etc. all this without having to update the data model everytime we add a new module) ACS uses this to great effect. i guess it can wait. in any case im anxiously awaiting the new Roadmap... We appreciate everyone's > patience, please know that your discussions and ideas have made a huge > impact on our decisions and I feel that phpWebSite will be much better for > it in the end. > |
|
From: Brian W. B. <br...@ap...> - 2001-04-09 22:23:14
|
> Dang... too bad. i had an architectural suggestion ive been meaning to > suggest for the past week and a half (basically a flexible way to > attach any item in the database to any other - eg. attach a photo album > to a comment, attach a comment to file, attach a file to a comment, add > an addressbook to calendar event, etc. all this without having to > update the data model everytime we add a new module) ACS uses this to > great effect. Please do share your suggestion. The Road Map is *not* an architectural model for the re-write. It will include information about what will happen to the existing version, what modules will compose the new version (polls and web links are being pulled and turned into plug-ins), how we will approach certain issues (e.g. DB abstraction, templates, etc.), as well as adopted coding standards, etc. The "inter-module" communication you describe is yet another road map item - but as a specification rather than a proposed design. One of the Road Map items is the development of the architecture of the new re-write, so you comments in that regard are most appropriate. I apologize if this was not clear. Discussion regarding architecture should certainly proceed (although the road map should help to guide this discussion). -- Brian W. Brown Internet Systems Architect, ESS Student Development Room 269, John Thomas Hall Appalachian State University Boone, NC 28608 vox: 828-262-7124 fax: 828-262-2585 |
|
From: clayton c. <cc...@ca...> - 2001-04-10 16:07:33
|
One of the greatest benefits of modular code is incremental utility, i.e. i
can add what i need, when i need it, with minimum impact to the base system.
An issue this raises is how newer features integrate into the base in a way
that other parts of the system can benefit from the new functionality.
Suppose, for example, we're running a site that allows users to create
communities. We currently have a calendar module, but later we decide to add
an address book and photoalbum. How do we associate the community user group
with these modules ? The way most people do it, unfortunately, is to modify
the schema of the group and insert foreign keys pointing to the tables
containing the data for the given modules. In my opinion phpWS should be
designed in a way that no end-user (site-operator) should ever have to
manipulate the schema (if they want to is another matter).
ACS (ArsDigita Community System) deals with this issue is through
scoping. Every module which needs to be able to associate itself with
another entity in the system does the following :
1) decide on the level of granularity of association. For instance with a
photo-album, do we want to associate an album with a user group, or single
photos.
2) based on 1, we modify the table representing the entity (album or photo)
being associated to contain the following additional fields :
scope varchar(12) -- [1] can be "user", "group",
"table", "system"
user_id int -- id of user if scope == "user"
group_id int -- id of group if scope == "group"
table varchar(64) -- table name, if scope is "table"
3) every time updates are made, we simply fill in these fields in a manner
appropriate to the scope. So for instance, to add a photoalbum to user #10's
account :
insert into pws_albums(scope,user_id,attr1,attr2) values
('user',10,$value1,$value2)
4) the module table will contain the following extra fields :
is_scoped char - "t" or "f"
item_type_name varchar(200) e.g. Photo Album
type_name_plural varchar(200) e.g. Photo Albums
item_table_name varchar(64) -- table containing the
entity e.g. pws_albums
item_id_field varchar(64) -- name of PK
field
what this allows us to do is to traverse all scoped modules to answer
questions like "what modules can be associated with a user/group etc. "
the last 4 fields are for easy UI and automatic query generation. For
instance consider the following
/* get ids of all groups who use a module */
function getModuleGroups($moduleId) {
$sql = "select * from pws_modules where moduleId=$moduleId";
$result = db_query($sql);
$row = db_fetcharray($result);
db_free_result($result);
$table = $row['item_table_name'];
$field = $row['item_id_field'];
$sql = "select $table.group_id, pws_groups.name from $table, pws_groups
where $table.scope='group' " .
" and pws_groups.group_id = $table.group_id";
$result = db_query($result);
$list = array();
while ($row = db_fetcharray($result)) {
$list[] = $row;
}
db_free_result($result);
return $list;
}
/* get all modules related to a user */
function getUserModule($userId) {
$sql = "select * from pws_modules where is_scoped="t";
$result = db_query($sql);
$list = array();
while ($row = db_fetcharray($result)) {
$item_type = $row['item_name_plural'];
$id_field = $row['item_id_field'];
$table = $row['item_table_name'];
$sql = "select $id_field from $table where $table.scope='user' and
$table.user_id=$userId";
$result1 = db_query($sql);
$sublist = array()
while ($row = db_fetcharray($result1) {
$sublist[] = $row['$id_field'];
}
db_free_result($result1);
$list[] = array($item_type => $sublist)
};
db_free_result($result);
return $list;
}
As you can see, once implemented, there is no need to mess with the schema
as modules are added. And the module metadata makes it possible to have
generic routines for UIs and queries. i also have ideas on metadata
improvement to make this slightly better.
In addition ive semi-translated a file containing routines to support
scoping in PHP scripts (reading the needed variables from GETs and POSTs,
generating hidden vars and urls, etc). if you'd like id ask Todd to post it
to his site.
questions, comments, criticisms ? fire away ...
|
|
From: Todd O. <to...@da...> - 2001-04-10 19:53:41
|
In addition to completing my taxes (my wife doesn't believe in extensions), I've been reviewing the complete source code of many community sites (php unless otherwise noted), such as phpNuke, myphpnuke, mmbase (java), typo3, phpcms (german docs), opencms (java), phpreactor, ezpublish, Ars Digital (tcl), phpgroupware, netautor, and zope (python) and a few others. Here are my findings: If mmbase were written in php, then I would pick that one to start with (it's over 200,000 lines of java). mmbase has by far the most thought out object architecture of the group. Their "relation node" concept should be our model of inter-object relationships. Instead of scoping (as defined in ACS), where a group or user relates to an object, the relation node connects arbitrary object types. See http://www.datadx.com/phpwebsite/mmbase_thesis.pdf for a good explanation beginning on page 24 (or beginning of chapter 3). We should use the mmbase permission model or the ACS model (as modified by Clayton). This allows a more abstracted access control scheme. OpenCMS is a great package, but it's almost a java version of Zope, which I like better. The problem is the fundamental code changes that would have to be done to Zope or OpenCMS to convert from a tree (top-down hierarchical relationship) to a more general mesh architecture like mmbase. Nuke, typo3, phpcms, reactor and others can't scale to multiple site in the same database and also tend to embed HTML more. mmbase and opencms use xml extensively (sometimes to the extreme in my opinion), but their concept is good. We need to use XML more in phpWS. The xml-rpc in ezpublish is great. I propose we use xml-rpc for all inter-module communication like telling the email module to send mail based on a new user login "trigger". This makes the message passing almost ;) effortless and meets our commitment to open standards. phpGW has the best language processing in my opinion. It uses a database to store languages; phpcms and mmbase use XML language tags, which are more "official", but I really don't like. I think the phpGW model could use flat files, if they don't get too big. EVERYONE should download and read the source of the above packages so we can make phpWS a better product. It's not a cut and paste project here, but we need to decide what design elements we want to integrate into phpWS. Let's talk here. --Todd Owen |
|
From: clayton c. <cc...@ca...> - 2001-04-10 23:43:07
|
Todd, >Their "relation node" concept should be > our model of inter-object relationships. Instead of scoping (as defined in > ACS), where a group or user relates to an object, the relation node connects > arbitrary object types. i just had a read, and it does seem interesting. Like moving the ER model to the application level. This should be not too difficult to accomplish, though i still have to process how cardinality would fit into our scheme. What this would mean, and what i propose regardless, is that we keep metadata for every table in our system which is involved in such a relationship or defines entities which are exposed to the user. this makes a lot of things easy, as we can have a generic codebase to handle the neccessary base functions (permissions management, entity-entity mapping, etc) as well as generating the user interface. >We should use the mmbase > permission model or the ACS model (as modified by Clayton). This allows a > more abstracted access control scheme. i searched the PDF and it didnt mention permissions. do you have a reference ? > The xml-rpc in ezpublish is great. I propose we use xml-rpc for all > inter-module communication like telling the email module to send mail based > on a new user login "trigger". This makes the message passing almost ;) > effortless and meets our commitment to open standards. i had proposed before the "alert" model. if this works fine, then great. perhaps we can compare and see which works best, or if a combination would meet our needs. Alerts as implemented in TerraCotta are DB backed (except for high priority ones, which are handled immediately), so we can use them for delayed processing (like bulk invoice generation, etc) clayton |
Thanks for helping keep SourceForge clean.
X