RE: [Phpwebsite-developers] Table Naming Conventions and Multiple Instances of phpWebSite

[Geoff S. <Ge...@Ho...>]

Todd:

I have a suggestion for you.

I've been invited to be a developer, but have not yet received my CVS
access. Jeremy asked me what userid and password I want, but, I haven't
heard back from him.

I'll go in, look at the code, and make a suggestion. I think it is a simple
search and replace -- remember that the SQL queries are all strings so
concatenating a prefix variable onto the table names should be more
mechanical find and replace then anything else. I'll look at the code and
provide a specification within the next 3 or 4 hours.

Once approved, I'd be happy to do the actual work.

The only problem here is that I have to put up a site on Monday or Tuesday
at the latest and I don't have CVS access yet. So, Jeremy, if you are out
there reading this...

One item: I really like what you have proposed for the administration
system. Even more then the OID aspect, I'm especially excited about the
prospect of having the following:

Giving some users that authority to post, delete, and modify their own
submissions.
Having multiple admins who can manage one or more topics, pages, etc.

I think that this will require having a user and admin "group" scheme in
order to make it work.

NOW: Here's a BIG concern that I mentioned previously and gotten no
response: I've looked at the database and there is no real database design.
And, of course, we all know that the code is sort of all grafted together.
SO, I'm hoping that we can take the time to do some serious modeling of the
system and come up with an architecture and a new data and function model.
(I'd call it "object-oriented," but, I don't want to confuse the issue with
coding technique.)

My suggestion would be this:

Do some analysis
Do the design
Build a new database
Build a new system framework consisting of source code files, classes (if
they are used), and function prototypes (Functions that have the function
name, the calling and return variables and values defined, but have no
procedural code in them).
Then, steal procedural code from the existing system to go into the new
functions and classes.
Write new code as needed.

My concern is that if we proceed "inside out" by trying to upgrade the
existing system in place, we will never achieve the goal of a system that is
powerful, extensible, and maintainable.

Geoff

Geoff,

> That means you must rely on the security in phpWebsite to control access
> if you segment by using an organization id (OID) in the tables. (Not that
> there's anything wrong with that.)

My philosophy is consistant with the statement above.  You are correct that
separate tables are the only way to use MySQL database security (row level
security would be a bear anyway).  Your observation that each "site" admin
could dump (and restore) their own tables is a good point.  My "combined"
table scheme would have "super" administrators, like root, that could
create, delete and modify site administrators, back-up data and so forth.
More on this later.

> I agree that having an organizational unit id would be a great idea.
> HOWEVER, that will not happen soon. I'd like to have the separate
> table enhancement, because it is dirt easy to implement.

The ouid scheme will happen soon, but not by April 15th (I'll grant you
that).

> Now, I think that BOTH of these techniques have their place and are
> appropriate for different circumstances.

Agreed.  We don't want a fork if both methods can coexist.  Can you lay out
more coding details for us to help you implement this?

--Todd Owen



_______________________________________________
Phpwebsite-developers mailing list
Php...@li...
http://lists.sourceforge.net/lists/listinfo/phpwebsite-developers