Re: [binarycloud-dev] Conventions - A question for the group...

[Alex B. <en...@tu...>]

> 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