> > If you can look up the function object yourself (e.g., using getattr() > on the proper module), you don't need eval(). You just call the > function object directly.
Ah. but of course, getattr(). That makes sense. On Fri, Aug 27, 2010 at 1:06 PM, Mike Orr <[email protected]> wrote: > On Fri, Aug 27, 2010 at 12:49 PM, Wojtek Augustynski > <[email protected]> wrote: > > Thank you for your reply, Mike. > > I'm building an EDI Interface. The users will come in and define the > > template layout and formats, pickup configurations, validations, actions > to > > take on validation failures, conversion, and delivery configurations. > > So what I had thought to do was store the actions in the EDI chain. e.g. > > step 1 - pick up, step 2 validate, etc. etc. > > I was working late last night and hadn't thought it through, but I guess > the > > correct way would be to keep those functions out of the controllers and > have > > separate modules for them (which I can pickle if need be). Basically the > > table would then just store the string descriptions of the action and the > > actual function call in another property. > > If I did store the function name as a string in a look-up scenario, I > would > > still need to eval the constructed string right? > > If you can look up the function object yourself (e.g., using getattr() > on the proper module), you don't need eval(). You just call the > function object directly. > > If you really want to just call an action, which doesn't need anything > outside its arguments, doesn't use request/response/session/url, you > could store the module name, controller name, and action name. Then > you'd instantiate it the same way Pylons does. For that, you can > leverage the methods in PylonsApp (in pylons.wsgiapp) and > WSGIController (in pylons.controllers.core -- parent class of > BaseController). > > controller = app.find_controller(controller_name) > # Uses the controller search path defined in your application > > app.setup_app_env and app.register_globals may be useful too. > > > At any rate, maybe a solution would be like an Observer pattern? I guess > I > > would still need to have some sort of evaluation to publish but It would > be > > cleaner though, I'd think, right? > > Er, I'm not sure what would be the observer and what would be the > observed. Maybe. But wouldn't that mean setting up all possible > actions beforehand in case they get invoked? That seems like a lot of > infrastructure for what's simply a lookup/instantiate/call problem. > > -- > Mike Orr <[email protected]> > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<pylons-discuss%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
