Re: Dreamhost, Django and MySQL server connection

[Edgars Jekabsons]

OK, posted a patch agaist trunk (revision 2307)
http://code.djangoproject.com/attachment/ticket/463/mysql_rev2307.diff

--
Edgars

Re: Dreamhost, Django and MySQL server connection

[Edgars Jekabsons]

Hi Kieran,

I posted a working patch against Django release 0.91 on the same ticket
http://code.djangoproject.com/ticket/463

HTH,
Edgars

Dreamhost, Django and MySQL server connection

[Edgars Jekabsons]

Does anyone else who uses Dreamhost has problems with MySQL connection
going away?

The project I suggested hosting there is not even inproduction yet, but
we get MySQL server errorsa lot (a few times a day). Sometimes it's
just Django error 500, but other times I get a Python traceback screen.

Is it just plain unlucky me and an unreliable MySQL server on Dreamhost
or I should have used something more robust than the setup described in
http://wiki.dreamhost.com/index.php/Django?

TIA,
Edgars

Re: custom admin view for edit_inline object

[Edgars Jekabsons]

On Thu, 09 Feb 2006 03:13:04 +0200, Colleen Owens <[EMAIL PROTECTED]> wrote:


Again, what I'm trying to do is customize the way inline-edited objects
are displayed for one of my applications (without affecting any other
application).

First I changed line 52 of
django/contrib/admin/templates/admin/change_form.html to read:

{% for related_object in bound_manipulator.inline_related_objects %}{%
block related_object_display %}{% edit_inline related_object %}{%
endblock %}{% endfor %}

(i.e. I added the block and endblock tags).

Then I created another change_form.html file in my template directory
that simply contains:

{% extends "admin/change_form" %}
{% block related_object_display %}{% include
"admin/news/edit_news_inline" %}{% endblock %}

admin/news/edit_news_inline simply points to my custom template that
contains the code I want. I'll customize the url rewrite to point to
the default change_form for all applications, but my news application
will point to my new change_form.

Does this seem like a reasonable way to do this? I still don't quite
have a handle on all this so sometimes I feel like I'm doing things in
a very convoluted way.



There is a simple way to create special admin templates for one object.
See  
http://code.djangoproject.com/wiki/NewAdminChanges#Adminconvertedtoseparatetemplates


HTH,
Edgars

Re: possible to validate a subset of a model's fields?

[Edgars Jekabsons]

On Tue, 31 Jan 2006 02:00:53 +0200, Oliver Rutherfurd  
<[EMAIL PROTECTED]> wrote:




Hi Amit,

On 1/30/06, Amit Upadhyay <[EMAIL PROTECTED]> wrote:

On 1/31/06, Oliver Rutherfurd <[EMAIL PROTECTED]> wrote:
> The use case for this is a long registration process, where different
> data points from individual models are split across multiple pages.
> The application needs to save data collected after every step, so the
> user doesn't have to start from scratch if they leave the site and
> return later.  As a silly example, let's say that name is collected on
> page 1, phone # on page 2.  Both are required and both live in a
> 'person' table -- and I want to save the model after page 1.

I would recommend creating your own FormManipulators, one for each page.
Validate page level manipulator and save the content in  
request.session, and
when you are done on the last page, pick out all the saved temproary  
states

and insert it in the database.


Thanks for the suggestion, but saving to the db after every page is a
requirement of the app.  If someone fills out a page and comes back a
week, or even a year later, everything they previously entered should
be in the db.


Well put blank=True in model field descriptions, use custom  
FormManipulators and save the data in database after each page :)


HTH,

Edgars Jekabsons

Re: what is the best way to capture the subdomain and send it to a view?

[Edgars Jekabsons]

On Wed, 04 Jan 2006 16:31:34 +0200, Le Roux <[EMAIL PROTECTED]> wrote:



Thanks. I'll do that. It just feels like that type of thing should
happen outside of the view (and come to the view as a parameter). The
other thing is that _all_ my views will need this and to me that just
feels a bit dirty. I guess it is probably the best way, though.


You can always rewrite user.host.com to host.com/user/ in Apache and pass  
it to Django.