Hi,
I have some experience using decorators in exact way -- I agree it can be
somewhat tricky. I am posting an example of the way I've usually done it -- it
may be helpful (if not, disregard my message :)
class Routing(object):
routes = {}
@classmethod
def addroute(cls, route):
def wrap(handler):
print "Registering handler %s for route %s"%(handler,
route)
cls.routes[route] = handler
return handler
return wrap
class View(object):
@Routing.addroute(r'^/blog/post/$')
def dosomething(self, *args, **kwargs):
pass
Thanks,
Ian
On Sep 5, 2011, at 11:14 AM, Jacek Furmankiewicz wrote:
> Hi Glyph,
>
> I looked at your suggestion, but unfortunately the implementation is very
> complex, if not impossible.
>
> The main problem is that
> a) a class method with a decorator "forgets" its class, so it's impossible
> from the decorator which class it belongs to.
> The function has not been bound to a class yet when the decorator is called
> for the first time, so there is no way for it to notify the containing class
> that this function defines a route for it
>
> b) is is next to impossible for a class to scan its own function and find
> their decorators. I've seen some hacks on StackOverflow
> where it actually parses the source code, but that is an ugly hack to say the
> least (and probably prone to many bugs)
>
> In general, it seems decorators on class methods are missing such crucial
> functionality as finding out which class the method belongs to.
> Sort of a key requirement, if you ask me (at least after lots of experience
> with Java or .Net reflection, where getting this sort of info is trivial).
>
> if you have any suggestions on how to accomplish your recommendation, I would
> greatly appreciate it.
>
> The decorator in question that I would need to take out of the CorePost class
> and make it a standalone function looks like this:
>
> def
> route(self,url,methods=(Http.GET,),accepts=MediaType.WILDCARD,produces=None,cache=True):
> """Main decorator for registering REST functions """
> def wrap(f,*args,**kwargs):
> self.__registerFunction(f, url, methods, accepts, produces,cache)
> return f
> return wrap
>
> it's obtaining the reference to 'self' when it is not a class method any more
> is the problem. Not sure how to get around it.
>
> Cheers,
> Jacek
>
> On Sun, Sep 4, 2011 at 12:01 AM, Glyph Lefkowitz <[email protected]>
> wrote:
>
> On Sep 3, 2011, at 8:28 PM, Jacek Furmankiewicz wrote:
>
>> Any feedback is welcome
>
> Hi Jacek,
>
> Great to see more development going into Twisted-based web stuff! :)
>
> However, I do have one question. Maybe I'm missing something about the way
> Flask does things, but it seems very odd to me that the decorators you're
> using are applied to global functions, rather than instances of an object.
> For example, instead of:
>
> app = CorePost()
> ...
> @app.route("/validate/<int:rootId>/schema",Http.POST)
> @validate(schema=TestSchema)
> def postValidateSchema(request,rootId,childId,**kwargs):
> '''Validate using a common schema'''
> return "%s - %s - %s" % (rootId,childId,kwargs)
>
> You could do:
>
> class MyPost(CorePost):
> @route("/validate/<int:rootId>/schema",Http.POST)
> @validate(schema=TestSchema)
> def postValidateSchema(self,request,rootId,childId,**kwargs):
> '''Validate using a common schema'''
> return "%s - %s - %s" % (rootId,childId,kwargs)
>
> This would allow for re-usable objects; for example, rather than having a
> "blog article create" API (sorry for the uninspired example, it's late) for
> your entire site, you would have a "article create" API on a "Blog", which
> would enable you to have multiple Blog objects (perhaps with different
> authors, in different permission domains, etc). This would also make
> re-using the relevant objects between different applications easier.
>
> In other words, global variables are bad, and this looks like it depends
> rather heavily on them.
>
> Any thoughts on this? Am I missing the point?
>
> Thanks,
>
> -glyph
>
>
> _______________________________________________
> Twisted-web mailing list
> [email protected]
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
>
>
> _______________________________________________
> Twisted-web mailing list
> [email protected]
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
