Hey Bart, 2011/11/30 Bart Vanhauwaert <bvh-wi...@irule.be>: > Yes, I had the same thoughts. Wanted to send the least intrusive patch > that fixes the problem though. There might be equal issues lurking with > references to user. Didn't check those because, well, my user table is > named user :)
I've decided to fix it better. > Another thing I am wondering : the value of being able to specify the > column name is, well, having some semblance of control over how the > final SQL is laid out (for example because you need to play nice with an > existing database?). But then Dbo goes and adds a silent "_id" anyway to > what the user specifies. This negates that advantage. So now specifying It does, however the problem is a bit harder. When using composite primary keys, there are also multiple foreign keys, so you would need an exception then for that case. Also, the "_id" is not entirely magic: it is in fact "_" + (primary key(s) of the referenced table). > the column name has become a strict burden with dubious gains. Then why > not go ahead and provide a variant of the belongsTo/hasMany pair that > doesn't take a name parameter at all and figures it out itself? So I did. > Secondly, I am not a big fan of the hangman example for showing off > Auth. My issue is that you typedef-fed types with exactly the same name > as their Auth::Dbo class templates. Combined with using namespace Wt; > above it is not always directly clear if a used name refers to the > typedef within the example or the template class in the Wt code. Not as > helpfull as it could be for an example. I would suggest dropping the use > of using namespace Wt; in these examples and having all typedefs in > example code that potentially have the same name as templates in the > code be named as I can see that. We will adapt it. > Lastly, I am not 100% convinced on the names of things within Wt::Auth. > Correct me if I have things wrong here. There is an AuthInfo which as > far as I get is the single copy of authorative information used to > identify a single user in the Auth systemn. There are AuthInfo::Identity Yes -- but note: this is only the default 'mapping' -- when not using Auth/Dbo, you can as well have the auth information in the user class itself, as is done in the blog example. > which presents a way in which a client may prove they are really > AuthInfo explicitly (login, OAuth). And then there are AuthTokens which > are ways in which a client may prove they are really AuthInfo implicitly > (cookies mainly). > > I would expect these names to be respectively Identity, Passport and > Voucher. This way a user has a single Identity (as in real life), can > have one or more Passports (as in real life) proving their identity and > can have one more Vouchers which fullfill the same role but in a > different way. I'm always open for naming suggestions, as I truly believe this is the hardest part of programming (harder than all the technical things combined, including understand bugs in IE). But Passport and Voucher don't cut it for me. Idenitity is pretty good to me -- it really is used to identify a person within some namespace. (Personally, passport also reminds me of clearing customs in the USA, or loosing it -- it's associated with bad news). I might now you as Bart (login name), Jafar (nick name), 123-4567890-23 (credit card), b...@idontrule.be (email address). You wouldn't associate things like that with a "Passport" ? Token is more debatable since it is less saying, and at one point we also debated whether it should be merged with Identity. But then you start treating "Identity" more as a key-value pair dump for all kinds of things -- it is nicer to have real typing in the API, and nothing prevents you from mapping your storage in this way, independent from how it is used within the Wt::Auth API. My biggest uneasy feeling with the current API is actually the fact that "loginname" is a special kind of identity, and we moved it from User/AuthInfo into the general Identity framework. Regards, koen ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
