Re: 'retrieve': the missing permission?
David Larlet wrote: > 2007/6/18, David Larlet <[EMAIL PROTECTED]>: >> Hi, >> >> I've just tried to use the permission_required decorator for my views >> and I realise that there is a missing 'retrieve' permission. It's a >> bit odd because others ones follow the CRUD permissions. >> >> Am I missing something here? >> >> The patch is trivial: >> Add 'retrieve' to the auth.management._get_all_permissions function, >> but I don't want to hack my django code so I wonder why this choice >> had been done? (I suspect the admin goal which is driven by the >> User.is_staff field but auth can be used elsewhere). >> >> David >> > > Am I the only one who deal with this kind of permission issue? Or > maybe there is an evident solution that I haven't found yet? you can create your own permissions: http://www.djangoproject.com/documentation/model-api/#permissions gabor --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: 'retrieve': the missing permission?
2007/6/18, David Larlet <[EMAIL PROTECTED]>: > Hi, > > I've just tried to use the permission_required decorator for my views > and I realise that there is a missing 'retrieve' permission. It's a > bit odd because others ones follow the CRUD permissions. > > Am I missing something here? > > The patch is trivial: > Add 'retrieve' to the auth.management._get_all_permissions function, > but I don't want to hack my django code so I wonder why this choice > had been done? (I suspect the admin goal which is driven by the > User.is_staff field but auth can be used elsewhere). > > David > Am I the only one who deal with this kind of permission issue? Or maybe there is an evident solution that I haven't found yet? I think it can be useful to restrict access in views or even better in urls and it works very well except for retrieve permission which doesn't exist. David --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: linebreaksli template filter
On Jun 20, 5:03 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > My code is below. It wouldn't take too much to > convert it to a Django template filter. What does everyone think? Interesting filter. Personally, I'm not sure this is useful enough for core. --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
linebreaksli template filter
I don't want to attempt to pollute Django's beautiful template library
namespace with garbage, but I do see a legitimate value for a
linebreaksli template filter. It does just what it says - converts a
string with linebreaks into a set of list items. Sometimes, a tag
just doesn't do the same thing, especially if you want to number the
items with an . My code is below. It wouldn't take too much to
convert it to a Django template filter. What does everyone think?
def linebreaksli(value):
"Converts strings with newlines into s"
value = re.sub(r'\r\n|\r|\n', '\n', value) # normalize newlines
lines = re.split('\n', value)
lines = ['%s' % line for line in lines]
return '\n'.join(lines)
--~--~-~--~~~---~--~~
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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On 6/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hi, I've been trying this out as the new inline functionality in
> newforms-admin branch but I've found one problem: raw_id_admin fields
> aren't rendered correctly in inline fields. They are still rendered as
> select widgets.
>
> Is this a known issue that is being worked on?
Yep. None of the javascript stuff really works right now. The calendar
and picker widgets for date and time fields, for instance, are broken.
The configuration will be different for raw_id fields as well. For
example:
class MyModelAdmin(models.ModelAdmin):
inlines = [StackedInline(MyModel, raw_id_fields=('field1', 'field2'))]
That code doesn't work yet, but that will probably be how to do it.
Christian Metts is helping me out with some template changes to make
things look nicer now that each object has a deletion checkbox. Once I
get his work integrated, I'll start on stuff like raw_id fields. If
you want to file a ticket against newforms-admin, that would be great.
Thanks for testing it out.
Joseph
--~--~-~--~~~---~--~~
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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Admin Date/Time Fields in localtime
Craig wrote: > I have noticed that when using the admin site (which is really nice, > by the way), the date and time fields have a nice js widget to fill in > the current date and time, but it uses localtime, not UTC time. Our > database we store all time fields in UTC, and having the web page use > localtime is a problem. Is there someway we can add a setting to the > admin site to say use local (broswer time) or UTC time? I don't mind > doing it if someone can give me a hint on where to do it. I can see > that the functions are in the media/js/core.js file I vaguely remember seeing a ticket with a similar issue... yes, here we go: http://code.djangoproject.com/ticket/2626 Gary --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On Jun 15, 1:58 pm, "Joseph Kocherhans" <[EMAIL PROTECTED]> wrote: > On 6/9/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > > > > On 6/8/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > > I'm most of the way there. Basically just template stuff and a little > > > bit of ModelAdmin code is left. I got stuck a few times keeping this > > > stuff usable outside the admin, and at multiple levels. I think it was > > > worth the effort, but time will tell. Expect to see a working version > > > checked in next week. Maybe sooner. And huzzah! core=True is no longer > > > necessary. > > > This is great news. Looking forward to it! > > I just checked in a bunch of > changes.http://code.djangoproject.com/changeset/5473 > > The templates still need some work, ok... a lot of work. I need to > write some more tests, and I'm going to rework some of the internals, > but things are pretty much functional. > > Feel free to start filing bugs and asking questions, but please ask > them in a new thread. And to answer many people's first question, no, > you cannot have inlines inside of inlines. If you want that, you're on > your own, and good luck ;) The second question, no, inline file > uploads don't work right now, but I plan on making that happen at some > point. > > Joseph > > > from django.db import models > from django.contrib.admin import site, ModelAdmin, StackedInline, > TabularInline > > class Poll(models.Model): > question = models.CharField(maxlength=255) > > def __str__(self): > return self.question > > class Choice(models.Model): > poll = models.ForeignKey(Poll) > > choice = models.CharField(maxlength=255) > votes = models.IntegerField() > > def __str__(self): > return self.choice > > class PollAdmin(ModelAdmin): > inlines = [TabularInline(Choice, extra=2)] > > class ChoiceAdmin(ModelAdmin): > list_display = ['choice', 'poll', 'votes'] > > site.register(Poll, PollAdmin) > site.register(Choice, ChoiceAdmin) Hi, I've been trying this out as the new inline functionality in newforms-admin branch but I've found one problem: raw_id_admin fields aren't rendered correctly in inline fields. They are still rendered as select widgets. Is this a known issue that is being worked on? regards matthew -- http://wadofstuff.blogspot.com --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: lazy-geometries/planning
> For instance, the lazy geometries patch in 4322 is way off
> track now we have support for ogr geometries.
The lazy geometries patch in 4322 is only a month old, and ten days
ago I incorporated portions of your patch in r5448. Not exactly what
I would consider "way off track" -- at least from my experience with
open source projects. Regardless, I'll concede that GDAL feature
additions have been prioritized over your patch for the reasons
enumerated below.
The addition of GDAL support was, I believe, more important for
GeoDjango than lazy geometries. To begin with, all lazy-geometry
functionality can be accomplished with existing extra instance methods
(e.g. "geomodel.objects.get_geom_geos().convex_hull"). Further, my
priorities have been aligned with what's on the wiki -- the phase 2
components with the highest priority are distance queries and GIS
dataset utilities (i.e., importing from SHP files directly into
GeoDjango models). The addition of native GDAL support is aligned
with these priorities.
As those familiar with GIS systems are aware, GIS data comes in a vast
multitude of formats (e.g. ESRI Shapefiles, MapInfo files, TIGER
files, etc.). To complicate matters, each dataset will use different
spatial reference systems -- rarely do I see a SHP file in WGS84 (for
non-GIS folks this is the system for lat/lon coordinates you get from
GPS). Fortunately, the GDAL library has an _excellent_ library for
both reading and transforming spatial data sets in these conditions.
While this may have been possible through the use of PostGIS SQL
statements such as "INSERT ... transform("POLYGON((... ))", 4326)," I
wanted to have this functionality accessible to the user, independent
of the database.
Distance queries present similar problems since the calculated
distance depends on the spatial reference system. For example,
distances calculated with coordinates in WGS84 are in units of degrees
-- hardly of use to someone looking for a store within 2km of their
home. Transforming to a projected coordinate system, with units in
meters (or miles), is more appropriate. PostGIS transformations only
accept an EPSG code (integer) associated with the spatial reference
system; giving the user access to a SpatialReference object that can
take multiple inputs (proj strings, EPSG codes, Well-Known Text, etc.)
that can then be passed to future distance routines seemed like a
better solution.
> but it helps if i can see a little way into the future
> about what other changes are planned to happen, and who is working on what.
There has been little "formal" division of duties on the GIS branch --
the only thing I can think of is that Jeremy handles the syncs to
trunk. Please be patient with our progress -- like other devs, we
have commitments outside of Django that may make commits and ticket
fixes sporadic.
Regards,
-Justin
--~--~-~--~~~---~--~~
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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Message Passing for Anonymous Users
On 6/19/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > Keep in mind how get_and_delete_messages() currently works; it > retrieves the messages and removes them so they won't show up on > subsequent page views. There would need to be some mechanism to > achieve this, so it would have to be something above and beyond a > simple list anyway. I obviously didn't read your patch either, SmileyChris. Looks good. :) -Gul --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Any news about MS SQL Server support
On Tue, 2007-06-19 at 17:35 -0300, Bruno Tikami wrote: > Hi Django folks! > > Does anyone have any news about Django supports to MS SQL Server? I've > already read the hole old bunch of topics and dicussions about this > matter, jsut want to know if there is come news. Nobody appears to be working on it. Malcolm --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Message Passing for Anonymous Users
On Jun 20, 5:27 am, "Amit Upadhyay" <[EMAIL PROTECTED]> wrote: > On 6/19/07, James Bennett <[EMAIL PROTECTED]> wrote: > > I'd be +1 on just switching the whole thing (messages for all users, > > authenticated or not) to using sessions, in which case > > django.contrib.auth.models.Message should be deprecated and replaced > > by django.contrib.sessions.models.Message. > > Why is request.session["_messages"] not enough? It can be a list of string > messages. I'm thinking that James didn't actually read my patch ;) --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Message Passing for Anonymous Users
On Jun 20, 3:58 am, "Joseph Heck" <[EMAIL PROTECTED]> wrote: > Out of curiousity, what's the reason to try and keep them separate > instead of just layering it over the session mechanism? Mainly due to the limitation of context processors that they can't see or change the current context. The core auth context processor pushes it's messages to the "message" context variable. It would have to be done in that same processor to be able to catch both session and auth messages and push them to the same context variable but then you can't have full sessions message functionality without using the combined processor.. --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: contrib.thumbnails approval?
On Jun 20, 1:50 am, Michel Thadeu Sabchuk <[EMAIL PROTECTED]> wrote: > But coming back to discussion again :D, what does happen if I remove > an image, it does not remove the thumbnail, am I right? Is there any > plan to work on this? Not really... Perhaps there should be a cleanup method you can call in the model's delete method, passing in the field you want to clean up any thumbnail files for. --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
KIPS (Keep It Personal, Stupid!) [was: Re: International standard for date and time]
> Jonas wrote: >> I remember to you that we are to interacting with computers, not with >> persons. James Bennett wrote: > The problem is that we're not really "interacting with computers". > We're using computers as proxies to help us interact with *people*, > and they should be first in our thoughts at all times. Very well said, and easily and sadly forgotten, sometimes. In this day and age, these machines are not mere computing devices, nor "ordinateurs": they are communicators, conveying and embodying many facets of the human beings that use them. (Many other human facets still elude our machines, but that would be doubly off-topic. ;-) ) -- Nicola Larosa - http://www.tekNico.net/ I'm not expecting Ubuntu to be perfect, but I am now certain it will be enough better to compensate me for the fact that I need to learn a new set of administration tools. Fedora, you had every advantage, and you had my loyalty, and you blew it. And that is a damn, dirty shame. -- Eric S. Raymond, February 2007 --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Message Passing for Anonymous Users
On 6/19/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> Why is request.session["_messages"] not enough? It can be a list of string
> messages.
Keep in mind how get_and_delete_messages() currently works; it
retrieves the messages and removes them so they won't show up on
subsequent page views. There would need to be some mechanism to
achieve this, so it would have to be something above and beyond a
simple list anyway.
Of course, doing that would be as simple as adding a
session.get_and_delete_messages() that reads session["_messages"] and
deletes it (or sets it to an empty list). And
user.message_set.create(message="blah") could be replaced with a much
simpler session.add_message("blah"). That method would take the step
of making sure the list is created if not already, or adding to it if
it's already there.
One thing it would lose is the ability to send messages to users
without them being logged in, or from actions initiated by other
users. By using the current database system, both of those are
possible. While it's probably an uncommon use, it's certainly a
possibility, and would be lost by simply moving to sessions.
All in all, I think it would work well on sessions, as long as the
above concerns are addressed, rather than simply expecting developers
to manage a list of their own. The one concern I addressed is
certainly not enough to cause me any pause, but I'm just one.
-Gul
--~--~-~--~~~---~--~~
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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: International standard for date and time
On 6/19/07, Jonas <[EMAIL PROTECTED]> wrote: > It's true that we are around circles, and I understand that you wann't > make that little change. It's more comfortable to have the framework > configured to your localization that: And it's already quite easy to do so, just by changing a couple settings. Why are we still going around about the default value? > * to thinking in in the rest of people > * doesn't continue believing that USA is the world > * and that the international standards, -created to facilitate the > data interchange between all countries-, are not worthy for them. Whoa, there, cowboy! You do know that among the core Django developers we have representatives of multiple countries, right? Plus, I have it on good authority that one of the American committers is actually part of a secret Ukrainian conspiracy to hook the US on gypsy jazz, though I'm not sure how they plan to profit from it. And Malcolm, who's lobbying against this change, is an Aussie who knows how to fly a hovercraft full of eels in more languages than I can count, so I'm not really seeing any US imperialism artfully hidden in the default value of the DATE_FORMAT setting. > Only 3 countries in all world have not adopted it. I'm sure that you > guess one of them. I guess it :P My car gets forty rods to the hogshead, and that's the way I like it! > I remember to you that we are to interacting with computers, not with > persons. It's by that reason that the operating systems show date and > time in that format -at least in my Debian- but it's possible that > you're using Windows. The problem is that we're not really "interacting with computers". We're using computers as proxies to help us interact with *people*, and they should be first in our thoughts at all times. I'm going to stand by my earlier -1: this is a bikeshed issue, and we've already painted it an arbitrary color and shipped instructions on how to change it if people want to ;) (though if we really want to be culturally agnostic, I'll nominate the Mesoamerican "long count", which nobody really uses anymore, so everyone would want to change the default setting to their own culture's preference. Plus, once we get over the dreaded y2k12 problem from rolling over a thirteenth b'ak'tun, it'll be stable again until around 6100 AD) -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: International standard for date and time
On 6/19/07, Jonas <[EMAIL PROTECTED]> wrote: > > On 18 jun, 23:17, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > I'm going to give this one more pass and then dropout. We're just going > > around in circles now. > It's true that we are around circles, and I understand that you wann't > make that little change. It's more comfortable to have the framework > configured to your localization that: > > * to thinking in in the rest of people > * doesn't continue believing that USA is the world > * and that the international standards, -created to facilitate the > data interchange between all countries-, are not worthy for them. > > Indeed I just read the next news that leaves very clear what I am > saying: > http://digg.com/general_sciences/Nations_who_have_not_yet_adopted_the_metric_system_pic > > "Nations who have not yet adopted the metric system" > Only 3 countries in all world have not adopted it. I'm sure that you > guess one of them. I guess it :P Besides the fact that you're being utterly unproductive with your combative attitude here, you *do* realize Malcolm is Australian, right? Furthermore, you're trying to "shame" a project that has a stellar internationalization track record. Trust me -- these guys "get it". Apparently, you don't. > > Do you really say 2007-06-18 when your friends ask you what the date is? > > Does your grandmother, who doesn't use computers as much as you do, use > > that format? We are trying to encourage websites that feel natural to > > all users, not just friendly for people who have used computers all > > their lives. > I remember to you that we are to interacting with computers, not with > persons. It's by that reason that the operating systems show date and > time in that format -at least in my Debian- but it's possible that > you're using Windows. Did you miss the point, stated several times, that all of this has *nothing* to do with the internal representation of the date/time? Changing the format will have *nothing* to do with how your server stores the time. "-MM-DD HH:MM:SS" is just as much a *human* convention as any other textual date/time format; the database *does not* store the date like that. :: sighs and goes back to doing more productive things :: --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Any news about MS SQL Server support
Hi Django folks! Does anyone have any news about Django supports to MS SQL Server? I've already read the hole old bunch of topics and dicussions about this matter, jsut want to know if there is come news. Best regards my friends! Tkm --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Fix for #4565 caused this code to break, not sure how to fix my code.
On Tue, Jun 19, 2007 at 01:12:40PM -0600, Norman Harman wrote:
>
> This change
>
> r5482 | mtredinnick | 2007-06-17 00:11:37 -0700 (Sun, 17 Jun 2007) | 4 lines
>
> Fixed #4565 -- Changed template rendering to use iterators, rather than
> creating large strings, as much as possible. This is all backwards
> compatible.
> Thanks, Brian Harring.
>
> Specifically the isinstance checks in/django/django/template/__init__.py
>
> class NodeBase(type):
> def __new__(cls, name, bases, attrs):
> """
> Ensures that either a 'render' or 'render_iter' method is
> defined on
> any Node sub-class. This avoids potential infinite loops at
> runtime.
> """
> if not (isinstance(attrs.get('render'), types.FunctionType) or
> isinstance(attrs.get('iter_render'), types.FunctionType)):
> raise TypeError('Unable to create Node subclass without
> either "rend
> return type.__new__(cls, name, bases, attrs)
>
>
> Breaks this code, from
> http://code.google.com/p/django-voting/wiki/RedditStyleVoting
>
> Seems like the above check doesn't "see" the inherited method. Based on
> the fact that above test passes if I but a render method in the two
> subclassess. But I don't really grok new/metaclass stuff all that
> supremely. Any help/insight in how to fix this is appreciated.
>
> from django import template
>
> class BaseForObjectNode(template.Node):
> def __init__(self, object, context_var):
> self.object = object
> self.context_var = context_var
>
> def render(self, context):
> try:
> object = template.resolve_variable(self.object, context)
> except template.VariableDoesNotExist:
> return ''
> context[self.context_var] = self._func(object)
> return ''
>
> class ScoreForObjectNode(BaseForObjectNode):
> _func = Vote.objects.get_score
>
> class AverageForObjectNode(BaseForObjectNode):
> _func = Vote.objects.get_average
See ticket 4625; ought to fix it. Adding tests would be welcome also,
since none seem to have been added :)
Thanks,
~harring
pgpNOFRT1sLgx.pgp
Description: PGP signature
Re: International standard for date and time
On 18 jun, 23:17, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I'm going to give this one more pass and then dropout. We're just going > around in circles now. It's true that we are around circles, and I understand that you wann't make that little change. It's more comfortable to have the framework configured to your localization that: * to thinking in in the rest of people * doesn't continue believing that USA is the world * and that the international standards, -created to facilitate the data interchange between all countries-, are not worthy for them. Indeed I just read the next news that leaves very clear what I am saying: http://digg.com/general_sciences/Nations_who_have_not_yet_adopted_the_metric_system_pic "Nations who have not yet adopted the metric system" Only 3 countries in all world have not adopted it. I'm sure that you guess one of them. I guess it :P > Do you really say 2007-06-18 when your friends ask you what the date is? > Does your grandmother, who doesn't use computers as much as you do, use > that format? We are trying to encourage websites that feel natural to > all users, not just friendly for people who have used computers all > their lives. I remember to you that we are to interacting with computers, not with persons. It's by that reason that the operating systems show date and time in that format -at least in my Debian- but it's possible that you're using Windows. -- For Linux only: Run *ls -lF* into a shell directory and you can see the date and time on international format. -- --- I'm consequent with I'm saying but I wann't to offend nobody. I hope that nobody feels like victim Greetings! --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: multidb and trunk
Thanks. Awaiting news from Ben... WBR, Dmitry On 17 июн, 02:27, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Sat, 2007-06-16 at 20:15 +, dimas wrote: > > Hello all, > > > Is it hard to portmultidbfeatures against trunk? > > > Or any info on how ready is it to get merged? > > Perhaps you might want to read > this:http://groups.google.com/group/django-developers/browse_frm/thread/18... > > Regards, > Malcolm --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Fix for #4565 caused this code to break, not sure how to fix my code.
This change
r5482 | mtredinnick | 2007-06-17 00:11:37 -0700 (Sun, 17 Jun 2007) | 4 lines
Fixed #4565 -- Changed template rendering to use iterators, rather than
creating large strings, as much as possible. This is all backwards
compatible.
Thanks, Brian Harring.
Specifically the isinstance checks in/django/django/template/__init__.py
class NodeBase(type):
def __new__(cls, name, bases, attrs):
"""
Ensures that either a 'render' or 'render_iter' method is
defined on
any Node sub-class. This avoids potential infinite loops at
runtime.
"""
if not (isinstance(attrs.get('render'), types.FunctionType) or
isinstance(attrs.get('iter_render'), types.FunctionType)):
raise TypeError('Unable to create Node subclass without
either "rend
return type.__new__(cls, name, bases, attrs)
Breaks this code, from
http://code.google.com/p/django-voting/wiki/RedditStyleVoting
Seems like the above check doesn't "see" the inherited method. Based on
the fact that above test passes if I but a render method in the two
subclassess. But I don't really grok new/metaclass stuff all that
supremely. Any help/insight in how to fix this is appreciated.
from django import template
class BaseForObjectNode(template.Node):
def __init__(self, object, context_var):
self.object = object
self.context_var = context_var
def render(self, context):
try:
object = template.resolve_variable(self.object, context)
except template.VariableDoesNotExist:
return ''
context[self.context_var] = self._func(object)
return ''
class ScoreForObjectNode(BaseForObjectNode):
_func = Vote.objects.get_score
class AverageForObjectNode(BaseForObjectNode):
_func = Vote.objects.get_average
thanks,
norm
--~--~-~--~~~---~--~~
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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Message Passing for Anonymous Users
On 6/19/07, James Bennett <[EMAIL PROTECTED]> wrote: > > I'd be +1 on just switching the whole thing (messages for all users, > authenticated or not) to using sessions, in which case > django.contrib.auth.models.Message should be deprecated and replaced > by django.contrib.sessions.models.Message. Why is request.session["_messages"] not enough? It can be a list of string messages. -- Amit Upadhyay Vakow! www.vakow.com +91-9820-295-512 --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Admin Date/Time Fields in localtime
I have noticed that when using the admin site (which is really nice, by the way), the date and time fields have a nice js widget to fill in the current date and time, but it uses localtime, not UTC time. Our database we store all time fields in UTC, and having the web page use localtime is a problem. Is there someway we can add a setting to the admin site to say use local (broswer time) or UTC time? I don't mind doing it if someone can give me a hint on where to do it. I can see that the functions are in the media/js/core.js file getHourMinuteSecond() maybe we could add a function called getUTCHourMinuteSecond() and use that if the option is set (or as the default). I am pretty new to Django, I am still learning the code, but I think it would be a nice feature to have, since I think most people store date/time in DBs as UTC time. I really like Django, it is pretty nice, I have used a few java web frameworks before and Django is a lot easier and a lot faster to develop in. I hope in the future I can contribute! --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Message Passing for Anonymous Users
On 6/19/07, Joseph Heck <[EMAIL PROTECTED]> wrote: > Out of curiousity, what's the reason to try and keep them separate > instead of just layering it over the session mechanism? I'd be +1 on just switching the whole thing (messages for all users, authenticated or not) to using sessions, in which case django.contrib.auth.models.Message should be deprecated and replaced by django.contrib.sessions.models.Message. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Message Passing for Anonymous Users
Out of curiousity, what's the reason to try and keep them separate instead of just layering it over the session mechanism? -joe On 6/18/07, SmileyChris <[EMAIL PROTECTED]> wrote: > > It's not difficult for someone to implement this themselves, but it > does seem useful enough (imo) for core. > > I have also contributed a patch to that ticket (sorry for the hijack) > with docs and tests, calling the framework "visitor messages" to keep > it separate from auth's "messages" framework. > > > > > --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: textile mysql unicode and newforms
Hi Waylan
I tried it the uicode branch on my local machine and it didn't make any
difference. I'm still keeping it on my local box though.
So, I tweaked the code a bit, so it looks like this at the top of the save
overide now, not at the bottom and it's working as expected.
if self.summary:
self.summary = self.summary.encode('ascii', 'ignore')
self.summary_html = textile.textile(self.summary)
That way we simply don't pass the pasted apostrophes at all, and textile
works, what i was after in the first place.
This works on the production server that isn't running the unicode branch
yet. Soon though, when we get some time to test.
I think I might have some trouble when my boss tells me they want to use the
same code base to do a welsh site though, lots of funny characters in there.
And the country
:-)
On 19/06/07, Waylan Limberg <[EMAIL PROTECTED]> wrote:
>
>
> I suspect the Unicode branch [1] addresses the issues you are having.
> A few weeks back there was a call for testers as it is now feature
> complete. I'd suggest giving that a try.
>
> [1]: http://code.djangoproject.com/wiki/UnicodeBranch
>
>
> On 6/19/07, vanderkerkoff <[EMAIL PROTECTED]> wrote:
> >
> > Hello everyone
> >
> > I'm running django from the trunk, so using the most up to date
> > version, python 2.5 with PyTextile 2.0.10.
> > mysql5.0.2 with all settings to utf-8 and django content type is utf-8
> >
> > I'm overwriting the save command on events using newforms, we're
> > textiling the input for an html field, here's what I mean.
> >
> > def save(self):
> > import textile
> > if self.body:
> > self.body_html = textile.textile(self.body)
> > super(Event, self).save()
> >
> >
> > it fails with this error
> >
> > Exception Value:'ascii' codec can't decode byte 0xb4 in position
> 0:
> > ordinal not in range(128)
> > Exception Location:
> /usr/local/lib/python2.5/site-packages/textile.py
> > in glyphs, line 2418
> >
> > My textile settings are
> > # Set your encoding here.
> > ENCODING = 'utf8'
> >
> > # Output? Non-ASCII characters will be automatically
> > # converted to XML entities if you choose ASCII.
> > OUTPUT = 'utf8'
> >
> > I tried changing my OUTPUT to ascii in textile but got the same error,
> > so to me it looks like the form is sending a unicode
> > series of bytes to textile which it can't understand.
> >
> > One way around this is to manipulate the self.summary prior to passing
> > it to textile, like this.
> >
> > self.body = self.body.decode('utf-8')
> > self.body = self.body.encode('ascii', 'ignore')
> >
> > This forces the passing of ascii to textile and it likes that alot,
> > and works.
> >
> > But if a user now copies and pastes the dreaded apostrophe form word
> > or another special character unique to word,
> > it fails with this error.
> >
> > Exception Value:'ascii' codec can't encode character u'\u2019'
> in
> > position 5: ordinal not in range(128)
> > Exception Location: /usr/local/lib/python2.5/encodings/utf_8.py in
> > decode, line 16
> >
> >
> > If I run the super save earlier in the save definition after removing
> > the textiling of the body section, and then
> > call the data out of the database further down in the save definition,
> > and then save it again like this
> >
> > e = Event.objects.get(id=new_id)
> > if e.body:
> > e.body_html = textile.textile(e.body)
> > super(Event, e).save()
> >
> > It all works fine, no encoding or decoding needed for pasted
> > apostrophes or anything.
> >
> > Here's the paste of the relevant part of the form with certain
> > sections commented out so you can see what I mean.
> >
> > http://pastie.textmate.org/71702
> >
> > I found this on the google groups form Ivan Sagalev
> > To summarizes: your storage (a database) and your input/output (the
> > web)
> > really should use utf-8 to avoid problems with "strange" characters.
> > If
> > you deal internally with unicode (which newforms produce for you) then
> > for now you should explicitly encode from it to utf-8 until Django
> > starts doing it automatically.
> >
> > I've also been reading this thread on the google developers group, and
> > I'm now completely confused as to what is going on.
> >
> > unicode issues in multiple tickets
> >
> > If anyone can tell me if there is some current status on this, or how
> > it works right now I'd be really grateful. If I have to encode and
> > decode then I
> > don't mind, not much anyway :-)
> >
> >
> > >
> >
>
>
> --
>
> Waylan Limberg
> [EMAIL PROTECTED]
>
> >
>
--~--~-~--~~~---~--~~
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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~---
Re: contrib.thumbnails approval?
Very thanks guy! > I was thinking that perhaps this could alternately go in an `images` > contrib package in case there are other related image functions (the > captcha image generator discussed in the users group for example) I agree with you! But coming back to discussion again :D, what does happen if I remove an image, it does not remove the thumbnail, am I right? Is there any plan to work on this? --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: textile mysql unicode and newforms
I suspect the Unicode branch [1] addresses the issues you are having.
A few weeks back there was a call for testers as it is now feature
complete. I'd suggest giving that a try.
[1]: http://code.djangoproject.com/wiki/UnicodeBranch
On 6/19/07, vanderkerkoff <[EMAIL PROTECTED]> wrote:
>
> Hello everyone
>
> I'm running django from the trunk, so using the most up to date
> version, python 2.5 with PyTextile 2.0.10.
> mysql5.0.2 with all settings to utf-8 and django content type is utf-8
>
> I'm overwriting the save command on events using newforms, we're
> textiling the input for an html field, here's what I mean.
>
> def save(self):
> import textile
> if self.body:
> self.body_html = textile.textile(self.body)
> super(Event, self).save()
>
>
> it fails with this error
>
> Exception Value:'ascii' codec can't decode byte 0xb4 in position 0:
> ordinal not in range(128)
> Exception Location: /usr/local/lib/python2.5/site-packages/textile.py
> in glyphs, line 2418
>
> My textile settings are
> # Set your encoding here.
> ENCODING = 'utf8'
>
> # Output? Non-ASCII characters will be automatically
> # converted to XML entities if you choose ASCII.
> OUTPUT = 'utf8'
>
> I tried changing my OUTPUT to ascii in textile but got the same error,
> so to me it looks like the form is sending a unicode
> series of bytes to textile which it can't understand.
>
> One way around this is to manipulate the self.summary prior to passing
> it to textile, like this.
>
> self.body = self.body.decode('utf-8')
> self.body = self.body.encode('ascii', 'ignore')
>
> This forces the passing of ascii to textile and it likes that alot,
> and works.
>
> But if a user now copies and pastes the dreaded apostrophe form word
> or another special character unique to word,
> it fails with this error.
>
> Exception Value:'ascii' codec can't encode character u'\u2019' in
> position 5: ordinal not in range(128)
> Exception Location: /usr/local/lib/python2.5/encodings/utf_8.py in
> decode, line 16
>
>
> If I run the super save earlier in the save definition after removing
> the textiling of the body section, and then
> call the data out of the database further down in the save definition,
> and then save it again like this
>
> e = Event.objects.get(id=new_id)
> if e.body:
> e.body_html = textile.textile(e.body)
> super(Event, e).save()
>
> It all works fine, no encoding or decoding needed for pasted
> apostrophes or anything.
>
> Here's the paste of the relevant part of the form with certain
> sections commented out so you can see what I mean.
>
> http://pastie.textmate.org/71702
>
> I found this on the google groups form Ivan Sagalev
> To summarizes: your storage (a database) and your input/output (the
> web)
> really should use utf-8 to avoid problems with "strange" characters.
> If
> you deal internally with unicode (which newforms produce for you) then
> for now you should explicitly encode from it to utf-8 until Django
> starts doing it automatically.
>
> I've also been reading this thread on the google developers group, and
> I'm now completely confused as to what is going on.
>
> unicode issues in multiple tickets
>
> If anyone can tell me if there is some current status on this, or how
> it works right now I'd be really grateful. If I have to encode and
> decode then I
> don't mind, not much anyway :-)
>
>
> >
>
--
Waylan Limberg
[EMAIL PROTECTED]
--~--~-~--~~~---~--~~
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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Volunteering for "Week in Review" postings
On 6/18/07, Clint Ecker <[EMAIL PROTECTED]> wrote: > > Everyone: > > *** I sent this to Adrian this afternoon and I just ... > Technica), I think it would be most prudent to publish these before > noon on Mondays when there are likely to be the most eyeballs. Does > this sound reasonable? It sounds like you know what you're doing. :) --~--~-~--~~~---~--~~ 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 from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: textile mysql unicode and newforms
Here's the add_event in my views which uses the newforms and calls the save.
http://pastie.textmate.org/71706
It will probably help :-)
On 19/06/07, vanderkerkoff <[EMAIL PROTECTED]> wrote:
>
> Hello everyone
>
> I'm running django from the trunk, so using the most up to date
> version, python 2.5 with PyTextile 2.0.10.
> mysql5.0.2 with all settings to utf-8 and django content type is utf-8
>
> I'm overwriting the save command on events using newforms, we're
> textiling the input for an html field, here's what I mean.
>
> def save(self):
> import textile
> if self.body:
> self.body_html = textile.textile(self.body)
> super(Event, self).save()
>
>
> it fails with this error
>
> Exception Value:'ascii' codec can't decode byte 0xb4 in position
> 0:
> ordinal not in range(128)
> Exception Location: /usr/local/lib/python2.5/site-packages/textile.py
> in glyphs, line 2418
>
> My textile settings are
> # Set your encoding here.
> ENCODING = 'utf8'
>
> # Output? Non-ASCII characters will be automatically
> # converted to XML entities if you choose ASCII.
> OUTPUT = 'utf8'
>
> I tried changing my OUTPUT to ascii in textile but got the same error,
> so to me it looks like the form is sending a unicode
> series of bytes to textile which it can't understand.
>
> One way around this is to manipulate the self.summary prior to passing
> it to textile, like this.
>
> self.body = self.body.decode('utf-8')
> self.body = self.body.encode('ascii', 'ignore')
>
> This forces the passing of ascii to textile and it likes that alot,
> and works.
>
> But if a user now copies and pastes the dreaded apostrophe form word
> or another special character unique to word,
> it fails with this error.
>
> Exception Value:'ascii' codec can't encode character u'\u2019' in
> position 5: ordinal not in range(128)
> Exception Location: /usr/local/lib/python2.5/encodings/utf_8.py in
> decode, line 16
>
>
> If I run the super save earlier in the save definition after removing
> the textiling of the body section, and then
> call the data out of the database further down in the save definition,
> and then save it again like this
>
> e = Event.objects.get(id=new_id)
> if e.body:
> e.body_html = textile.textile(e.body)
> super(Event, e).save()
>
> It all works fine, no encoding or decoding needed for pasted
> apostrophes or anything.
>
> Here's the paste of the relevant part of the form with certain
> sections commented out so you can see what I mean.
>
> http://pastie.textmate.org/71702
>
> I found this on the google groups form Ivan Sagalev
> To summarizes: your storage (a database) and your input/output (the
> web)
> really should use utf-8 to avoid problems with "strange" characters.
> If
> you deal internally with unicode (which newforms produce for you) then
> for now you should explicitly encode from it to utf-8 until Django
> starts doing it automatically.
>
> I've also been reading this thread on the google developers group, and
> I'm now completely confused as to what is going on.
>
> unicode issues in multiple tickets
>
> If anyone can tell me if there is some current status on this, or how
> it works right now I'd be really grateful. If I have to encode and
> decode then I
> don't mind, not much anyway :-)
>
>
--~--~-~--~~~---~--~~
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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
textile mysql unicode and newforms
Hello everyone
I'm running django from the trunk, so using the most up to date
version, python 2.5 with PyTextile 2.0.10.
mysql5.0.2 with all settings to utf-8 and django content type is utf-8
I'm overwriting the save command on events using newforms, we're
textiling the input for an html field, here's what I mean.
def save(self):
import textile
if self.body:
self.body_html = textile.textile(self.body)
super(Event, self).save()
it fails with this error
Exception Value:'ascii' codec can't decode byte 0xb4 in position 0:
ordinal not in range(128)
Exception Location: /usr/local/lib/python2.5/site-packages/textile.py
in glyphs, line 2418
My textile settings are
# Set your encoding here.
ENCODING = 'utf8'
# Output? Non-ASCII characters will be automatically
# converted to XML entities if you choose ASCII.
OUTPUT = 'utf8'
I tried changing my OUTPUT to ascii in textile but got the same error,
so to me it looks like the form is sending a unicode
series of bytes to textile which it can't understand.
One way around this is to manipulate the self.summary prior to passing
it to textile, like this.
self.body = self.body.decode('utf-8')
self.body = self.body.encode('ascii', 'ignore')
This forces the passing of ascii to textile and it likes that alot,
and works.
But if a user now copies and pastes the dreaded apostrophe form word
or another special character unique to word,
it fails with this error.
Exception Value:'ascii' codec can't encode character u'\u2019' in
position 5: ordinal not in range(128)
Exception Location: /usr/local/lib/python2.5/encodings/utf_8.py in
decode, line 16
If I run the super save earlier in the save definition after removing
the textiling of the body section, and then
call the data out of the database further down in the save definition,
and then save it again like this
e = Event.objects.get(id=new_id)
if e.body:
e.body_html = textile.textile(e.body)
super(Event, e).save()
It all works fine, no encoding or decoding needed for pasted
apostrophes or anything.
Here's the paste of the relevant part of the form with certain
sections commented out so you can see what I mean.
http://pastie.textmate.org/71702
I found this on the google groups form Ivan Sagalev
To summarizes: your storage (a database) and your input/output (the
web)
really should use utf-8 to avoid problems with "strange" characters.
If
you deal internally with unicode (which newforms produce for you) then
for now you should explicitly encode from it to utf-8 until Django
starts doing it automatically.
I've also been reading this thread on the google developers group, and
I'm now completely confused as to what is going on.
unicode issues in multiple tickets
If anyone can tell me if there is some current status on this, or how
it works right now I'd be really grateful. If I have to encode and
decode then I
don't mind, not much anyway :-)
--~--~-~--~~~---~--~~
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 from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
