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
-~----------~----~----~----~------~----~------~--~---

Reply via email to