On Friday 09 June 2006 23:50, binjured wrote: > 1) How robust is Django? Take for instance the User class. Say I > wanted to add the field "favorite_color" and have it editable in the > admin interface and work with all applicable functions, is that > possible? What if I need to connect to a Soap server after a > successful local login, send some commands, get a response, and set a > cookie? Can things like this be done without rolling my own > completely custom User class (this could have only to do with the > login model, I don't know)?
This sounds like you are really asking 'how *flexible* is Django?'. With regards to adding fields, see: http://code.djangoproject.com/wiki/ExtendedUserModel As for logging in, it depends on what you mean -- are you talking about the admin? If you are talking about your own logging in functionality, you can do whatever you want. I imagine you could write a 'view middleware' to implement this otherwise. > 2) Is there any way to make a portable Django app, i.e. the user > getting the app doesn't have to install Django to their system? This > isn't a huge deal because I can still develop our portable apps in > PHP, but it would be neat ;) You don't have to *install* Django into system directories, if that is what you are asking - it just has to live somewhere on your python path. This is the way I always use it. > My biggest problem with "heavy" frameworks like Django, regardless of > the language, is customizability. Usually they do certain things a > certain way extremely well, but if you try to deviate from that too > much then you're in trouble. I am tired of reinventing the wheel in > PHP, but at least when reinventing the wheel we decide exactly what > it looks like ;) Django's components are in general very loosely coupled, so you are not forced into doing everything the Django way. You can use a different template engine, a different ORM (if you don't want the admin), a different URL despatching mechanism (by creating a single item in urlconf that goes to your custom function). Even the admin has various hooks to allow overriding (e.g. you can provide different templates, you can even provide different view functions using additional urlconf entries), but it doesn't contain every single hook that someone somewhere would like it too -- it would just become crazy. There is some intrinsic inflexibility in the models that the admin depends on i.e. User, Group, Permission, ContentTypes -- these are models that are not only managed by the admin, but that the admin uses itself -- it's impossible not to depend on them in some way. There are SoC plans to make authorisation more modular though, or at least more capable. Luke -- The probability of someone watching you is proportional to the stupidity of your action. Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~---------~--~----~------------~-------~--~----~ 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@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users -~----------~----~----~----~------~----~------~--~---