From: Jason H. <ja...@pe...> - 2003-11-26 22:24:09
|
Hi all, In some of my servlets I have dynamic actions - by this I mean actions which may or may not be permissible, depending on the logged-in user. So my code might look like: def actions(self): alist = super(MyServlet, self).actions() # get actions from super if self.user().playsRole('admin'): alist.append("deleteFrobber") return alist Nothing in the Webware documentation led me to think that this was not allowed, but I've recently discovered that Page caches a list of actions in the Page._actionSet() method: def _actionSet(self): """ Returns a dictionary whose keys are the names returned by actions(). The dictionary is used for a quick set-membership-test in self._respond. Subclasses don't generally override this method or invoke it. """ if not hasattr(self, '_actionDict'): self._actionDict = {} for action in self.actions(): self._actionDict[action] = 1 return self._actionDict This method is marked as "private utility" and the only code which uses it is this snippet from Page._respond(): # Check for actions for action in self.actions(): if req.hasField('_action_%s' % action) or \ req.field('_action_', None) == action or \ (req.hasField('_action_%s.x' % action) and \ req.hasField('_action_%s.y' % action)): if self._actionSet().has_key(action): self.handleAction(action) return It appears that the _actionSet() caching was added for performance reasons back when "old style actions" were used. However in the above code I don't think the "if self._actionSet().has_key(action)" test could ever fail because that test is enclosed by the "for action in self.actions()" loop. If the action is in self.actions(), it's going to be in self._actionSet() too. So I'd like to remove the "if self._actionSet().has_key(action)" test from the above snippet, seeing as it doesn't seem to be of any benefit anyways, which will allow use of dynamic actions. Does anyone see a problem with doing this? I wanted to check in before I proceed just in case I've overlooked something... -- Jason D. Hildebrand ja...@pe... |