Does the following help :-
URL :- http://lmap.co.nr/Amazon1.htm
In the tree, one can browse amazon catalogues based
on the browse id. On reaching the item level (marked
with red dots) one can click on it to view details
such as price, image etc.
Eugene Lazutkin wrote:
> Mochikit is an
On 11/14/05, hugo <[EMAIL PROTECTED]> wrote:
> Actually the only thing I can think of that would be good if django had
> it, would be a REST style API to access model stuff that automatically
> will be returned in JSON format. That would allow JavaScript code to do
> easy database queries without
Lets make it happen. Who wants to be involved? What form of interaction is
preferred: IRC, e-mails, anything else?
AFAIK, Dojo is built on bones of many projects and directly sponsored by
real life applications like JotSpot (http://www.jot.com). Guys from WebWork
On 11/14/05, Maniac <[EMAIL PROTECTED]> wrote:
> But I think this whole approach is wrong and should not be supported.
> There are certain reasons behind separating server and client part and
> wishing to break this barrier smells like a bad design to me. If Django
> will make such things easy
"Maniac" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> But I think this whole approach is wrong and should not be supported.
> There are certain reasons behind separating server and client part and
Care to share these reasons or provide a link to reasons you support?
Hi,
>I think if I don't get new-admin merged soon, the maintenance will start
>to be a headache, and it will block work on trunk. Also a lot of people
>are using it for a development branch.
+1 from me, as I already use it in my CMS testbed system for a while
and it doesn't produce more
Hi,
>Hence, I plead with the proponents of "Ajax support:" Please >show
>concrete examples of what you want. Enlighten us.
Actually the only thing I can think of that would be good if django had
it, would be a REST style API to access model stuff that automatically
will be returned in JSON
"Robert Wittams" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> I've got to say, this plan sounds like it would lead to *another*, half
> featured AJAX library. Do we really want to reimplement everything? It
> seems like the world needs fewer JS toolkits, not more...
>
> Lets
I have recently discovered the joy of .pth files. I respectfully submit
that having django-admin create one of these for you as part of running
startproject would be a cleaner (and more cross-platform) solution than
what you propose here.
Implementation details aside, +1 for the idea!
Hey djangonistas,
I think if I don't get new-admin merged soon, the maintenance will start
to be a headache, and it will block work on trunk. Also a lot of people
are using it for a development branch.
So, please bang on it, peruse the big diff, and merge it when you are
happy...
Functionality
it cheats and there is a 'REALLY_LAST' and a 'REALLY_FIRST' ;-)
most people just use the pre/post dependancies, and only uses the
first/last thing when it has to do with hacks to do set certain
variables before something is run and some of the hooks are set to run
until someone answers it.
On Mon, 14 Nov 2005 16:57:10 -0600 Jacob Kaplan-Moss wrote:
> 1. There's no way to set the order of the response middleware
> without changing the order of the request middleware. So if you've
> got a middleware that needs to be the first on both request and
> response, you're screwed.
You
James Bennett wrote:
> On 11/14/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
>>1) Let's keep different forums separate. I hope you responded to those
>>unnamed guys in the IRC channel.
>>2) My car has an integrated CD-player. Does it mean it is "in the core"? I
>>respectfully disagree with
On Nov 14, 2005, at 5:05 PM, Ian Holsman wrote:
you might want to implement something similar to what apache2 did with
their hooks.
it sounds pretty complex, but in reality you hardly need to use all
the options.
1. define when the middle ware will be run .. FIRST, MIDDLE, or LAST.
2.
On Nov 14, 2005, at 4:45 PM, Ian Holsman wrote:
I was also thinking of something a whole lot more simplistic as well.
javascript-enabling some of the validators.
I was planing on this being one of the web services views -- a
"validate" view that you would pass a new or modified object into
Hey folks --
As some have pointed out in the past, there are some potential
pitfalls in the current way the middleware API works. As it stands
now, MIDDLEWARE_CLASSES is implemented as a stack: the middleware
bits are called in order on the process_request and process_view
phases, and
This is a good conversation, and I hope it continues.
Here are some thoughts, which I've brought up a number of times over
the past couple of months and remain unresolved.
Django is all about *actual tools that get actual stuff done* -- not
about buzz words, or academic noodling, or "let's make
I don't recall anybody proposing "AJAX in the core". Clearly Ajax should be
an optional feature. While Ajax is generating a lot of buzz lately causing
adverse reaction in non-marketing people, don't overlook it is potential to
improve usability of web sites. Ajax can be abused, but let's be
"""
It seems to me that the original question here is based on a
misunderstanding;
"""
James, you made a good point.
So, when we rate it (1 best):
1 FCGI
2 mod_python
3 SCGI ?
4 Twisted
X runserver (development only)
X+1 CGI (probably performance worse than runserver)
Is it OK
I want to second the idea of a config variable for saving the session
on each request. I got stuck on a bug where my sessions never seemed
to be saved. I'm creating an shopping engine in django, and need to
store a lot of data in a session, and so I wanted to partition the data
a bit for better
On 11/14/05, limodou <[EMAIL PROTECTED]> wrote:
> I want to know if there is easy way to create form?
You might want to look over this:
http://www.djangoproject.com/documentation/forms/
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
On 11/14/05, Stephen Rainey <[EMAIL PROTECTED]> wrote:
> I agree with you that it's pure marketing fluff and I guess you see that
> was my point. It just got me to thinking when I was reading about
> developer adoption. I do like your lightweight ideas. It might be good
> to do something rather
On 11/14/05, Radek Svarz <[EMAIL PROTECTED]> wrote:
> I believe that PythonistL did not asked about running it on CGI. He asked to
> run it on the shared webhosting. And noted some issues.
Django runs perfectly well on shared hosting. Plenty of hosts out
there offer Python/FCGI which is
# I believe that PythonistL did not asked about running it on CGI. He
# asked to run it on the shared webhosting. And noted some issues.
Right: he didn't ask about running it on CGI; it was just stated that
running it on CGI is his only option, and it's such a nasty one that
he ought to consider
I believe that PythonistL did not asked about running it on CGI. He
asked to run it on the shared webhosting. And noted some issues.
There is no reason to think about using CGI at all as many of you noted.
I believe that there is / will be shared webhosting with mod_python /
fastcgi support. (At
> ( I guess that from this:
>If a Python programmer has a good webhosting ( = share webhosting)
>company, he is happy with, why he should find another one only to
>install Django?)
Because he wouldn't be anymore happy with his webhosting, if he is
forced to run Django under CGI, as that is dead
Yes, I agree with Radek.
For a wide spreading of Django,
a support for share webhosting ,will be very, very important.
( I guess that from this:
If a Python programmer has a good webhosting ( = share webhosting)
company, he is happy with, why he should find another one only to
install Django?)
# Simon, you are saying that FastCGI serves worse than mod_python?
He said "CGI", which is not the same as FastCGI.
--
Jonathan Daugherty
http://www.parsed.org
On 14 Nov 2005, at 16:24, PythonistL wrote:
So, would it be possible to make the installation easier also for
those who use share webhosting ?
Maybe we should document Django-as-CGI, horrible though the
performance will be. We can have a big performance disclaimer
recommending this as
Hi,
I have been playing with Django for some time and I really like it.
Very few lines of code can make great things.
However, what seems to me as a big limit in Django using is a quite
difficult installation.
Here it is what I mean:
I use a share webhosting, (http://www.imhosted.com). I have
OK, let me mix it:
1. Django guitar core
2. Django ORM beats
3. Django singing templates
4. Django piano admin
You have it novel and self-explanatory, too :)
Radek
On 11/14/05, Jonathan Daugherty <[EMAIL PROTECTED]> wrote:
# 1. Django guitar## 2. Django beats## 3. Django singer## 4. Django
Hi,
>> I'm presenting Django to a crowd of 200+ people on Thursday as part
>> of the London Web Developer Frameworks evening ( http://
>> blog.unixdaemon.net/cgi-bin/blosxom.pl/2005/10/27 ). I'm putting the
>> slides together now and I want to do one detailing the various high-
>> level
# 1. Django guitar
#
# 2. Django beats
#
# 3. Django singer
#
# 4. Django piano
Novel, for sure, but wouldn't people have a hard time remembering
which is which?
--
Jonathan Daugherty
http://www.parsed.org
On 11/14/05, Tim Keating <[EMAIL PROTECTED]> wrote:
> This is attached to ticket #593
> (http://code.djangoproject.com/ticket/593). The patch adds a "match"
> lookup_type that gets converted into a where clause entry for a
> full-text search. I'm not convinced this is a good long-term solution,
>
I want to know if there is easy way to create form?
I found atocha is simple, if I need borrow it and use it in django.
http://furius.ca/atocha/
--
I like python!
My Blog: http://www.donews.net/limodou
NewEdit Maillist: http://groups.google.com/group/NewEdit
When you named Django after the great jazz muzician, why don't you name
its components similarily? I mean something like:
1. Django guitar
2. Django beats
3. Django singer
4. Django piano
That would be much more "cool" for the public.
Radek
On 14 Nov 2005, at 06:06, Tom Tobin wrote:
A bit stumped here . . . Is there a recommended convention for
repeating blocks within a template? e.g., I have a paginated
object_list generic view, and I want to repeat my pager code (i.e.,
"back", "next") at both the top and bottom of the list
37 matches
Mail list logo
