Either that, or use a custom manipulator and override the save method
there. Depends on if the processing will always need to be done when
saving or just done with the form data. If it's the form data, probably
best to put it in a manipulator. If you want, just create a manipulator
and override it
mthorley:
I think you just need to override the save() method of your model.
You can do all the processing you need before it's saved.
Corey
On Sep 5, 2006, at 10:21 AM, mthorley wrote:
>
> Thanks for the tip Nate!
>
> Does any one know what method receives the data from the form when it
>
Thanks for the tip Nate!
Does any one know what method receives the data from the form when it
is submitted? I tried models.Field.get_db_prep_save but that doesn't
seem to be working. I need to process the form data before it is passed
off to the database for saving.
--
mthorley
--~--~
On Fri, Sep 01, 2006 at 10:21:38AM -0700, mthorley wrote:
> Table creation is handled by core.management. In it, a lookup is
> preformed where it loads the dict DATA_TYPES (or something like that)
> from db.backends..creation. Then it attempts a key matching the
> field class name of each field in
I found it! There is a mapping of Field types in
db.backends..creation where yourdb is mysql or postgres or what
ever. I found it by grepping for CREATE in the django source.
Table creation is handled by core.management. In it, a lookup is
preformed where it loads the dict DATA_TYPES (or somethin
> Oh, I see where you're going with it. Just hide the interface from the
> user. That's a great idea, I still need a way though to enforce it so
> that carefully crafted POST requests don't allow unauthorized users
> from breaking things.
That's true, maybe using the custom manipulator would han
Chris Long wrote:
> Maybe, but if you do it in the template then it won't even show the
> option to the user and you'll avoid the trouble of getting the error
> from the save method to be displayed to the user.
Oh, I see where you're going with it. Just hide the interface from the
user. That's a
> Thanks, that's a neat trick, though from the surface I'm not 100% sure
> it will do what I'm thinking. I'll have to investigate further. My
> intuition tells me I need to do the checks in the model, maybe with a
> save hook, not in the template; but I may be off on that.
Maybe, but if you do i
Chris Long wrote:
> For the permission checking, See:
> http://code.djangoproject.com/wiki/ExtendingAdminTemplates for more
Thanks, that's a neat trick, though from the surface I'm not 100% sure
it will do what I'm thinking. I'll have to investigate further. My
intuition tells me I need to do t
Howdy,
For the permission checking, you could override the admin template and
add auth checking in there for the various permissions you want to
check for. See:
http://code.djangoproject.com/wiki/ExtendingAdminTemplates for more
details on this. And in the auth documents there is info on how to
a
Greetings,
I am trying to do a few advanced (from my point of view) customizations
to the built in admin. I have searched around but haven't found the
answers I'm looking for. If any one can help, or point me to a resource
that can, I'd be forever greatful. (or at least really grateful ;)
More E
11 matches
Mail list logo
