convention for making a method non-public
Jeffery Olson
I'm curious if there is any (current or planned) convention to make a
function defined inside of a controller 'non-public' or not-exposed?
I'm asking this because I couldn't find anything to that effect in the
documentation, so I went and implemented it myself...
the purpose behind it was so that I could have code that I could share
between all of the functions in a controller, without having to monkey
around with sys.path or site.py and doing imports (it seemed kind of
messy and not very portable) ...
I mostly intended to use these "internal" functions between multiple
functions in one controller. I intend to use them so that they have no
"side effects", ie they take inputs and return something and do
nothing else besides that (a risk introduced by having methods that
can access all of the internal state values like request, session,
etc), although it would have access to the models and the defined
tables (which could only otherwise be accomplished by implementing
these functions in some external python file and adding
'/gluonroot/gluon' to sys.path / site.py and doing 'from sql import *'
in your external python, which would then have to have it's location
also exposed in sys.path so that the controller could import it...
confusing and complicating from a portability perspective )...
Also, a drawback of using externally defined functionality (ie a
homebrew library) for gluon is that you have to restart the server
every time you make a change, unlike changes to the
views/models/controllers themselves, which are immediately available
(a big plus, in my opinion)...
still with me?
...so here was my implementation (3 steps):
1.) I added the following to the end of myregex.py
# jeff's custom pattern to match functions that end with "_internal"
regex_internalfunction=re.compile('^.+_internal$',re.IGNORECASE)
2.) then I added the following to main.py (around line 159, between
the "access the requested application" and "load cookie" steps in
wsgibase() ):
###################################################
# jeff's hack to dodge displaying "internal methods"
###################################################
if regex_internalfunction.match(request.function):
raise HTTP(400,'Attempt to access internal function')
3.) restarted the gluon server
so what this does is make it so that whenever a user requests a
function defined in a controller that ends with '_internal', like so:
http://hostname.com/appname/controllername/function_internal
they get redirected to an error page.
of course this is a simple pre-emptive check, and it would raise this
error regardless of whether the function actually existed (being
possibly misleading.. perhaps a more generic-sounding error would be
aprop.)
This basically creates a "category" of functions within a controller
that aren't exposed to external users of an application, freeing the
developer up to make functions that 1) take arguments and 2) can
return something besides a dict without fear of repercussions...
I mostly envision myself using these "internal functions" for the
purpose of doing repetitive, heavy lifting tasks within the context of
one controller (ie getting crypt hashes of a password or determining
if a user exists in the db, etc) ... this kind of functionality is
quite cumbersome to implement, otherwise. as far as i can tell,
anyways...
i would of course caution against having these methods change state
except in the context of input->output (ie who knows what kind of
weird cases could arise if you pushed all of the business logic into
these sorts of functions) ...
Anyways, I tooks some liberties with going into the "guts" of gluon to
enable this functionality... is this something that would be
considered useful, or does it go against the "best practices" that
gluon adheres to? or does this functionality already exist? (in which
case i apologize for wasting the time of anyone reading this)
Cheers,
Jeff
Jeffery Olson
underscores ('_') pre-prending a function name... quite a bit less
verbose and it still get's the message across...
i changed the addition in myregex.py to:
# jeff's custom pattern to match functions that end with "_internal"
regex_internalfunction=re.compile('^_+\w+$',re.IGNORECASE)
it now checks for one or more underscores and then one or more word
characters in the supplied string
Jeffery Olson
that takes arguments (i'm guessing?) causing them to not be exposed...
horray for learning!
mdip...@cs.depaul.edu
function that does not take arguments and you still don't want to
expose it you can also use a trick... add a space after the function
name and before ().
Massimo
On Nov 21, 9:15 pm, "Jeffery Olson" <olson.jeff...@gmail.com> wrote:
> it seems i did waste my time, as it seems that defining a function
> that takes arguments (i'm guessing?) causing them to not be exposed...
>
> horray for learning!
>
>
> > on second thought, i refined the regex to check for one-or-more
> > underscores ('_') pre-prending a function name... quite a bit less
> > verbose and it still get's the message across...
>
> > i changed the addition in myregex.py to:
> > # jeff's custom pattern to match functions that end with "_internal"
> > regex_internalfunction=re.compile('^_+\w+$',re.IGNORECASE)
>
> > it now checks for one or more underscores and then one or more word
> > characters in the supplied string
>