Amazon shows it as being released on Oct 22:
http://www.amazon.com/Professional-Python-Frameworks-Programming-Turbogears/dp/0470138092/ref=pd_bbs_12/104-9039171-6407132?ie=UTF8&s=books&qid=1187871082&sr=8-12
On 8/23/07, Ramdas S <[EMAIL PROTECTED]> wrote:
> Has someone seen this book?
>
> http:
Amazon shows that the book on Django will be published on March 26th
which is 1 1/2 weeks away. Does anyone know if that date is still
valid?
I'm anxiously waiting to order it.
Derek
--~--~-~--~~~---~--~~
You received this message because you are subscribed to t
I just moved to Dreamhost so I can start to work with Django as my
previous host wouldn't support it. I'd be curious to know if the
general concensus is that the speed difference is a "fcgi vs flup"
issue, or if there could be other factors at play. E.g.:
- Maybe the Dreamhost servers are more
> I took a look and traced the bottleneck to lines 125 and 127 in
> viewPlan.html. The problem was as Malcolm hinted -- you're
> doing a foreign key lookup ({{ workout.workoutType.name }})
> for each iteration of the for loop.
>
> I changed line 55 of views.py to use select_related() instead
> of
The app I have is pretty simply as I'm just beginning so I didn't
bother to try and make it any smaller. I've ZIPped the entire project
directory and it can be downloaded here:
http://www.roadtoboston.com/media/RoadToBoston.zip
I have a batch file called runserver.cmd that would run the local t
> It may take a couple more days to work this out. It's only been 48 hours
> since you posted the original problem and less than 24 hours since you
> posted a portion of your code that causes the problem. It is very
> unusual behaviour for Django; the templating code is normally very fast,
> but t
Thu, 2007-02-08 at 20:21 -0600, Derek Lee-Wo wrote:
> > > One more idea: It looks like you're doing foreign-key lookups in the
> > > rendering.
> > >
> > > {% for workoutWeek in workoutWeeks %}
> > > ...
> > > {% for workoutDay in workout
I incorporated ReportLib to generate a PDF of the same data that I'm
trying to display on the web and the PDF gets created in about 2
seconds as compared to the template via Django which is taking 16-18
seconds.
Both routines share a common method that does all the data retrieval
and manipulation
> I did as you suggested and the call template.render() is where the
> 16-18 seconds are being spent. My next step is to add some timings to
> django.template.NodeList.render as you suggested.
I added a timing statement at the entrance and exit of render() and
just inside the foreach loop. I go
> You'll want to do something like this, timing each line:
>
> from django.template import loader
>
> source, origin = find_template_source('your_template_name')
> template = get_template_from_string(source, origin, 'your_template_name')
> template.render(your_context)
>
> --
>
> It ma
> > My app does a bunch of database queries and processing and when I
> > timed that part, it all completes within 0.5 seconds, but the call to
> > render_to_response() takes 18 seconds. Needless to say, the end-user
> > experience isn't acceptable.
>
> I don't know if you are aware about the fac
I just started working with Django about a week ago and I love it. I
was able to get my first webapp up and running faster than I have with
various other technologies I've used in the past.
One problem I'm having though is the speed of the template rendering.
That is, the call to render_to_respon
12 matches
Mail list logo