Page 16 of 20
Posted: Tue Jun 06, 2006 10:27 pm
by MrPotatoes
Hockey wrote:Seriously, the reason why I like PHP is because if it crashes and burns you have some idea where you went wrong.
Huh...
I disagree...from other programming languages perspective...
Being loosely typed and very flexible has it's advantages...but knowing what went wrong isn't one of them
since i've been using PHP i've become a much better syntactical debugger and a better programmer in general. those 'errors' make you learn the language lol
Posted: Wed Jun 07, 2006 10:55 am
by santosj
MrPotatoes wrote:since i've been using PHP i've become a much better syntactical debugger and a better programmer in general. those 'errors' make you learn the language lol
I agree. At least with PHP, it is on the page, with JavaScript you have to check some JavaScript 'console' or alerts. Much rather get slapped in the face with an "Error: blah blah" then expect a result and not get it and have no understanding of why. Having a thousand alerts isn't really that good either.
arborint wrote:Uh ... you guys went off and built yet another database abstraction layer? I think I must have totally misunderstood the goal of this thread.
It appears that way, but something had to be done to make sure we referenced the username and password column correctly. I believe that we are not going to require that they use ours.
Posted: Wed Jun 07, 2006 11:39 am
by Christopher
santosj wrote:It appears that way, but something had to be done to make sure we referenced the username and password column correctly. I believe that we are not going to require that they use ours.
Not sure I understand that either, but I guess I'll just have to wait and see ...
Posted: Thu Jun 08, 2006 2:17 pm
by Ambush Commander
Well, it's not really another abstraction layer since we never had one to begin with. The wrapper is just an attempt at polymorphism for databases.
I think we'll start off with a Facade + Ad hoc queries, and then factor the SQL within into a facade + mapper if it turns out to be too complicated. I'd really like it if we could just $mapper->getUser($id) but that ease of use makes polymorphism a pain.
arborint, you haven't misunderstood the purpose of the thread. But we're trying to get a few basic needs down first.
Posted: Wed Jun 14, 2006 9:06 pm
by Ambush Commander
Hmm...
BUMP!!!
Okay, we'll scrap work on DB abstraction for now. What should be worked on?
Posted: Wed Jun 14, 2006 9:26 pm
by alex.barylski
Ambush Commander wrote:Hmm...
BUMP!!!
Okay, we'll scrap work on DB abstraction for now. What should be worked on?
Getting it done???

Posted: Wed Jun 14, 2006 9:30 pm
by Ambush Commander
That's like giving a blueprint to an architect which has one blob that says, "The Building". No idea where to start.
Posted: Wed Jun 14, 2006 10:22 pm
by Christopher
Ambush Commander wrote:What should be worked on?
For me the curious part about the Authentication part of Access Control is the Credential.
I think a while back in this thread I proposed that the application would BOTH create a credential object AND provide some sort of Validator object that tests the Credential. These would be given to our Authenticator which would provide a framework for them to do their thing. Creating the Credential and Validator would be made easy by the brilliant combination of interfaces and conventions that we would create.
My reasoning was twofold. First I wanted to push off as much work as possible in the first phase onto the application until we figured out how the thing actually worked. Second was to allow flexiblity, because the application would have to do the part that was custom to it. And I assumed that we would need to implement a couple common use cases to exercise the Authenticator. It is easier to add to a simple system than to try to simplfy a complex one.
But that leads me back to this rascally Credential. I looked around and the kind of things l found looked like this:
Code: Select all
class Property {
// application specific stuff?
}
class Credential {
var $properties = array();
function intersection($credential) {
}
function union($credential) {
}
function contains($property) {
return true || false;
}
function equals($credential) {
return true || false;
}
}
Those seem pretty abstract ... and I don't see at this point how they would be used or if that's the direction we might want to go. And the other part of the equation is the Validator which is probably just a rule base system of some sort.
Maybe identifying/defining Use Cases would be a way to know how to proceed?
Posted: Thu Jun 15, 2006 1:44 pm
by santosj
Well, I was looking at other systems that also provided authentication abstraction and it seems that they all pretty much suck. Not the authentication, I couldn't find any code for them, but the other packages provided with them.
But I did read an informative post about rewriting the wheel and seem that the only way true authentication abstraction will be widely used is if Zend does it or it is included in with PHP.
There is no guarantee that everyone will use Zend Framework, not because it is still technically in alpha. The licensing has been fixed, however, they can't provide a good enough wheel for every possible setup. I may want feature XYZ and the Zend Framework only provides X and Y. I add the Z feature, then I would still have to provide the update for each of my customers to use the feature.
PHP already has server authentication but no database one. It would be easy to setup a RADIUS server on a company intranet website, but over the web that is not possible.
OpenID
I was looking over the OpenID spec and it is pretty interesting. If it gets popular enough, I can see it probably being included in with PHP in my dreams perhaps, because it has gone nowhere currently and it doesn't seem feasible even if it was.
OpenID already has libraries in multiple languages and I don't think it would be all that difficult creating an adapter for the Authentication system.
PEAR
I don't like PEAR, partly because I'm on a shared hosting that makes installing it difficult, partly because I'm lazy and finally because I hate learning another person's code.
Posted: Thu Jun 15, 2006 2:17 pm
by Christopher
santosj wrote:But I did read an informative post about rewriting the wheel and seem that the only way true authentication abstraction will be widely used is if Zend does it or it is included in with PHP.
There is no guarantee that everyone will use Zend Framework, not because it is still technically in alpha. The licensing has been fixed, however, they can't provide a good enough wheel for every possible setup. I may want feature XYZ and the Zend Framework only provides X and Y. I add the Z feature, then I would still have to provide the update for each of my customers to use the feature.
I've signed the Zend CLA and have made some contributions already. If we come up with some good ideas here I will submit a proposal based on them.
I notice that there is a lot of focus on a "database one". Perhaps the reason "they all pretty much suck" is because people design them around a database model -- rather than designing a flexible, datasource independent core.
For me the key issue is how to we provide containers (like the Property and Credential I posted above) that allow almost any kind of system to be encapsulated in a form usable by our common set of managers/controllers?
Posted: Thu Jun 15, 2006 11:33 pm
by santosj
arborint wrote:I've signed the Zend CLA and have made some contributions already. If we come up with some good ideas here I will submit a proposal based on them.
I notice that there is a lot of focus on a "database one". Perhaps the reason "they all pretty much suck" is because people design them around a database model -- rather than designing a flexible, datasource independent core.
For me the key issue is how to we provide containers (like the Property and Credential I posted above) that allow almost any kind of system to be encapsulated in a form usable by our common set of managers/controllers?
Well, there is hope then. That is if they accept Ambush Commander's project. I sure that this project will be competing against at least two or more others. They may choose the one that doesn't suck. Ambush is following Zend's class Model, but I don't think they would accept the Database Abstraction in with the project.
People should probably be using Zend more when it reaches final. I don't really know what I think about it now. The security Filter and InputFilter, I will use eventually. I'm not to impressed on the others. Ez Components however does provide other features that I would like.
It will take a lot to get people informed on why they should use Ambush's Auth Implementation. You can't say that it is official Zend Framework, unless Zend accepts it into the framework (no guarantee). You also can't see that it has the 'cool' highly stable framework.
Posted: Fri Jun 16, 2006 4:46 pm
by bg
I prefer that the code used in my projects has all been written by myself. If you use someone elses code in your project and you have to debug it, there's a learning curve. You gotta study their code to understand how it works. Once in a while I will use someones code if I need a quick fix, but I will eventually implement it myself.
Posted: Fri Jun 16, 2006 5:17 pm
by Christopher
bgzee wrote:I prefer that the code used in my projects has all been written by myself. If you use someone elses code in your project and you have to debug it, there's a learning curve. You gotta study their code to understand how it works. Once in a while I will use someones code if I need a quick fix, but I will eventually implement it myself.
The inablity to use others code is the key quality of a certain class of programmer.
Posted: Fri Jun 16, 2006 6:39 pm
by bg
arborint wrote:bgzee wrote:I prefer that the code used in my projects has all been written by myself. If you use someone elses code in your project and you have to debug it, there's a learning curve. You gotta study their code to understand how it works. Once in a while I will use someones code if I need a quick fix, but I will eventually implement it myself.
The inablity to use others code is the key quality of a certain class of programmer.
Well I guess Ill take that as a compliment, but I should clarify. If I were working with a group of programmers, that would be different since we would all understand the workings of the codebase and conform to it. It's when you introduce outside code that it bothers me.
Posted: Fri Jun 16, 2006 7:39 pm
by Ambush Commander
While you guys are bickering, I'm going to put my foot down.
MySQLIterator is not going to be used. Period.
Sorry santosj.