>For instance with manipulators, after magic-removal, it will be
>elementary to over-ride the Model.AddManipulator(), and
>Model.ChangeManipulator(pk). So you could then apply RuleDispatch in
>your own model, and not need it built-in to Django at all.
You can only override methods that are defin
On 1/23/06, Brant Harris <[EMAIL PROTECTED]> wrote:
>
> For instance with manipulators, after magic-removal, it will be
> elementary to over-ride the Model.AddManipulator(), and
> Model.ChangeManipulator(pk). So you could then apply RuleDispatch in
> your own model, and not need it built-in to Dj
Ian went over the RuleDispatch at the ChiPy meeting a few months back.
It's a very interesting technique, certainly. But it's usage is
limited in scope, and I think dangerous in appeal. In this case, I
think it's better to apply it at the application level, rather than in
Django itself. Rather
On 1/23/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> On 1/23/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> > Rather than reserving attribute names in a model instance
> > (modelinstance.objects returns a Manager) we could use a combination
> > of generic functions and a simple type of a
On 1/23/06, Joseph Kocherhans <[EMAIL PROTECTED]> wrote:
> Rather than reserving attribute names in a model instance
> (modelinstance.objects returns a Manager) we could use a combination
> of generic functions and a simple type of adaptation.
What real-world problem would this solve?
Adrian
--
This may be rather confusing for those who aren't familiar with Philip
Eby's RuleDispatch package. Feel free to ask questions. I'll answer
them as best I can.
Rather than reserving attribute names in a model instance
(modelinstance.objects returns a Manager) we could use a combination
of generic
