Proposal for importing functions into controllers

[Robin B]

Controller functions taking arguments, or functions with an extra
space like def index (): are hidden:

http://groups.google.com/group/web2py/browse_thread/thread/35c15761dc3801e7/b0ee7945e272922e?lnk=gst&q=arguments+space+#b0ee7945e272922e

This is good that you can hide functions somehow, but using only a
regex to detect controller functions requires people to copy-paste
common actions into every controller (bad).

Could a controller be loaded, and its symbols that are functions
checked for a tag (attribute) indicating that they are also exposed.
This way you can import actions/functions in the models and in the
individual controllers.

Proposal: continue to use the regex for backwards compatibility, but
also expose functions that are explicitly tagged as exposed by some
decorator.

Examples:

# in models/0.py
@T2.decorators.expose
def stats():
return 'stats'

# in modules/crud.py
@T2.decorators.expose
def update():
return 'update'

# in controllers/posts.py
from modules.crud import *

It would be fully backwards compatible!

Feedback?

Robin

[mdipierro]

Not sure I undestand. This goes in a module? not a model?

On Jan 8, 12:03 am, Robin B <robi...@gmail.com> wrote:
> Controller functions taking arguments, or functions with an extra
> space like def index (): are hidden:
>

> http://groups.google.com/group/web2py/browse_thread/thread/35c15761dc...

[Yarko Tymciurak]

On Thu, Jan 8, 2009 at 12:03 AM, Robin B <rob...@gmail.com> wrote:

Controller functions taking arguments, or functions with an extra
space like def index (): are hidden:

http://groups.google.com/group/web2py/browse_thread/thread/35c15761dc3801e7/b0ee7945e272922e?lnk=gst&q=arguments+space+#b0ee7945e272922e

This is good that you can hide functions somehow, but using only a

Well - explicit is better, so this is also BAD! ...  too obtuse, clever, tricky, hidden...

 

 

regex to detect controller functions requires people to copy-paste
common actions into every controller (bad).

Could a controller be loaded, and its symbols that are functions
checked for a tag (attribute) indicating that they are also exposed.
This way you can import actions/functions in the models and in the
individual controllers.

Proposal: continue to use the regex for backwards compatibility, but
also expose functions that are explicitly tagged as exposed by some
decorator.

Examples:

# in models/0.py
@T2.decorators.expose
def stats():
 return 'stats'

Explicit is better, but I wonder if this is the right (most useful) idiom???

I would think that normally, one would assume what they write will NOT be hidden, so perhaps

a more useful pattern is 

@T2.decorators.hidden

def stats():

  return 'stats'

Are there other explicit ways to accomplish this?

Let's have some more thought, ideas around this.

FWIW - I would not worry about backward compatiblity on this until

all the most useful alternatives are considered;  then we can balance

the improvement, vs. compatibility.

Yarko.

[Robin B]

Massimo,

> Not sure I undestand. This goes in a module? not a model?

The example shows that it can go in either or both.

You could put it in a module and then import it into a controller to
import actions into one specific controller. You could put it in a
model to add an action to all controllers.

The first time a controller is requested, the controller is exec'ed,
the resulting environment is searched for functions of no args that
have the specific attr that was set by the decorator, these actions
are merged with the actions found with the regex. All the possible
controller_action.pyc is compiled and stored like usual, now you can
call actions that were created in the models or imported from a module
(crud, resources, admin, stats etc).

Robin

[Yarko Tymciurak]

yep - after reading that thread Robin pointed to at the head of this thread,  the space behavior definitely looks like an expedient hack...

and reading the response from Massimo there:
"If you have
function that does not take arguments and you still don't want to
expose it you can also use a trick..."

I'm with Robin - forget the "tricks" and be explicit... but, as I suspected, the usual intent is expose no-argument controllers, so the exceptional case calls for a decorator, a better name than I originally posted:

@not_exposed
def  myfunc():
  #blah, blah, ...

[Yarko Tymciurak]

Let me double check to make sure:

this behavior -  non-argumented controllers being exposed / accessible from a client - is not (only) t2; this is general web2py behavior,

correct?

[Robin B]

Very true. This is more general than t2, I just dislike adding so
many symbols to the global namespace, so this could be added to a
helpers.* object if it existed.

The reason for this proposal is that currently you cannot import
actions easily:

# in controllers/default.py
from modules.crud import create

The create action will not be found because actions are currently
found with a regex.

Robin

On Jan 8, 1:19 pm, "Yarko Tymciurak" <yark...@gmail.com> wrote:
> Let me double check to make sure:
>
> this behavior -  non-argumented controllers being exposed / accessible from
> a client - is not (only) t2; this is general web2py behavior,
>
> correct?
>

> On Thu, Jan 8, 2009 at 1:15 PM, Yarko Tymciurak <yark...@gmail.com> wrote:
> > yep - after reading that thread Robin pointed to at the head of this
> > thread,  the space behavior definitely looks like an expedient hack...
>
> > and reading the response from Massimo there:
> > "If you have

> > function that does not take *arguments* and you still don't want to

> > expose it you can also use a trick..."
>
> > I'm with Robin - forget the "tricks" and be explicit... but, as I
> > suspected, the usual intent is expose no-argument controllers, so the
> > exceptional case calls for a decorator, a better name than I originally
> > posted:
>
> > @not_exposed
> > def  myfunc():
> >   #blah, blah, ...
>

[Yarko Tymciurak]

Yep, Robin - saw your other post on this.... I'm liking the direction this is going...  thanks!
Yarko

[mdipierro]

Me too but I need more time to look into details... today is not the
optimal day. Tim, could you email me your proposals so that it does
not get list in the list?

Massimo

On Jan 8, 2:54 pm, "Yarko Tymciurak" <yark...@gmail.com> wrote:
> Yep, Robin - saw your other post on this.... I'm liking the direction this
> is going... thanks!
> Yarko
>

[Timothy Farrell]

Dude...wait, what?

what proposal?

--
Timothy Farrell <tfar...@swgen.com>
Computer Guy
Statewide General Insurance Agency (www.swgen.com)

[Yarko Tymciurak]

hehe... I think Robin should send Robin's proposals ;-)

[Robin B]

Should these proposals end up in the google code issues database as
enhancements?

Robin

On Jan 8, 3:45 pm, "Yarko Tymciurak" <yark...@gmail.com> wrote:
> hehe... I think Robin should send Robin's proposals ;-)
>

> > Timothy Farrell <tfarr...@swgen.com>

[Yarko Tymciurak]

Massimo is doing development on launchpad.net/web2py (google code is just a mirror for svn users; sort of a backwards compatibility thing).

You could start by doing a blueprint on launchpad;   if you have more to include, maybe a link to the www.web2pywiki.com

[mdipierro]

I am sorry. I am writing while in the middle of a meeting. Meant
Robin's proposals.

Massimo

On Jan 8, 4:09 pm, "Yarko Tymciurak" <yark...@gmail.com> wrote:
> Massimo is doing development on launchpad.net/web2py (google code is just a
> mirror for svn users; sort of a backwards compatibility thing).
> You could start by doing a blueprint on launchpad; if you have more to
> include, maybe a link to thewww.web2pywiki.com
>