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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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