So far, PSA4 is functional - except for the supplemental UI. The class
has been reworked to interface with PEAR::MDB instead of Metabase, and
so far the _restrict.php file is working. The next step will be to get
all the UI pages arranged and functional. Also, I have some work to do
on the SQL queries that are used in the class, and will get to them when
I start work on the UI.
I have been thinking of possibly setting up another restriction method
that checks for GET or POST variables. Then there would be 4 or 5 access
methods instead of just 2:
1. No access
2. Full access
3. Read only (no GET or POST allowed)
4. Read and GET
5. Read and POST
This option would allow for better control and more flexibility in CMS
systems.
There hasn't been any planning for this yet, it's just a thought at this
point. Version 4 will have API changes because I felt that a good audit
was needed. Therefore, don't expect to upgrade PSA to work with custom
apps that accessed the class methods directly. However, if you only use
PSA's _restrict.php and the supplied UI, then things should work without
hitch.
Obviously, there is going to be a lot of testing on my end before I
release even alpha or beta code. I don't have sf.net CVS setup where I
am developing, and I don't have the time to set it up right now, so
you'll all have to be in the dark for a while.
If anyone out there has any feature requests, now would be a great time
to submit them. Thanks to all you who've helped out in the past!
|
