Re: Users authentication and admin interface

> Do you have 'class Admin: pass' or something in your model definition?
>  That should show you the UserProfile under the heading of your
>  application in the main admin interface (for me, that's simply
>  'Users'; not 'Auth'). There you can add a new user, and set the
>  foreingkey to the corresponding Auth user. As well as edit all other
>  extra fields.

Thank you, I have it in my admin.  Now I have 'UserProfile' (user
details) in my admin interface and default users, which administrator
could add while filing form in 'UserProfile'.   Is it professional to
deploy admin application where the user's first name and last name are
optional, and the form doesn't send error when admin forget to write
user's name?

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Users authentication and admin interface

>> Do you have 'class Admin: pass' or something in your model  
>> definition?
>> That should show you the UserProfile under the heading of your
>> application in the main admin interface (for me, that's simply
>> 'Users'; not 'Auth'). There you can add a new user, and set the
>> foreingkey to the corresponding Auth user. As well as edit all other
>> extra fields.
>
> Thank you, I have it in my admin.  Now I have 'UserProfile' (user
> details) in my admin interface and default users, which administrator
> could add while filing form in 'UserProfile'.   Is it professional to
> deploy admin application where the user's first name and last name are
> optional, and the form doesn't send error when admin forget to write
> user's name?

Not sure if you mean that the form should warn you, or that you  
actually -want- the first & last names to be optional. For the latter,  
the Auth class allows the first and last name to be blank, so that  
should work out of the box.
If the former, you could opt to add a first and last name to your  
UserProfile, but requiring them and not letting them be blank; the  
admin form should require them as well then. Then ignore the Auth  
first & last name everywhere in your app, but instead use those from  
your UserProfile. It then doesn't matter whether the Auth fields are  
filled in or not. And I'd guess that the authentication system still  
works, relying on the username and password (but other people will  
know better).
Whether it's professional, well, I guess that depends what you really  
want/like. Eg, there's isn't any field for initials either, so there's  

Re: DateTimeField's 'auto_now_add' only set once with 'edit_inline'

Re: ModelForm: Dynamically change model and fields

This approach works for me in a similar situation:
        import new
        UploadMeta = new.classobj("UploadMeta", (), {
          'model': yourModel,
          'fields': ('yourfield1', 'yourfield2')
          })
        UploadForm = new.classobj("UploadForm", (ModelForm,), {
          "Meta": UploadMeta
          })

In case you're wondering about the practical use case of this...
I use this to read a CSV-formatted file and validate the input rows
one by one before saving to the database.
So, when reading the header line of the file, I dynamically create the
form: the column names in the first row define the fields. For every
following line in the input file I then process it with (simplified):
    try:
      form = UploadForm(dictionary_built_from_the_row)
      form.save()
    except:
      ... process validation errors

My 2 cents: similar use cases for a more dynamic use of ModelForm are
sure around. It would be great if they would be supported in a cleaner
and more intuitive way than currently available.

Johan

On Feb 29, 8:47 pm, Dominik Szopa <dsz... <at> gmail.com> wrote:
> On 29 Lut, 09:28, brian <bros... <at> gmail.com> wrote:
>
>
>
>
>
> > > But this doesn't work, how to pass new _meta.fieldsand _meta.modelin
> > > init method ???
>
> > I am a bit concerned that your use-case for this kind of functionality
> > is not well justified. However, you cannotchangethefieldsin the
> > __init__ method of the form. By the time __init__ is executed the form
> > has already assembled thefields. This is done with the use of a
> > metaclass that dictates how your Form class is built. You need to do
> > some reading on metaclasses (which is an advanced Python topic) before
> > you can accomplish something like this. There can be ways to simply
> > adjust the values assigned to the class inside the class since the
> > class defintion can live anywhere, but it would be wise to understand
> > how all that works.
>
> > Again, I would seriously reconsider your approach and make sure that
> > this type of functionality is critical to your app.
>
> > Here are some handy links:
>
> >http://docs.python.org/ref/metaclasses.htmlhttp://en.wikipedia.org/wi......
>
> Thank you, i'll try to read about metaclasses, thanks for the links :)- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: ModelForm: Dynamically change model and fields

On Sat, 2008-03-01 at 00:48 -0800, johan de taeye wrote:
> 
> This approach works for me in a similar situation:
>         import new
>         UploadMeta = new.classobj("UploadMeta", (), {
>           'model': yourModel,
>           'fields': ('yourfield1', 'yourfield2')
>           })
>         UploadForm = new.classobj("UploadForm", (ModelForm,), {
>           "Meta": UploadMeta
>           })
> 
[...]

> My 2 cents: similar use cases for a more dynamic use of ModelForm are
> sure around. It would be great if they would be supported in a cleaner
> and more intuitive way than currently available.

It's two lines of code! How could it be cleaner??? We moved to a class
style here precisely so that we wouldn't have to keep extending and so
that people could do exactly what you're doing.

There are any number of different things people are going to want to do
with forms. We cannot and should not attempt to cover them all because
Python already support dynamic class creation and you should use that.
ModelForms provide a class structure for one case that is common for
some people: that of mapping a model directly to a bunch of form fields.
It allows some customisation via field ordering and specifying what to
leave out, as well as providing an easy way to add extra methods.

If you want dynamic adjustments, do something similar to what you're
doing and use Python's native support for dynamic class creation. You
might decide you pattern is common enough in your code that it becomes a
helper function. Then you write a helper function and it's cool.

As a side note, your code contains a slight bug. The "new" module
carries some historical baggage and part of that is that new.classobj
only provides you with an old-style class (not one with "object" as a
base). Since newforms are based around new-style classes, it would be
more accurate (and shorter) to create the class using type(). The
differences are subtle, but new-style classes contain a few more methods
than old-style ones and something might well be relying on that.
Normally, it's not an issue, since you inherit from Form when creating
classes in code. But if you're doing it dynamically, you should use the
right object creation function.

Regards,
Malcolm

--

-- 
Everything is _not_ based on faith... take my word for it. 
http://www.pointy-stick.com/blog/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Users authentication and admin interface

>  If the former, you could opt to add a first and last name to your
>  UserProfile

Yes, I did that.  Now I have first name and last name in UserProfile
which is mandatory, and again first name and last name in 'user' which
would stay empty.  Well, this isn't very good, but I don't have any
alternative if I want to use Django default authentication.  Suppose I
can copy entire middleware /django/contrib/auth to my home folder and
change User model to my needs.  Would that work?  Hmm.

Thank you for you help.  :*

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Context Processing and per View Caching

Does per view caching also cache everything in the context
processing?

I have a cached view along the lines of:-

 <at> cache_page(60 * 60 * 24)
def advert_detail_ver2(request,offer_id):

offer = Offer.objects.get(id=offer_id)
#do stuff
return render_to_response(template_name,
{'offer':offer},context_instance=RequestContext(request))

Is the cache holding just "offer" or all the variables?   I have
{{ user }} in the template and this changes with each  user, which
suggests that  the context is not being cached - but I want to be
sure.

Cheers

MerMer
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

RuPy 2008

Hello.

 We invite you to take part in RuPy 2008 - Python & Ruby Conference,
which will take place on 12th, 13th April 2008 at Adam Mickiewicz
University in Poznan, Poland.

This international event is organised for the second time. The
conference is devoted to Ruby and Python programming languages. RuPy
is the only event of this type organised in Central Europe. It is a
great opportunity to broaden your knowledge, discuss new trends
with world class specialists and establish priceless international
contacts.

You may find more details on the conference website: http://rupy.eu/

See you at RuPy 2008,

--
Rafal bluszcz Zawadzki
http://web-dev.pl
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: DateTimeField's 'auto_now_add' only set once with 'edit_inline'

Thanks, that is indeed one step closer to what I want. The problem
that now arises is that this way the field shows up in the admin
interface. I don't want users to fill it out, the default value is
fine.

> Instead of using auto_now_add, try setting default=datetime.now.  I think
> that will accomplish the same thing and work properly when you edit the
> objects.
>
> Karen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Re: Is there a ModelChoiceField() HTML widget that accepts typing?

Check this out: http://code.djangoproject.com/wiki/AJAXWidgetComboBox

If it doesn't suit your needs you can make your own widget and then
tell your form field to render itself using your custom widget.

Here's an OK example of making a custom widget:
http://code.djangoproject.com/wiki/CustomWidgetsTinyMCE
The main issues I have with this example are 1) you can't use a
javascript function object as an element in the settings, and 2) the
inline HTML. Ick. I think it would be nicer to create a template
containing the HTML for the widget, then pass in a Context with all
the configuration data. Good example of that over here:
http://www.hoboes.com/Mimsy/?ART=609 but it get's a bit complex as he
is deailing specifically with a multiwidget.

After you've coded up your own, you can tell CharField to use it by
doing something like:

from django import newforms as forms
class MyForm(forms.Form):
    combobox = forms.fields.CharField(widget=MyCustomWidget())

On Feb 29, 11:24 am, Adam Stein <a... <at> eng.mc.xerox.com> wrote:
> Want to see if something exists so I don't recreate it.
>
> For years, I've been using a JavaScript utility called "HTML CombBox" by
> CS Wagner.  This provided ComboBox functionality for HTML.  That is, you
> can have a <select>...</select> list with the added functionality that
> you can type into the select box (useful if what you want isn't on the
> list).
>
> Now that I'm using Django, I need that functionality again.  Does
> anything like this exist already?
> --
> Adam Stein  <at>  Xerox Corporation       Email: a... <at> eng.mc.xerox.com
>
> Disclaimer: All views expressed
> here have been proved to be my own.  [http://www.csh.rit.edu/~adam/]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to django-users <at> googlegroups.com
To unsubscribe from this group, send email to django-users-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---