Simon Willison wrote:
>
>
> On 17 Nov 2005, at 23:04, Christopher Lenz wrote:
>
>> I don't agree, at least for the common cases such as validating
>> emails, URLs, date/time fields etc. It really shouldn't be necessary
>> to call back to the server for trivial and/or common validation task
Let me present my half-cooked view of the layers.
I don't care how many layers we are going to have in
implementation, I care for the final layer --- actual use of Ajax in templates.
RPC is not a final layer for me, because I suspect that majority of user will
need end user functionality,
There is a well know effect related to the light speed limit. :-) Basically
it adds some constant delay to all packets. This delay depends on physical
wire distance between client and server. Even if you have infinite
bandwidth, you will still experience delay. Retransmissions of packets and
t
On 11/18/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
I don't care how many layers we are going to have in
implementation, I care for the final layer --- actual use of Ajax in templates.
RPC is not a final layer for me, because I suspect that majority of user will
need end user function
Let me present my half-cooked view of the layers.
I don't care how many layers we are going to have in
implementation, I care for the final layer --- actual use of Ajax in templates.
RPC is not a final layer for me, because I suspect that majority of user will
need end user functionality,
There is a well know effect related to the light speed limit. :-) Basically
it adds some constant delay to all packets. This delay depends on physical
wire distance between client and server. Even if you have infinite
bandwidth, you will still experience delay. Retransmissions of packets and
techn
On 18 Nov 2005, at 19:08, hugo wrote:
Please not AJAX-only - we do still want to validate on POST, too, as
the user might just have JavaScript disabled or is using IE with
settings that don't allow the XmlHttpRequest object ...
That should go without saying - server-side validation will alwa
>If I get some spare time soon I think I'll build the Ajax-only
>validation thing as a proof of concept. I'm willing to bet that the
>performance difference between it and pure client-side validation
>will be imperceptible in most cases. If it's noticable and obvious
>that the user experience woul
On 17 Nov 2005, at 23:04, Christopher Lenz wrote:
I don't agree, at least for the common cases such as validating
emails, URLs, date/time fields etc. It really shouldn't be
necessary to call back to the server for trivial and/or common
validation tasks.
I don't understand why not. It's
Here are my half cooked thought on the issue.On 11/18/05, Wilson Miner <[EMAIL PROTECTED]
> wrote:
I think we should be as toolkit-agnostic as we are
templatesystem-agnostic and ORM-agnostic. We deliver one with Django,and all Django code builds on the delivered ones. But we don't enforcethose on
hugo wrote:
> Sure, people won't be able to use all aspects of
> Django when switching toolkits - but that's the same with ORM and
> template system, you just can't use all aspects of Django when
> switching them to SQLObject or Cheetah.
>
Exactly ;-)
> > I think we should be as toolkit-agnostic as we are
> > templatesystem-agnostic and ORM-agnostic. We deliver one with Django,
> > and all Django code builds on the delivered ones. But we don't enforce
> > those on users, if they want to use something else.
>
> +1 - well put
+1 too.
--
Pedro
Inline.
"Antonio Cavedoni" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]
>
>along with it. We're in 2005, and we *know* that some people turn JS off
>on purpose, use browsers where JS support sucks, or are disabled
I specifically track js settings of all people who come to my si
Am 17.11.2005 um 23:29 schrieb Antonio Cavedoni:
On 17 Nov 2005, at 11:51, Christopher Lenz wrote:
While there are definitely many types of validations that can't be
performed on the client side, calling back to the server just to
check whether e.g. a text-input is empty is overkill IMO. The
Hello everyone,
first post on the list, I’ll be introducing myself at the bottom of
this message.
On 17 Nov 2005, at 11:51, Christopher Lenz wrote:
While there are definitely many types of validations that can't be
performed on the client side, calling back to the server just to
check wh
I think we should be as toolkit-agnostic as we are
templatesystem-agnostic and ORM-agnostic. We deliver one with Django,and all Django code builds on the delivered ones. But we don't enforcethose on users, if they want to use something else.
+1 - well put
On 11/17/05, Bill de hÓra <[EMAIL PROTECTED]> wrote:
Turn it around. Which of the _javascript_ stacks is working now, or iswilling to work, to make it kick ass with Django?I won't speak for him, but I was talking last night to Alex Russell, of Dojo, and he said that he'd tried to talk to the Django
Inline.
"Christopher Lenz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> I'd prefer a hybrid approach, where simple javascript validation checks
> are generated, and the others are performed via AJAX callbacks.
+1.
Well-known type validation and simple checks can be (and sh
David Ascher wrote:
>
>
>
> Goofy idea: use the Python logic to generate JS code to do clientside
> validation based on the model-specified constraints. Detailed specification
> and implementation are left as an exercise to the reader. ;-)
>
Scarily:
http://codespeak.net/svn/pypy/dist/pypy/t
Robert Wittams wrote:
> Wilson wrote:
>
>>no matter which framework gets bundled (or if anything gets bundled
>>at all)
>
>
> This is the sticking point. I just have no idea how we add rich
> functionality to the bundled apps without either
>
> a) Picking a toolkit to bundle
> b) Making some h
Am 17.11.2005 um 10:07 schrieb Simon Willison:
On 17 Nov 2005, at 05:48, David Ascher wrote:
Goofy idea: use the Python logic to generate JS code to do
clientside validation based on the model-specified constraints.
Detailed specification and implementation are left as an exercise
to the
On 17 Nov 2005, at 05:48, David Ascher wrote:
Goofy idea: use the Python logic to generate JS code to do
clientside validation based on the model-specified constraints.
Detailed specification and implementation are left as an exercise
to the reader. ;-)
Here's a concept for form validat
I don't think it's goofy idea. Actually it is kind of what
dojo.validate.check() does: it takes a form id and a profile object, which tells
how to validate each field. Obviously the profile is generated by server
depending on underlying data types. Django has all information available to
ge
On 11/16/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
> PS: There are some people in Dojo community, who work on form widget,> which supports some validation mechanism. It would be nice to see what> they do.They do have some stuff to validate input. I found this file in their
repository:http://do
# Sorry for replying to myself.
Don't apologize to us; apologize to yourself!
--
Jonathan Daugherty
http://www.parsed.org
Sorry for replying to myself.
"Eugene Lazutkin" <[EMAIL PROTECTED]>
wrote in message news:[EMAIL PROTECTED]
>
> PS: There are some people in Dojo community, who work on form widget,
> which supports some validation mechanism. It would be nice to see what
> they do.
They do have some stuff to
On 11/16/05, hugo <[EMAIL PROTECTED]> wrote:
> keep in mind that things should at least have lower-level APIs that
> could be used even if the selected toolkit isn't used itself, but some
> other toolkit is.
Again, +1. Some sort of (hopefully RESTful) API which can respond to
queries and toss bac
>I'm sure people are convinced I'm just arguing for the sake of it, but I
>really am trying to get across a point which just hasn't been addressed
>by people who want to be toolkit-agnostic to the max.
I think we should be as toolkit-agnostic as we are
templatesystem-agnostic and ORM-agnostic. We
Wilson wrote:
> no matter which framework gets bundled (or if anything gets bundled
> at all)
This is the sticking point. I just have no idea how we add rich
functionality to the bundled apps without either
a) Picking a toolkit to bundle
b) Making some horrific abstraction layer over every bit o
Inline.
"Wilson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> But no matter which framework gets bundled (or if anything gets bundled
> at all) the exact same work is going to be necessary on the backend
> first.
All toolkits have different ways to make their magic. While it
Not true! I support your position. While we attempt to make Django
library-agnostic, let's settle on what is going to be used in bundled apps.
IMHO admin should be used as a field test of design decisions and a source
of new ideas. Maybe it would be useful to compile a list of required widgets
Honestly, I'm not really sure what you're after. Yes, everyone's
opinion is distinct. I think that's clear from the preceding
discussions. I'm just saying it might be productive to focus on what we
can and do agree on and act on that.
Far from being ignored, as far as I can tell, most of the conv
Wilson wrote:
> See what I mean? ;) Of course, everyone with a real opinion will
> ultimately fall somewhere between the two.
>
> Opinions aside, I guess what I was trying to say is let's talk nuts and
> bolts. You know, instead of apples and oranges.
Erm, my point was really contained in the word
Done.
I think that RoR's implementation is a little bit clunky:
1) too many callbacks, which may be processed on client side
2) too low level
3) unmodular on client side
Of course you can always write your own level, which will keep things
manageable in complex cases. Unfortunately RoR does co
On Nov 16, 2005, at 2:34 PM, Eugene Lazutkin wrote:
Will do. I was hoping that it would be discussed publicly before being
canned.
I didn't mean to "can" anything -- I think your assesment of what's
good about AJAX in Rails is quite useful, so I want it somewhere
slightly more prominent th
Will do. I was hoping that it would be discussed publicly before being
canned.
"Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> Eugene --
>
> Can you add this to the discussion on the wiki?
>
> Thanks,
>
> Jacob
>
Eugene --
Can you add this to the discussion on the wiki?
Thanks,
Jacob
While it does go against my beliefs, I have to admit that
"freeing users from choice" works. At least it worked in case of TurboGears. In
any case we have to provide "the preferred path" and document "the best
practices". Documented way to do typical things always trumps "you can use
whatev
See what I mean? ;) Of course, everyone with a real opinion will
ultimately fall somewhere between the two.
Opinions aside, I guess what I was trying to say is let's talk nuts and
bolts. You know, instead of apples and oranges.
On 11/16/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
Not to fan the flames, but I think my position has been a bit distinctfrom these:3. There are requirements for the bundled apps to make use of extensiveJS functionality. If we don't bundle an existing toolkit, we will end up
inventing a new one
Wilson wrote:
> So far the discussion of "AJAX support" in Django has been a relatively
> contentious one. There seem to be two viewpoints at the heart of this
> conflict, which are not mutually exclusive in their substance. At the
> risk of being unfair, let me grossly generalize the two position
So far the discussion of "AJAX support" in Django has been a relatively
contentious one. There seem to be two viewpoints at the heart of this
conflict, which are not mutually exclusive in their substance. At the
risk of being unfair, let me grossly generalize the two positions.
1. AJAX is the fut
Wilson Miner wrote:
> That's a red herring. Nothing in that plan precludes using an existing AJAX
> library. If Dojo or Mochikit or whatever else out there does what we need it
> to for the admin, then the end result will be that we "integrate" that
> particular AJAX framework and build in some ac
That's a red herring. Nothing in that plan precludes using an existing AJAX library. If Dojo or Mochikit or whatever else out there does what we need it to for the admin, then the end result will be that we "integrate" that particular AJAX framework and build in some access points to make it easy f
>Lets accept that other people are capable of waving the "extract from a
>working application" magic wand, and take a look at what they found
>rather than starting from scratch and recreating all their bugs.
+1
bye, Georg
Hi,
>I've been thinking about how Django might leverage DHTML^H^H^H^H^H
>AJAX a lot recently, and I think the framework I'll sketch out below
>should make a bunch of people happy.
my main gripe with your ideas is that you throw RPC style stuff
(XML-RPC and SOAP) in with the REST stuff. That just
"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 ac
Wilson Miner wrote:
> I think this all sounds great.
>
> I also think Adrian's point in his post about AJAX support is very valid
> here. Any support for AJAX in Django should come from real needs in a real
> project.
>
> As Rob pointed out in an earlier thread, once the new-admin changes are
>
Failing usability tests?
if stuff_is_blinking then return YOU_FAIL!!! :-)
"Jeremy Dunck" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
On 11/14/05, Eugene Lazutkin
<[EMAIL PROTECTED]> wrote:
>
> Nah, it would take all fun from bashing. :-) What kind of code do want to
> see for
I think this all sounds great. I also think Adrian's point in his post about AJAX support is very valid here. Any support for AJAX in Django should come from real needs in a real project.As Rob pointed out in an earlier thread, once the new-admin changes are rolled in, the project to fix the edit_i
Looks good. It pretty much consistent with my arguments. Unfortunately the
third layer is the most complex one and it is not well defined.
"Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
Hey folks --
Man, it's fun having such smart and passionate people on thi
On 11/14/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
> Nah, it would take all fun from bashing. :-) What kind of code do want to
> see for negative statements?
>
Failing tests.
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
Nah, it would take all fun from bashing. :-) What kind of code do want to
see for negative statements?
"Simon Willison" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]
>
>
> On 14 Nov 2005, at 22:37, Jacob Kaplan-Moss wrote:
>
>> How does this sound to everyone?
>
> Frickin' awesom
On 14 Nov 2005, at 22:37, Jacob Kaplan-Moss wrote:
How does this sound to everyone?
Frickin' awesome.
How about an informal rule for this list: no more discussion of Ajax
without code to back it up :)
Cheers,
Simon
I was also thinking of something a whole lot more simplistic as well.
javascript-enabling some of the validators.
for example.. we have a URL field.. it would be nice if the javascript
did the same regex match that the server side did, so that people
wouldn't have to submit it in the first place,
Hey folks --
Man, it's fun having such smart and passionate people on this list!
I've been thinking about how Django might leverage DHTML^H^H^H^H^H
AJAX a lot recently, and I think the framework I'll sketch out below
should make a bunch of people happy.
As I see it, there are three layers
57 matches
Mail list logo
