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
I didn't see it before. It looks like it implements CRUD-type manipulator
with predefined RESTful API --- a few lines of code on top of prototype.js.
This approach is a form of remoting and be complimented by automatic object
publishing from server side.
Usefulness of remote CRUD depends on a
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
this ajax conversation is getting long, and my apolagies for continuing it.
has anyone seen/heard of JSDBI ?
http://scottyallen.com/code/jsdbi.js
it looks like it would produce a pretty easy to use way of getting the
data to/from the client.
--
[EMAIL PROTECTED] -- ++61-3-9877-0909
If ever
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
Inline.
"Maniac" <[EMAIL PROTECTED]> wrote in
message news:[EMAIL PROTECTED]
>
> separation. This is bad (allow me not to descend into an academic-style
> discussion why).
I am with you.
> What I was trying to say is that I'm agains 'Ajax support' only if it
> means what I described above -
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
Eugene Lazutkin wrote:
Care to share these reasons or provide a link to reasons you support?
Unfortunately all this client-server separation is a marriage of
convenience, which is mostly created by network speed. Trust me: as network
speed grows, client-server separation will be less defined.
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
Adrian Holovaty wrote:
> On 11/16/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
>
>>For validation, we could do something like :
>>
>>from django.core import meta, validate
>>
>>class Poll:
>> date = meta.DateTimeField()
>> question = meta.CharField(maxlength=100)
>> category = meta.ForeignKey
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:
> For validation, we could do something like :
>
> from django.core import meta, validate
>
> class Poll:
> date = meta.DateTimeField()
> question = meta.CharField(maxlength=100)
> category = meta.ForeignKey(category)
>
> validate.fiel
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
To take peoples minds of of Dutch football teams and bathroom cleaning
fluids
I'm poodling around in a private svk branch so I don't break new-admin
;-) Specifically, I'm doing core fields removal, extending iholsmans
#747 ( getting all field determined model instance methods and module
metho
Inline.
"Baishampayan Ghose" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]
>
> Heh, AJAX, as you might have noticed is mostly all buzzword crap, but
No. My experience is quite opposite: AJAX is very useful tool. Not more, not
less.
> again many not-so-knowledgeable developers wo
I pulled some of the info from this thread and started a Wiki page:
http://code.djangoproject.com/wiki/AJAX
Please commence filling in the blanks and correcting my errors and
misrepresentations :)
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
Baishampayan Ghose wrote:
> Yeah surely. I have discussed about this AJAX stuff at length on IRC and
> my preference is shared by a lot of people and has been posted on the
> list too. What I feel is that I know Django ``supports'' AJAX today
> itself in a way that it doesn't restrict / stop the u
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eugene,
> 1) With all due respect I shall remind you that nobody forces to read all
> posts.
I know, but that's not the case. As you might realise, your one off
off-topic comments can stray the whole discussion towards something
which is totally irre
James Bennett wrote:
> For example, Rails includes an "AJAX library" called Prototype; this
> library provides "AJAX" functionality in that it delivers a facility
> for making asynchronous server calls from the client via JavaScript,
> but it also provides a number of easily-used visual DHTML eff
On 16-11- 2005, at 13:35, Radek Svarz wrote:
not sure if that helps you. We had to rollback and use 4.0.x (with
win-1250 and iso-8859-2) because the support of UTF-8 and collation
in 4.1 for the czech lang. was not properly done.
Well I found sollution, cludge but it works. I will create
not sure if that helps you. We had to rollback and use 4.0.x (with
win-1250 and iso-8859-2) because the support of UTF-8 and collation in
4.1 for the czech lang. was not properly done.
I'll give 4.1 another try tomorrow and let you know.
sorry, no help today.
Radek
On 11/16/05, Nebojša Đorđević
On 16-11-2005, at 13:12, Radek Svarz wrote:
There are diffs between 4.0.x 4.1.x and 5.
My local version is MySQL 4.0.23_Debian-3ubuntu2.1-log and TextDrive
is using MySQL 4.1.14-log, and probably that is a problem. Any
solutions?
---
Nebojša Đorđević - nesh
Studio Quattro - Niš - SCG
h
What's the MySQL version?
There are diffs between 4.0.x 4.1.x and 5.
RadekOn 11/16/05, Nebojša Đorđević - nesh <[EMAIL PROTECTED]> wrote:
I'm hitting interesting problem with MySQL hosted on TextDrive. Allcharacter encoding is set to utf-8 but I'm still getting a '?' forall accented characters fr
I'm hitting interesting problem with MySQL hosted on TextDrive. All
character encoding is set to utf-8 but I'm still getting a '?' for
all accented characters from all queries.
They recommended that 'SET CHARACTER SET utf8' should be sent after
opening connection to counter this to force
On 16 nov 2005, at 11.41, Bjørn Stabell wrote:
Is there any work underway to implement more than two-levels of inline
editing in the admin interface? I.e., Company/ Department/ Team/
Person in one interface?
I see this talk about 'new-admin' so I'd thought I'd ask.
What I've gathered from l
Hi. I have developed generic views and cheetah template loader (with caching
capabilites) for django.
http://126.pl/cheetah.tar.bz2
Just put it into django/contrib and change your urls.
Look into functions.tmpl - there are some handy functions for autmatically
displaying django models.
Have
Hi all,
Is there any work underway to implement more than two-levels of inline
editing in the admin interface? I.e., Company/ Department/ Team/
Person in one interface?
I see this talk about 'new-admin' so I'd thought I'd ask.
Rgds,
-- Bjorn
George,
That's exactly what I was insinuating. Provide some abstract sql types
that the Field classes can target as well as the database backends can
implement. There's already distinctions in text vs varchar in the
Fields themselves (CharField vs TextField), so that's already in place.
Basica
Baishampayan,
1) With all due respect I shall remind you that nobody forces to read all
posts.
2) I feel offended when people replace real issues with a stream of
meaningless buzz-words using evasive rhetoric when asked to explain the
meaning of those words --- "It depends on what the meaning
Today I discovered that I missed very interesting Django/Ajax-related
discussion on #django. Specifically MochiKit-Dojo comparison was discussed.
I know it is hard to talk about Dojo, when documentation is lacking. Let me
present my take, based on some experience with both toolkits from
prospe
>This immediately breaks if you extend a field and don't implement that
>method. Preferably, all the Field classes would implement the mapping
>right there. Each database shouldn't need to know how to map a USState
>field for example, just strings, dates and integers, etc.
Can't work. The field
>Remote scripting's been around, but GMaps and Garrett's >article
>whacked the mainstream designers over the head. AJAX >can stand for
>whatever acronym you want. When designers say "AJAX", >they mean rich
>interaction and a broken page request/response model >broken.
Actually AJAX can be done
On 11/15/05, Eugene Lazutkin <[EMAIL PROTECTED]> wrote:
>
> Now I am confused. AJAX stands for Asynchronous JavaScript And XML. But
> "AJAX effects" == visual effects? You have to publish your own dictionary,
There's a disconnect between the code monkeys and the designers.
Remote scripting's bee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eugene,
[snip]
>>For example, Rails includes an "AJAX library" called Prototype; this
>>library provides "AJAX" functionality in that it delivers a facility
>>for making asynchronous server calls from the client via JavaScript,
>>but it also provides
47 matches
Mail list logo
