Menu
▾
▴
binarycloud-dev — development list for binarycloud
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
(57) |
May
(287) |
Jun
(166) |
Jul
(286) |
Aug
(273) |
Sep
(254) |
Oct
(144) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andreas A. <a.a...@th...> - 2001-07-05 20:08:44
|
> Or first thought was to rename ./core/ to ./bccore/. >Just a thought. Anybody else feel this way for my reasons, > or other "administrative" reasons. Hmm, I think that makes everything messy and adds redundant information to the structure. If bc core is renamed, consequently init has to be renamed to bcinit and lib to bclib and... and.. and... We have that information already in the direcory structure "binarycloud/*". I like the name "core" caus it is descriptive and simple. But, I see the problem of bad written scripts that may interpret core/ as a core dump. For bc scripts this should not be a problem ;) What cvs concerns it can be overwritten. As far as i remember core is a default cvsignore. My opinion is to leave core/ as is and just be careful with scripts. Andi |
|
From: Alby L. <al...@th...> - 2001-07-05 19:59:53
|
in my last message it should read:
function blah($array) {
- not -
function ($array) {
|
|
From: Alby L. <al...@th...> - 2001-07-05 19:58:40
|
I'm still working on the sql call stuff, and need a question answered. As
you can imagine - some calls will have 3 arguments (3 vars to be inserted
into a table) and others will have more or less, depending on the table
size. My php manual says that user-defined functions can be passed variable
amount of arguments using the following functions:
func_num_args(), func_get_arg(), and func_get_args()
but doesn't give any examples at all. What would the syntax be?
function ($array) {
$i = func_num_args();
for ($j=0; $j < $i; $j++) {
$arg_x = "arg_" . $i;
${$arg_x} = $array[$j];
}
something tells me that won't work but I'll give it a shot anyhoo.
Albert
al...@th...
|
|
From: John D. <jo...@we...> - 2001-07-05 19:48:42
|
Just to be clear, metabase is a separate project that binarycloud is embedding. From it's website (http://phpclasses.upperdesign.com/browse.html/package/20): Description: Package of classes that provide DBMS independent access and management of databases. Features: o Set of functions that call the selected DBMS driver objects functions supporting when possible: * Database connection setup * Operation error handling * Query constant data conversion * Direct queries * Prepared queries * Query result rows random access * Retrieve a limit range of rows of a SELECT query. * Transactions * Database object creation (tables, indexes, sequences) * DBMS driver supported feature query etc.. metabase is not what is responsible for actually generating your queries. The only place (that I'm familiar with) where queries are generated at run-time are in the EntityManager (and even then, only when we _can't_ use a compile-time generated query), which hasn't actually made its way into binarycloud at this point. But, generating queries requires a context. In the EntityManager, your context is your entities. A predefined set of queries can be generated (mostly at compile time, there's no reason to do them at run-time) for adding, deleting, updating, and fetching, based on the fields which you have designated as being the fields you want to be exposed to the world. You wouldn't in most cases, want to run mysql_fetch_field() at run-time and just interate over everything you find, as that would run contradictory to defining your entities at development time, and cause a lot of lost functionality. That's not to say, however, that there shouldn't be something that you could run on a particular table to generate an entity definition, which you can then edit/fine-tune. On the other hand, maybe it would be more correct to generate the SQL to make the tables based on the entity definitions, instead of the other way around. That could allow for some pretty cool shit, such as automatic schema migrations, true database independance, etc.. As to your question about the case control structure, see: www.php.net/switch John On Thu, 5 Jul 2001, Alby Lash wrote: > Whilst waiting for bc2 to be ready for production - I'm doing some > restructuring of my current project and I'm trying to isolate all of my sql > commands into a few dynamic functions. For the most part, I'll be doing a > lot of updating, inserting, and querying - big surprise I know. > > At any rate, I was thinking of building some tables that contain information > about the _real_ db structure, so that when I do an insert on a variable > driven table definition, I would be able to cycle through the field titles > and build my sql call that way. However, I thought, why not just grab the > table structure from the tables themselves using the mysql_fetch_field > command. So, when I was thinking about this - bringing the db structure out > in pieces to a simple dynamic sql query builder - I felt it sounded very > much like what I thought the BC metabase to be. However, I did some poking > around in the db "metabase" code and I couldn't find that much that made > sense from that perspective. > > Anyone want to try to explain to me what the metabase portion on BC is up > to, and if there is anything like what I am describing in BC2? Also, I came > across this often used function "case" that I couldn't find in the php > manual. Anyone know what this does? It seems to have something to do with > the data type thats in the table field. > > Thanks, > > Albert Lash > al...@th... > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > > -- John Donagher Application Engineer Intacct Corp. - Powerful Accounting on the Web 408-395-0989 720 University Ave. Los Gatos CA 95032 www.intacct.com Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD |
|
From: Alby L. <al...@th...> - 2001-07-05 19:11:57
|
Whilst waiting for bc2 to be ready for production - I'm doing some restructuring of my current project and I'm trying to isolate all of my sql commands into a few dynamic functions. For the most part, I'll be doing a lot of updating, inserting, and querying - big surprise I know. At any rate, I was thinking of building some tables that contain information about the _real_ db structure, so that when I do an insert on a variable driven table definition, I would be able to cycle through the field titles and build my sql call that way. However, I thought, why not just grab the table structure from the tables themselves using the mysql_fetch_field command. So, when I was thinking about this - bringing the db structure out in pieces to a simple dynamic sql query builder - I felt it sounded very much like what I thought the BC metabase to be. However, I did some poking around in the db "metabase" code and I couldn't find that much that made sense from that perspective. Anyone want to try to explain to me what the metabase portion on BC is up to, and if there is anything like what I am describing in BC2? Also, I came across this often used function "case" that I couldn't find in the php manual. Anyone know what this does? It seems to have something to do with the data type thats in the table field. Thanks, Albert Lash al...@th... |
|
From: Jimmy H. <ji...@aa...> - 2001-07-05 18:31:35
|
Alex.... Still waiting... Can I do a site with r2 now or is it still in 'alpha' / preview stage? |
|
From: Justin F. <je...@ey...> - 2001-07-05 18:12:45
|
Alex: Jason and I were talking this morning about the CVS "problem". We were kinda thinking what ./core/* should be named, because we don't like the name "core" too much for a directory. There are potential problems with, say, a lot of scripts (poorly written) that go through, say, files systems once a day and remove anything named "core". Or first thought was to rename ./core/ to ./bccore/. Just a thought. Anybody else feel this way for my reasons, or other "administrative" reasons. _jef (yes Alex, I stole that underscore idiom from you) -- Justin Farnsworth Eye Integrated Communications 321 South Evans - Suite 203 Greenville, NC 27858 | Tel: (252) 353-0722 |
|
From: Jimmy H. <ji...@ha...> - 2001-07-05 18:07:39
|
Alex.... Still waiting... Can I do a site with r2 now or is it still in 'alpha' / preview stage? |
|
From: alex b. <en...@tu...> - 2001-07-04 04:24:08
|
> 1. No file, no directory that is named "core" checks out.
> I co'ed from home in a bare directory and then
> [jef@localhost tmp]$ find . -name Debug.php
> [jef@localhost tmp]$ find . -name init
> ./r2/binarycloud/base/init
> [jef@localhost tmp]$ find . -name core
> [jef@localhost tmp]$
yeah, I'll fix that tomorrow - I _would_ like to know why cvs doesn't like
that dir, your points below about core dumps may actually be true..
> But I think you knew this. This must be
> some "feature" of CVS, to avoid core dumps
>
> 2. I can't remember exactly what the second question was,
> but I first co'ed in a place in my home directory
> for my "pristine" cvs place. Then I make in
> the MYPLACE/r2/binarycloud directory to see
> if there are any errors/problems. Then I copy
> MYPLACE/r2/binarycloud to /usr/local/binarycloud
> and make in /usr/local/binarycloud. I have to
> make again, because of the self-generated stuff
> such as in prepend.php which ends up defining
>
> define('BC_PATH', '/home/jef/bc/r2/binarycloud/build/en');
>
> instead of
>
> define('BC_PATH', '/usr/local/binarycloud/build/en');
if you consider /usr/local/binarycloud "production" - then you would only
ever need to copy r2/binarycloud/build/
> where the "development" thingy is.
> So, I have to do a second make, and cannot just
> copy and run... Yea, I could copy and probably
> edit and then run, if I knew for sure what to
> edit (anything besides prepend.php???).
Oh, yeah, that's marked for doing - i.e. we will incorporate a "location"
facility into the path definitions, which allows you to switch paths based
on environment, or manually, etc.
I.e. that make is complete, but is intended only for use in a single
location. That will obviously change in future.
> Maybe I am being redundant, and I am not quite sure
> what the second question was. I hope this helps.
>
> As far as I know, there is only the problem of no
> core directory. And as said, I am still humping along
> because I grabbed the ./core/* directory out of the tarball.
And that's essentially current.
> PS: I don't know cvs very well at all. Is it possible that
> the "filtering" of "core" out can occur on the client
> side, and not your side?
no, because it isn't in cvsroot.
erg
_a
|
|
From: Justin F. <je...@ey...> - 2001-07-04 01:58:22
|
Alex:
It got kinda hectic round quittin' time, I didn't get to
your emails on the CVS "problem", and since I use IMAP
at home and POP at work, I don't have them.
BUT, from what I remember:
1. No file, no directory that is named "core" checks out.
I co'ed from home in a bare directory and then
[jef@localhost tmp]$ find . -name Debug.php
[jef@localhost tmp]$ find . -name init
./r2/binarycloud/base/init
[jef@localhost tmp]$ find . -name core
[jef@localhost tmp]$
But I think you knew this. This must be
some "feature" of CVS, to avoid core dumps
2. I can't remember exactly what the second question was,
but I first co'ed in a place in my home directory
for my "pristine" cvs place. Then I make in
the MYPLACE/r2/binarycloud directory to see
if there are any errors/problems. Then I copy
MYPLACE/r2/binarycloud to /usr/local/binarycloud
and make in /usr/local/binarycloud. I have to
make again, because of the self-generated stuff
such as in prepend.php which ends up defining
define('BC_PATH', '/home/jef/bc/r2/binarycloud/build/en');
instead of
define('BC_PATH', '/usr/local/binarycloud/build/en');
where the "development" thingy is.
So, I have to do a second make, and cannot just
copy and run... Yea, I could copy and probably
edit and then run, if I knew for sure what to
edit (anything besides prepend.php???).
Maybe I am being redundant, and I am not quite sure
what the second question was. I hope this helps.
As far as I know, there is only the problem of no
core directory. And as said, I am still humping along
because I grabbed the ./core/* directory out of the tarball.
PS: I don't know cvs very well at all. Is it possible that
the "filtering" of "core" out can occur on the client
side, and not your side?
_jef
--
Justin Farnsworth
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722
|
|
From: Alex B. <en...@tu...> - 2001-07-03 21:16:27
|
> 1. Saved my modules/masters/layouts > 2. Snipped off the /usr/local/binarycloud tree > 3. Snipped off the "bc" tree in my /home/jef where > I "buffer" the CVS > 4. Went to /home/jef/bc > 5. Got the CVS > 6. couple of edits, (a) force LANGS=en in the Makefile > and (b) changed the shebang in script that > let it know php was really in /usr/bin/php > 7. went to ./binarycloud and typed make, - everything OK > 8. copied ./binarycloud (in home tree) to /usr/local/binarycloud > 9. went to /usr/local/binarycloud, changed BCHOME, did make > and all OK > 10. copied the /usr/local/binarycloud/build/en/htdocs/* > stuff up to the DOCUMENT_ROOT. > 11. pointed browser to ..../bcdocs/index.php and got > > Warning: Failed opening > '/usr/local/binarycloud/build/en/binarycloud/core/Debug.php' for > inclusion (include_path='.:/usr/share/php') in > ./prepend.php on line 33 > > URG, their ain't no ./core directory. It is missing in the > place I keep CVS agh.. I've run into this before. I have no idea, CVS does not like to import core. f*ck. That's a bad import, I thought I checked that but maybe I was looking at an old co. I'll fix that later today. > [jef@dev8 binarycloud]$ pwd > /home/jef/bc/r2/binarycloud/build/en/binarycloud > [jef@dev8 binarycloud]$ ls -l > total 8 > drwxr-xr-x 2 jef jef 4096 Jul 3 15:35 init/ > drwxr-xr-x 3 jef jef 4096 Jul 3 15:35 lib/ > [jef@dev8 binarycloud]$ > > nor when I copied the tree to /usr/local/binarycloud > and remade everything, obviously, > > [jef@dev8 binarycloud]$ pwd > /usr/local/binarycloud/build/en/binarycloud > [jef@dev8 binarycloud]$ ls -l > total 8 > drwxr-xr-x 2 jef jef 4096 Jul 3 15:41 init/ > drwxr-xr-x 3 jef jef 4096 Jul 3 15:41 lib/ > [jef@dev8 binarycloud]$ > > Now, I went back to the tarball that I had used before, > and untarred it again in a ./tmp directory. There, > after making (or even before), core is in the tarball. > > [jef@dev8 tmp]$ find `pwd` -name Debug.php > /home/jef/tmp/r2/binarycloud/base/core/Debug.php > /home/jef/tmp/r2/binarycloud/build/en/binarycloud/core/Debug.php > [jef@dev8 tmp]$ > > After I copied this core directory up to where it belongs > in /usr/local/binarycloud, everything worked fine. > > So, the core directory is missing from CVS, and things worked > here before because of the residue from the tarball. When I > started "virgin" cvs, the missing ./core became evident. doh! _a -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: Alex B. <en...@tu...> - 2001-07-03 21:16:09
|
Just to check here, you _did_ copy the binarycloud/build/en/binarycloud directory, not just binarycloud/ right? -alex |
|
From: Justin F. <je...@ey...> - 2001-07-03 20:46:12
|
Alex: There seems to be something rotten in the CVS. Now when the tarball first came out, I got that and installed it at home, and did it dirty, namely let the un-tarring just write over the current directory structure, which was, incidentally, an older CVS from jason's account. Everything worked perfectly. This was the situation at work too. But, I decided to get organized, get my own CVS etc, and start from scratch with the latest CVS. So I: 1. Saved my modules/masters/layouts 2. Snipped off the /usr/local/binarycloud tree 3. Snipped off the "bc" tree in my /home/jef where I "buffer" the CVS 4. Went to /home/jef/bc 5. Got the CVS 6. couple of edits, (a) force LANGS=en in the Makefile and (b) changed the shebang in script that let it know php was really in /usr/bin/php 7. went to ./binarycloud and typed make, - everything OK 8. copied ./binarycloud (in home tree) to /usr/local/binarycloud 9. went to /usr/local/binarycloud, changed BCHOME, did make and all OK 10. copied the /usr/local/binarycloud/build/en/htdocs/* stuff up to the DOCUMENT_ROOT. 11. pointed browser to ..../bcdocs/index.php and got Warning: Failed opening '/usr/local/binarycloud/build/en/binarycloud/core/Debug.php' for inclusion (include_path='.:/usr/share/php') in ./prepend.php on line 33 URG, their ain't no ./core directory. It is missing in the place I keep CVS [jef@dev8 binarycloud]$ pwd /home/jef/bc/r2/binarycloud/build/en/binarycloud [jef@dev8 binarycloud]$ ls -l total 8 drwxr-xr-x 2 jef jef 4096 Jul 3 15:35 init/ drwxr-xr-x 3 jef jef 4096 Jul 3 15:35 lib/ [jef@dev8 binarycloud]$ nor when I copied the tree to /usr/local/binarycloud and remade everything, obviously, [jef@dev8 binarycloud]$ pwd /usr/local/binarycloud/build/en/binarycloud [jef@dev8 binarycloud]$ ls -l total 8 drwxr-xr-x 2 jef jef 4096 Jul 3 15:41 init/ drwxr-xr-x 3 jef jef 4096 Jul 3 15:41 lib/ [jef@dev8 binarycloud]$ Now, I went back to the tarball that I had used before, and untarred it again in a ./tmp directory. There, after making (or even before), core is in the tarball. [jef@dev8 tmp]$ find `pwd` -name Debug.php /home/jef/tmp/r2/binarycloud/base/core/Debug.php /home/jef/tmp/r2/binarycloud/build/en/binarycloud/core/Debug.php [jef@dev8 tmp]$ After I copied this core directory up to where it belongs in /usr/local/binarycloud, everything worked fine. So, the core directory is missing from CVS, and things worked here before because of the residue from the tarball. When I started "virgin" cvs, the missing ./core became evident. _jef -- Justin Farnsworth Eye Integrated Communications 321 South Evans - Suite 203 Greenville, NC 27858 | Tel: (252) 353-0722 |
|
From: Andreas A. <a.a...@th...> - 2001-07-02 19:57:54
|
Hi Alex, > did the cvs synch, tested - works for me. > please let me know if there are any problems :) cool!! works fine. andi |
|
From: Alex B. <en...@tu...> - 2001-07-02 19:05:54
|
hi all, did the cvs synch, tested - works for me. please let me know if there are any problems :) _a -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: Alex B. <en...@tu...> - 2001-07-02 17:51:52
|
> Have a look over the request class (in core). There is also a newer version > available as soon as alex makes the cvs synch. Yes, do... and thanks for reminding me about the synch. _alex -- alex black, ceo en...@tu... the turing studio, inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 |
|
From: Alex B. <en...@tu...> - 2001-07-02 17:50:01
|
> So, in BC, if I want to lay down the law, and force > everyone to: > > 1. use POST > 2. or use a cookie > 3. or establish a common precedence like POST/cookie/GET > 4. or something else. > > So, what do youse guys do????? use the request class, which I have not tested - but the idea is to be able to completely control your incoming vars. so you could have a constant in the user conf that just shuts off access to get vars through thr request class. that could be cool. > THIS MAY BE IMPORTANT for the community in general. There > is no reason for Alex to "establish policy" on this, but > if there is no convention, then in the brave new world > of binarycloud, when we start exchanging modules or > contributing them, this very-important-precedence of > var-passing must be honored, i.e., a convention is "needed". Thus request. use of request _will_ be required for all binarycloud-distro packages, so installations can retain control over their own environment. > I donno what I am going to do at my business, but I may > say > 1. Use POST when you can > 2. Use a cookie if you can't > > and that implies a session for all modules to work right > together if drawn from different packages. ? > But, if Andreas contributes something cool, and uses GET > to start a round trip, my modules have to look in GET first > and then error out. We haven't integrated PEAR_Error yet - but I don't think I see the problem? > Or else, I have to rewrite/check every flippin' module that > I will pull down to check. I think you see the "problem" > if I don't do a re-write. > > Maybe this does not seem like a "problem" to youse guys. > Pour moi, l'administrateur anale - it is a "problem". I don't get it, can you provide a little more detail? > Again, what do you gurus do???? Was this an issue, ever, > with r1, which I know nothing about? R1 assumes that you have register_globals On, which I didn't like. Request completely solves all those problems, because it add a nice, configurable request layer for all "incoming" user data. > _jef > > _alex |
|
From: Alex B. <en...@tu...> - 2001-07-02 17:49:59
|
I have no changes planned for the import delimiters - they will stay "." :) -a > It sounds as though the import, include, or include_once ( I can't remember > which one this pertains to) delimiter problem has been solved, but I wanted > to throw in that Flash, as an odd ball comparison, also uses dots in > ActionScript to delimit objects: > > _root.parent.child._attribute and the like, so when you're not dealing with > file names, it really kind of makes sense. One time when I did run into a > problem with this was when I was trying to control an attribute of a child > object with db driven data, I couldn't specify the object directly, or even > the object hierarchy (_root.parent) from the database because it won't let > me put dots into varchars. That, unfortunately, I am certain was my fault > and not necessarily a flaw in the system arch. > > > I also vote for _Dot Delimiters_. Hey - you just can't argue with > alliteration. > > Alby Lash > al...@th... > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > -- 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-07-02 14:01:08
|
Hi Alby, Justin,
> I am one of those lazy coders, but I can't stand using GET but often do to
> ensure the integrity of my variable names and values. This has been a
thorn
> in my side and I would like a method to handle this insecurity as well.
> My initial thought would be to include a debug option to globally echo all
> post varnames and values to the page. This is not a holistic solution
> however as I am often using servlet like pages that only include code and
> call a header ("Location: snafu.php"); when my logic is done.
> Anyone have any other ideas/problems to contribute to this?
I'm with you. I don't like GET vars very much because they mess up the
Location-Input-Line. In fact that's just an aesthetic concern. What the
security concerns GET vars are not more dangerous than POST vars, except
that the bad guy does not have to view the html source and start his attack.
So it does not matter if post or get (imho), everything coming from the
outside is a potential security risk and therefore it should be carefully
doublechecked twice. I don't want to use forms for each and every operation.
If such high security is required and checking the incoming is not enough -
maybe SSL is an option.
Sometimes GET is really useful. If you have a list of db results you want to
display, for example. E.g. I would use the GET var for the "delete"
operation. To avoid using forms and maybe image buttons for every row (of
course with a "are you sure" question).
Or for switchting languages. Or for the sessionId if cookies are disabled. I
personally don't rely that users do have cookies enabled.
Have a look over the request class (in core). There is also a newer version
available as soon as alex makes the cvs synch.
Andi
|
|
From: Alby L. <al...@th...> - 2001-07-02 13:05:32
|
Justin,
I am one of those lazy coders, but I can't stand using GET but often do to
ensure the integrity of my variable names and values. This has been a thorn
in my side and I would like a method to handle this insecurity as well.
My initial thought would be to include a debug option to globally echo all
post varnames and values to the page. This is not a holistic solution
however as I am often using servlet like pages that only include code and
call a header ("Location: snafu.php"); when my logic is done.
Anyone have any other ideas/problems to contribute to this?
Alby Lash
Justin said, and I quote:
"
Now, I hate GET vars because of their security problem.
As far as I am concerned, their only utility is for
bookmarking, or lazy coders. They are a definite security risk if you
have weaknesses in your design.
"
|
|
From: Alby L. <al...@th...> - 2001-07-02 12:58:26
|
It sounds as though the import, include, or include_once ( I can't remember which one this pertains to) delimiter problem has been solved, but I wanted to throw in that Flash, as an odd ball comparison, also uses dots in ActionScript to delimit objects: _root.parent.child._attribute and the like, so when you're not dealing with file names, it really kind of makes sense. One time when I did run into a problem with this was when I was trying to control an attribute of a child object with db driven data, I couldn't specify the object directly, or even the object hierarchy (_root.parent) from the database because it won't let me put dots into varchars. That, unfortunately, I am certain was my fault and not necessarily a flaw in the system arch. I also vote for _Dot Delimiters_. Hey - you just can't argue with alliteration. Alby Lash al...@th... |
|
From: Justin F. <je...@ey...> - 2001-07-02 07:17:19
|
Guys:
I have been trying to get some experience and feel for
BC when a site/application starts snapping modules
together from different "packages". I have run across
a "problem", that is not a problem, really, just
that some kind of convention has to be established
for the set of modules that we (Eye) are going to use.
It is kind of interesting that the first simple thing
I did, I used anchor tags for navigation, and therefore
used the $HTTP_GET_VARS to collect information after
the round trip. Then, if another module used a
<form>, I used POST. SO, after the round trip,
I would collect what I needed from either HTTP_GET_VARS
or HTTP_POST_VARS, whichever I was expecting. Just
getting started, the modules were not "general", and
I just coded like I was doing a stand-alone site.
I am certainly not used to not knowing where the
data is going to come from after the round trip.
However, to use, and make general, a BC module, you
have to do something like:
(a passed-in parameter is needed)
1. check if HTTP_GET_VARS['parm'] is not empty.
2. if not empty, set the internal class var.
3. check if HTTP_POST_VARS['parm'] is not empty.
4. if not empty, set the internal clas var, overriding
any GET pass of $parm. THIS ESTABLISHES THE
PRECEDENCE OF POST OVER GET (and any built-in default).
5. check if the $this->parm is empty.
6. if it is empty, then, buddy, you have to do something
and trap that error gracefully. Otherwise, these
modules are not going to "work right" with any
other package:module. And I hope that PEARerror makes
this easy, calling it, hoping it will clean up
properly and clean up gracefully, when exiting.
[I haven't looked at PEARerror yet]
Now, I hate GET vars because of their security problem.
As far as I am concerned, their only utility is for
bookmarking, or lazy coders. They are a definite security risk if you
have weaknesses in your design.
So, in BC, if I want to lay down the law, and force
everyone to:
1. use POST
2. or use a cookie
3. or establish a common precedence like POST/cookie/GET
4. or something else.
So, what do youse guys do?????
THIS MAY BE IMPORTANT for the community in general. There
is no reason for Alex to "establish policy" on this, but
if there is no convention, then in the brave new world
of binarycloud, when we start exchanging modules or
contributing them, this very-important-precedence of
var-passing must be honored, i.e., a convention is "needed".
I donno what I am going to do at my business, but I may
say
1. Use POST when you can
2. Use a cookie if you can't
and that implies a session for all modules to work right
together if drawn from different packages.
But, if Andreas contributes something cool, and uses GET
to start a round trip, my modules have to look in GET first
and then error out.
Or else, I have to rewrite/check every flippin' module that
I will pull down to check. I think you see the "problem"
if I don't do a re-write.
Maybe this does not seem like a "problem" to youse guys.
Pour moi, l'administrateur anale - it is a "problem".
Again, what do you gurus do???? Was this an issue, ever,
with r1, which I know nothing about?
_jef
--
Justin Farnsworth
Eye Integrated Communications
321 South Evans - Suite 203
Greenville, NC 27858 | Tel: (252) 353-0722
|
|
From: alex b. <en...@tu...> - 2001-07-01 17:21:36
|
hey, they have cvs commit messages up on the site, that's cute :) I'll download the code and have a look, but seems pretty nice. _alex ----- Original Message ----- From: "Andreas Aderhold" <a.a...@th...> To: <bin...@li...> Sent: Sunday, July 01, 2001 6:35 AM Subject: RE: [binarycloud-dev] FW: GroupIT Engine > Hi Jason, > > >> BC is the best designed and coded php "app" I've seen so far. > > > Speaking of good/bad code, take a look at Drupal some time > > (www.drupal.org). It's a PHP content management app with "beautiful" > > design structure and modularity. I learned quite a bit from this > > project, namely "Less is More". > > Downloaded it today and had a breif look. Well designed and modular, looks > nice. But had not the time to inspect the code extenively. > > andi > > > _______________________________________________ > binarycloud-dev mailing list > bin...@li... > http://lists.sourceforge.net/lists/listinfo/binarycloud-dev > |
|
From: Andreas A. <a.a...@th...> - 2001-07-01 13:31:33
|
Hi Jason, >> BC is the best designed and coded php "app" I've seen so far. > Speaking of good/bad code, take a look at Drupal some time > (www.drupal.org). It's a PHP content management app with "beautiful" > design structure and modularity. I learned quite a bit from this > project, namely "Less is More". Downloaded it today and had a breif look. Well designed and modular, looks nice. But had not the time to inspect the code extenively. andi |
|
From: Andreas A. <a.a...@th...> - 2001-07-01 12:02:50
|
Hi Alex,
>> add resource handler for true files:
>> import('file:a_file_name');
> why would one not then just use include_once?
>i.e. we'd be replicating (unnecessarily, unless your suggestion would do
>something different than when I have in mind) functionaliy that php already
>takes care of.
That's right. I wont change the import. But If you plan to modify import
the way Justin demands this would be the way how I would do it.
Again I would not change import. Include does a fine job, so why adding
overhead.
--
Andi
|
5 messages has been excluded from this view by a project administrator.
