From: Alex B. <en...@tu...> - 2001-05-12 00:52:10
|
whew, well, they're up: http://www.binarycloud.com/documentation/r2/overview.html much is different, there are few crazy-internal-conversation notes left :) The managers document is quite anemic as compared to how I would like it when it's in a final state, so please bear with me while I get documentation etc ready for those. Some things to note: -Init is just a class now, it's still an "application layer" but I actually wrote an Init class to get my thoughts together, and when I was done I realized it was good and checked it into r2 cvs! -The "core" layer (auth/perm/sess/dispatch/error) has pretty straightforward & complete method lists for the classes, though I am 100% open to suggestions at this point. (now's the time, after all!) -I will be adding another document, which is a complete, detailed overview of the entire installation tree. That will give me an opportunity to explain some of the things that don't necessarily warrant an entire new document, but that should be mentioned. --- This is a significant step up from r1, and I'm looking for people who would like to help build these components. If you're interested, contact me. _alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
From: Andreas A. <a.a...@th...> - 2001-05-13 11:05:51
|
Hi Alex, > well, they're up: > http://www.binarycloud.com/documentation/r2/overview.html Cool. Great work. But think the code conventions are a bit confusing (to me). For example. The mehtod names are named like: "Set_Name". The uppercase/lowercase thing seperates engough, so why add a "_"? and why start with a capital letter (classnames already start with a capital letter). To me it's more smooth to name functions that way: public: setName(); ( $obj->setName() vs. $obj->Set_Name() ) private: _setName(); or that way: set_name(); _set_name(); You alread do: $_my_variable_name vs. $_myvariablename. That should be in line with the other naming conventions. Also the global vairable naming. Varibale names starting with a _ are global. On the other hand methods starting with a _ should be considered as private!? Could be a bit confusing - ok its another context but not very linear, in my mind. At the this is not really as important as other topics. It's important the the conventions (no matter in what form they are applied) are constantly used. So what does the community think? Andi -- BTW: I'm working on a set of code standards for our internal projects. They are heavyly based on PEAR and the Java Code Standards which I think are a good base to work with. We "ported" them to PHP. You can download them here: http://www.thyrell.de/info/downloads/CodeGuide.pdf |
From: alex b. <en...@tu...> - 2001-05-13 18:21:21
|
> Cool. Great work. But think the code conventions are a bit confusing (to > me). For example. The mehtod names are named like: "Set_Name". The > uppercase/lowercase thing seperates engough, so why add a "_"? and why start > with a capital letter (classnames already start with a capital letter). To > me it's more smooth to name functions that way: > > public: setName(); ( $obj->setName() vs. $obj->Set_Name() ) > private: _setName(); > > or that way: > > set_name(); > _set_name(); > > You alread do: $_my_variable_name vs. $_myvariablename. That should be in > line with the other naming conventions. I'm actually open to changing those, assuming there is a general consensus here on what they _should_be. > Also the global vairable naming. Varibale names starting with a _ are > global. On the other hand methods starting with a _ should be considered as > private!? Could be a bit confusing - ok its another context but not very > linear, in my mind. The private method thing is a standard. The reason for the global standard (and yeah, I thought of that, i.e. it might be a little strange) is because you can put: /index.php?.foo=hello and get in php: $_foo which is quite useful, because you have a good way of always identifying what came in frmo the user, as opposed to "internal" variables. It's _very_ important to have a variable naming domain that identifies user input, in my opinion. > At the this is not really as important as other topics. It's important the > the conventions (no matter in what form they are applied) are constantly > used. > > So what does the community think? Right, funnily enough it's almost more important that there _is_ a standard :) But again, for those of you with suggestions, etc please speak up. Some of the code it written, but I'm happy to change it. Also, in the near future, I will push the r2 core cvs out to binarycloud.com, where I will continue development pubically. For those interested in participating, I'll set up accuonts for pserver. There will be a running install of binarycloud r2 w/MySQL on that box. > -- > BTW: I'm working on a set of code standards for our internal projects. They > are heavyly based on PEAR and the Java Code Standards which I think are a > good base to work with. We "ported" them to PHP. You can download them here: > http://www.thyrell.de/info/downloads/CodeGuide.pdf heh, your app framework is called storm - which is the name of the binarycloud admin interface. I also see why you find the $_global_variable_name standard yucky, because you have it defined just the opposite in your docs. This is one of the few things I consider to be quite important, actually: some simple, easily identifyable "this is coming from the outside" naming convention. I have used .var with good results, it's easier to track the security of a codebase. _alex |
From: Andreas A. <a.a...@th...> - 2001-05-13 19:19:26
|
Hi Alex, > The private method thing is a standard. Agreed. This is also the I use it. > /index.php?.foo=hello and get in php: $_foo > which is quite useful, because you have a good way of always identifying > what came in frmo the user, as opposed to "internal" variables. Ok, good point. I did not consider that. Actually I was not aware that the dot is translated to an undescore. Never used that this way. > It's _very_ important to have a variable naming domain that identifies user > input, in my opinion. Yuup. Better than only importing variables formerly defined as valid user vars. Ok got that. $_global is good, at the cost of strange looking, but thats worth it. > But again, for those of you with suggestions, etc please speak up. Some of > the code it written, but I'm happy to change it. Ok. My suggestion is to use straight forward naming of methods and varnames: Methods: setName() or set_name() privat class methods: _setName() or _set_name() Variables (global) , as discussed before: $_varName or $_var_name Variables (other): $varName or $var_name Classnames: Auth, ExecutionTimer Personally I prefer the setName and $_varName, $varName case. Becaus the seperations is more clear. Usage of "_" only for the extra "namespace" and for private class methods, not for seperation. But thats personal taste I guess. Important is to have a standard. > heh, your app framework is called storm - which is the name of the > binarycloud admin interface. Yes, the name is borrowed (hope you don't kill me for that ;-)). Actually, it's not a full working framework. Currently it's a colletion of libs I need for smaller projects (metabase, smarty, template abstraction, session abstraction, some language specific files) as a intermediate until bc r2 is usable :-) I also see why you find the $_global_variable_name standard yucky, because you have it defined just the opposite in your docs. Hehe ;-) > convention. I have used .var with good results, it's easier to track the > security of a codebase. Ok, you convinced me in this point. Andi |
From: alex b. <en...@tu...> - 2001-05-13 19:41:34
|
> Methods: setName() or set_name() > privat class methods: _setName() or _set_name() > Variables (global) , as discussed before: $_varName or $_var_name > Variables (other): $varName or $var_name > Classnames: Auth, ExecutionTimer I think the only place where there's actually a difference is naming caps standards, i.e. Public_Function as opposed to publicFunction or PublicFunction. I need to look at some of the incoming code (EntityManager, etc) before giving you a refined opinion on this. I'm leaning towards a lax standard that says "whatever you want" for naming caps. I would choose and adhere to one standard for Init and the Core classes, but metabase uses its own standards (manual _really_ dislikes PEAR), etc. anyway. I like the form: "verbNoun", like "setVariable" or "checkPermissions" just fine, but I think the decision will be made by the incoming code. _alex |
From: Peter B. <re...@f2...> - 2001-05-13 20:54:45
|
At 12:39 PM 5/13/01 -0700, you wrote: >I would choose and adhere to >one standard for Init and the Core classes, but metabase uses its own >standards (manual _really_ dislikes PEAR), etc. anyway. What does he have against PEAR? Also, can you give me a link o a PHP manual page describing the ?.foo=bar -> $_foo = "bar"; behaviour? Thanks, Peter. --oOo-- Narrow Gauge on the web - photos, directory and forums! http://www.narrow-gauge.co.uk --oOo-- Peter's web page - Scottish narrow gauge in 009 http://members.aol.com/reywob/ --oOo-- |
From: alex b. <en...@tu...> - 2001-05-14 01:05:00
|
> What does he have against PEAR? In principle, I think nothing. In practice I have seen him flam them (quite eloquently, actually) about their not invented here/ivory tower approach. I have to say that I agree with much of his opinion. > Also, can you give me a link o a PHP manual page describing the ?.foo=bar > -> $_foo = "bar"; behaviour? http://www.php.net/manual/en/language.variables.external.php#language.variab les.external.dot-in-names :) _alex |
From: alex b. <en...@tu...> - 2001-05-14 01:35:43
|
actually, might as well ressurect this idea: a while ago, I considered adding another core class, called "vars" or something, which would be used this way: -turn off global variable registration for php. i.e. if you do: /index.php?foo=hello you _cannot_ access: $foo in a script. I can see everyone scratching their heads. The most secure wat to get input from the outside world is referencing: $HTTP_POST_VARS[var], $HTTP_GET_VARS[foo], etc PHP already has a means of determining the variable order, usually it's GPCS (get post cookie session). The problem with that is it can dump strange stuff into your environment that you don't necessarily know about. We would provide a similar means of ordering this stuff, but abstracted into a class so nothing would actually make it into the environment until it was requested. So, I thought it might be a good idea to make all "external" variable access pass through this single point, and in doing so, I could: -impose some checks on the input -make sure that _no_ user input would _ever_ be in the environment my code is running without my explicitly including that input via: $Var->getVar('foo'); or the like. I sort of liked that, it's a little inconvenient, but it's much more secure. Also, you could add some intelligence to getVar like: getVar('string', 'foo'), and getVar would check that the requested variable was a simple string (containing no - <? ?> or < > pairs, etc) that may be a bit overboard, but it would certainly be secure. thoughts? this is pretty easy to do, btw. and because of the way r2 pages are designed, we could just make it an option that loads only if a page explicitly requests it. (this can already be donw with auth, perm, and session - so unlike binarycloud r1, binarycloud r2 will be usable without a database, assuming you don't use modules or core components that require queries.) maybe I'll write that into the spec for core and mark it as "to do" see if anyone is interested in doing it. _alex |
From: Andreas A. <a.a...@th...> - 2001-05-14 10:56:17
|
Hi Alex, > The most secure wat to get input from the outside world is referencing: > $HTTP_POST_VARS[var], $HTTP_GET_VARS[foo], etc Well this is the way I do all my projects. It's the most secure but also more effort. I check the $HTTP_*_VARS arrays and reference the variables to internal globals if required. More work, but possibly highest security. > So, I thought it might be a good idea to make all "external" variable access > pass through this single point, and in doing so, I could: Performing a type check or something (isEmail, isNumber, etc.) and on success return the reference. > I sort of liked that, it's a little inconvenient, but it's much more secure. I'm with you. > thoughts? Totally agree with you. But for people that don't like this, maybe the the trailing_ thing is an alternative. $myOutside_ (?myOutside.=value) Andi |
From: Jim H. <ji...@ha...> - 2001-05-14 01:44:41
|
Hello, I have just tried to install r1b on my windows2k apache, php, mysql. Firstly I'd like to comment / ask whether the installation can be done on a shared web hosting i.e. no root access, can only create mysql db through a 'web control panel' interface. It seems that Creade db schema insists on creating a db and subsequently failed because I did not use the root mysql access. Secondly, I have a debug message: PHP Warning The length of the needle must not be 0 file: h:/projectwebs/bc/binarycloud/core/lib/bread_crumbs_and_tabs.lib line 40 This is because BC_DOCROOT is indeed empty because I tried to put it where my apache docroot is and the doc said don't change if it's in docroot. I will keep playing with it and ask some more :) Cheers, Jimmy |
From: alex b. <en...@tu...> - 2001-05-14 02:07:03
|
> Hello, > > I have just tried to install r1b on my windows2k apache, php, mysql. > > Firstly I'd like to comment / ask whether the installation can be done > on a shared web hosting i.e. no root access, can only create mysql db > through a 'web control panel' interface. > It seems that Creade db schema insists on creating a db and subsequently > failed because I did not use the root mysql access. It's harder to do it, but certainly possible. You can't run create_db for obvious reasons, and you need to make sure that the database you _do_create uses the same name: binarycloud_db. Note, though that r2 will require access to non-module php on the command line, because all of the Makefiles are php. That's going to be harder to find on a shared hosting box with that config available, if you have no ability to develop your stuff on a local linux/bsd/etc box. I have no idea if the Makefile would work on Win, as I haven't done any testing. I think it's probably safe to assume that r2 will need a unix-esque machine to run on. The best way to run things would be: -local development machine (any cheap pc hardware will do, redhat or similar) -virtualhost (shared hosting) setup, with php 4.0.4+, we can control ini setting from within Init. > Secondly, I have a debug message: > > PHP Warning The length of the needle must not be 0 file: > h:/projectwebs/bc/binarycloud/core/lib/bread_crumbs_and_tabs.lib line 40 > > > This is because BC_DOCROOT is indeed empty because I tried to put it > where my apache docroot is and the doc said don't change if it's in > docroot. Yes, this is a sort-of-not-bug which is a result of me not testing a patch I received enough. I will send you the breadcrumbs lib which doesn't use BC_DOCROOT. > I will keep playing with it and ask some more :) great :) _alex |