I believe that's the expected outcome.. The use is to encode something for
the use in an URL...
Eg. convert "some-crazy//user?input" into something that can safely be
passed into http://www.google.com/search?q=URL_ENCODED_STRING
On Sun, Oct 25, 2009 at 9:14 PM, Danilo Cabello wrote:
>
> Hi,
>
>
This list is for the development of django itself. Please direct this
question to the django-users list, and for any further questions regarding
developing with django.
On Wed, Jul 29, 2009 at 7:12 AM, franxx wrote:
>
> does anyone have any idea how to serve non-html content on GAE using
> the a
This list is about django development it-self, not about developing with
django. Please send this question to django-users.
On Fri, Jul 10, 2009 at 3:35 PM, Benjamin Kreeger wrote:
>
> Here's the situation: I've got two projects, both Django. One is a
> simple, public-facing website that renders
Big bold letters:
*** THIS LIST IS NOT FOR DJANGO HELP - USE DJANGO USERS FOR THAT ***
On Fri, May 8, 2009 at 10:26 AM, Dave Smith wrote:
> On Fri, May 8, 2009 at 4:49 AM, Ned Batchelder wrote:
>
>> Add the word "core" to make the first sentence, "Discussion group for
>> Django core developers"
This is a question that should be directed to django-users.
Django-developers is a list dedicated to discussing of developing django
itself.
On Wed, Apr 29, 2009 at 2:53 PM, megaman821 wrote:
>
> I see fckeditor has python functions for its quick upload and image
> browsing. Is anyone using this
I really hate to be a pessimist, but if the functionality already
exists for that much generation, why bother integrating it with the
main django package?
On Mar 18, 8:06 pm, Jari Pennanen wrote:
> WTForm is simple implementation built on top of existing (new)forms to
> help create fieldsets, an
I don't really want a bunch of javascript in my django libraries. There are
a lot of opportunities for other developers to make something that's not
part of the core, and let it be plug-able. It keeps django away from
spending time maintaining javascript and being selective towards one
framework ov
r tag type
(to avoid JSP's problems with 500 different damn tag types, I
imagine), but I think the benefits of this one far outweigh the
"ickyness" of adding another tag.
Thanks for the patch!
-Tyson
On Sep 13, 2006, at 9:34 AM, Will McCutchen wrote:
>
> No pr
I imagine there are some people here who (like me) want to open
source some of their Django code, contrib apps, or other things but
cant run Subversion or Trac on their host. Google to the rescue, as
always:
http://code.google.com
Hopefully this can be useful to many of you.
-Tyson
On 7/27/06, Ian Holsman <[EMAIL PROTECTED]> wrote:
> I for one would like a 0.95 release.
...
Earlier today:
On 7/27/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
...
> We're working on the .95 release as I type
> this, though.
>
> Adrian
--~--~-~--~~~---~--~~
Y
d, your time might be better spent
working on all those "non-kiddy" projects you work on.
-Tyson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, s
number on it to appease management or do we wait and
put out a stable release with the features and changes that developers
have requested?
I, for one, really hope Pete's date-based generic view patches get applied. :)
Peace out,
Tyson
--~--~-~--~~~---~--~~
You r
ne: http://code.djangoproject.com/ticket/2386
I'm *really* hoping 2386 will get implemented soon.
And 2433. :)
-Tyson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To pos
> Regards,
> Malcolm
I'm +50 on this because I'm about ready to jump in to a large calendar
project next week and I'll need this functionality. If no one beats me
to it, I'll try to remember to hammer out a patch next week.
Any sugges
is
independant of your data is something that shouldn't be coupled with
the view that displays such data. Information that is relevant to your
data, such as the previous and next dates that contain your objects is
something that should be coupled with the data.
Regards,
Tyson
--~--~
us month's worth of data? "next_month" is empty if there's no
>> next data for next month. Which is logical.
>
> Continuing with a theme, this behavior does match the documentation
> precisely. Whether it should be changed is a
please, I'm begging, can someone, *anyone*, acknowledge these
problems, at the very least? I'm at the end of my rope with these
problems. I've spent the past two weeks trying to get the barest
acknowledgment of these problems on the lists and on IRC, but I feel
like a
quot;working around it". Who wouldn't?! After all, we're perfectionists on deadlines! :)Regards,Tyson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this
e.e-scribe.com/775/
entry_archive_day.html: http://paste.e-scribe.com/776/
entry_archive_month.html: http://paste.e-scribe.com/777/
entry_archive_year.html: http://paste.e-scribe.com/778/
entry_archive.html: http://paste.e-scribe.com/779/
generic_entry_list.html: http://paste.e-scribe.com/78
thing!
Regards,
Tyson
On Jul 16, 2006, at 2:10 PM, Tyson Tate wrote:
>
> Note: I originally posted part of the following to the users list,
> but I realized today that it's probably better posted here because it
> deals with a potential bug and developer rationale behind some
> gen
us Month: {{ next_month|date:"F Y"}}
{% endif %}
{% if previous_month %}
Next Month: {{ previous_month|date:"F Y"}}
{% endif %}
---
Thanks in advance for any help/suggestions,
Tyson Tate
--
Tyson Tate
- CalPoly Graphic Design Student
- Work: Graphic Designer (CalPoly L
)
I'm +1 on this too. I've done it many a time, expecting it to "just
work".
Thanks!
-Tyson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group
On Jun 24, 2006, at 11:14 AM, Tyson Tate wrote:
>
> Most comment systems that I know of allow the commenter to optionally
> supply an e-mail address and/or a URL along with their comment for
> attribution or administrator records. I thought it would be really
> handy to have i
On Jun 26, 2006, at 7:16 PM, Jacob Kaplan-Moss wrote:
> Yeah, as I read over my own email I'm inclined to agree with you -- I
> think ``objects.create()`` seems a bit nicer.
>
> Jacob
+1 Agreed! I'd very much like the ability to save me all those crazy
p.save()
ust random
junk?) I couldn't find where I should include this sort of field
validation in the contrib.comments code, so perhaps someone can point
me in the right direction and I'll throw in some simple RegEx
validators with validation error messages.
Let me know what you guys th
fiasco. Do you have any
links or more information about this? If it blew up for the PHP
folks, I think I'd be prone to changing my position on the issue.
Regards,
Tyson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to th
escaping automatically turned on.
Regards,
Tyson
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe fro
lems outside of the admin interface. If anyone could
point me to the relevant areas of code (i.e. where in Django's code
does it determine if a model shouldn't be created because it's empty,
etc.), I'd be happy to take a crack at a patch or two to give these
ideas a shot.
;basic security check" function that is
either run only explicitly by the user or as part of some other
function (syncdb etc.) that checks for untrusted strings that are
publicly viewabel and simply lists them as warnings.
> Thoughts?
Given!
-Tyson
[1] Here at work, we have dozens of
s a signup list, which has a one-to-many
relationship with signup slots.)
I have two ideas on how this could be addressed:
1. Throw a warning or error in Syncdb, letting the user know that
every model must have at least one explicit field.
2. Build the field as the programmer defined them.
Any
30 matches
Mail list logo