CharField vs. CharField
Hi, I think it is bad, that there are two CharField classes. One for OR-Mapping and one for HTML (new)forms. Why not change the HTML classes to ...InputField? Thomas -- Thomas Güttler, http://www.tbz-pariv.de/ Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917 TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Attributes for ManyToMany
Hi, How can you add attributes to ManyToMany Relations? Given the example: http://www.djangoproject.com/documentation/models/many_to_many/ Publication -- N:M -- Article How can you store the page number of the published article? Thomas -- Thomas Güttler, http://www.tbz-pariv.de/ Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917 TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Re: CharField vs. CharField
Am Freitag, 6. Juli 2007 10:41 schrieb Malcolm Tredinnick: > On Fri, 2007-07-06 at 10:35 +0200, Thomas Güttler wrote: > > Hi, > > > > I think it is bad, that there are two CharField classes. ... > Any particular reason you only want to change CharField? Or any > technical reason why you think the current situation is bad? No, this was just an example. I think the base class (and the used postfix) should be changed to InputField. But nevermind I can live with the current name, too. Thomas -- Thomas Güttler, http://www.tbz-pariv.de/ Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917 TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
newforms: I18N (Date und Decimal)
Hi, I read the source of the newforms module, but there seems no easy way to get i18n for dates and decimals. widget.py: -- class Input(Widget): def render(self, name, value, attrs=None): if value is None: value = '' final_attrs = self.build_attrs(attrs, type=self.input_type, name=name) if value != '': final_attrs['value'] = force_unicode(value) # Only add the 'value' attribute if a value is non-empty. return u'' % flatatt(final_attrs) - in render() the decimal object becomes a string. Maybe the Widget class should have a value2str method, which cares for this. The constructor of models.DecimalField could take the decimal separator as keyword argument and give his Input Widget this method. Of course the to_python() method must be changed, too. Is someone already working on this? Thomas -- Thomas Güttler, http://www.tbz-pariv.de/ Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917 TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Traceback of endless loop
Hi, how can you get a traceback if the script is inside a endless loop. Standalone python apps give you this by sending SIGINT. But this does not work with mod_python or the builtin webserver. Any hints? Thomas -- Thomas Güttler, http://www.tbz-pariv.de/ Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917 TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
FileField: id of row (like strftime)
Hi, the upload_to argument to FileField evals strftime formatting. I would like to have the ID of the belonging row. Example: One MyObject has N attachments. class Attachment(models.Model): file=models.FileField(upload_to="%(myobject_id)s") myobject=models.ForeignKey(MyObject) This way all attachments of one MyObjects are in the same directory. This would be very nice. Thomas -- Thomas Güttler, http://www.tbz-pariv.de/ Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917 TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
No tests for newforms
Hi, I was told to include a test in my newforms patch: http://code.djangoproject.com/ticket/5335 I couldn't find any tests for newforms. Am I blind? Thomas -- Thomas Güttler, http://www.tbz-pariv.de/ Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917 TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Get all related instances
Hi, since obj.delete() uses "on delete cascade", I want to see first which instances still have a reference to obj (and would get deleted). I write this little helper. Comments welcome: def all_related_instances(instance): """ Return all instances which have a relation to this instance. You can check this list before instance.delete(), since all returned instances would get deleted, too (ON DELETE CASCADE) """ assert isinstance(instance, models.Model) meta=instance._meta related=[] for related_object in meta.get_all_related_objects()+meta.get_all_related_many_to_many_objects(): attr = getattr(instance, related_object.get_accessor_name()) related.extend(attr.all()) return related -- Thomas Güttler, http://www.tbz-pariv.de/ Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917 TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
settings.py gets imported twice
Hi,
settings.py gets imported twice. This is bad, if you want to
set up the logging module, since you register the handler twice
and you get all log messages twice.
Here are the stacktraces I created for debugging this:
===> python manage.py test admin
import logconfig
Traceback (most recent call last):
File "manage.py", line 12, in ?
import settings # Assumed to be in the same directory.
Traceback (most recent call last):
File "manage.py", line 19, in ?
execute_manager(settings)
File "/localhome/user/myproject/django/core/management/__init__.py", line
277, in execute_manager
utility.execute()
File "/localhome/user/myproject/django/core/management/__init__.py", line
225, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/localhome/user/myproject/django/core/management/__init__.py", line
177, in fetch_command
self.project_directory)[subcommand]
File "/localhome/user/myproject/django/core/management/__init__.py", line 86,
in get_commands
for app_name in settings.INSTALLED_APPS:
File "/localhome/user/myproject/django/conf/__init__.py", line 28, in
__getattr__
self._import_settings()
File "/localhome/user/myproject/django/conf/__init__.py", line 57, in
_import_settings
self._target = Settings(settings_module)
File "/localhome/user/myproject/django/conf/__init__.py", line 83, in __init__
mod = __import__(self.SETTINGS_MODULE, {}, {}, [''])
File "/localhome/user/myproject/settings.py", line 147, in ?
This shnippet has a workaround:
http://www.djangosnippets.org/snippets/16/
(I have not tested it yet)
I think it would be better to avoid a second import.
Any hints?
Thomas
--
Thomas Güttler, http://www.tbz-pariv.de/
Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917
TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth
Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: validating fields with newforms - part 2
Am Freitag, 23. November 2007 14:37 schrieb Wolfram Kriesing:
> this has two drawbacks:
> 1) the URL is validated in the "wrong" place (in clean() instead of
> clean_url())
> 2) the error, if one occurs, is not assigned to the errors['url']
> but errors['__all__']
>
> fixing 2) would also be hackish imho
I had this problem, too.
http://code.djangoproject.com/ticket/5335
In clean() you can add the message to errors['url'] like this:
errorlist=self.errors.get(name)
if errorlist==None:
errorlist=ErrorList()
self.errors[name]=errorlist
errorlist.append(message)
Since this is not nice, I wrote a small patch inclusive tests and
documentation:
http://code.djangoproject.com/ticket/5335
Please leave a message there if you like / don't like it.
With the patch you can add the message like this:
class StartEnd(Form):
start = IntegerField()
end = IntegerField()
def clean(self):
start, end = self.cleaned_data.get('start'),
self.cleaned_data.get('end')
if start!=None and end!=None and start>end:
self.errors.append('start', u'start must be smaller than end')
return self.cleaned_data
Thomas
--
Thomas Güttler, http://www.tbz-pariv.de/
Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917
TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth
Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---
Re: Out of range value
Am Montag, 26. November 2007 14:28 schrieb Nader: > Hallo, > > I have a model in which one field value can be a large integer value > (from 2^0=1 till 2^32=4294967296). ... > If want to try to input the 2^31 or 2^32 I get the next 'Warning': > Out of range value adjusted for column 'poolMaskID' at row 1! There is a patch which works for me (postgres): http://code.djangoproject.com/ticket/399 -- Thomas Güttler, http://www.tbz-pariv.de/ Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917 TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
SCGI (or other) graceful restart
Hi, up to now I use SCGI and flup. There are some issues: - flup does not provide an init script. No big problem: I wrote my own. - flup is not developed actively: The author does not use it anymore. - There is no graceful restart (Restarting SCGI server with kill produces internal server errors). Graceful restart is the bigest problem for me. During a restart the site should stop serving requests for some seconds, but the users should not see errors messages. I want an external server, so mod_python is not an option. Access to server goes through Apache2. How do you handle this? I think about these solutions: - I heard that mod_wsgi has a server mode. Need to look at it - Use mod_proxy and run lighttpd. Never used it, but I think it has built in SCGI support. - Use FastCGI. But somehow I want to avoid it, because SCGI is simple and easy to understand. - patch flup to support graceful restart. Thomas -- Thomas Güttler, http://www.tbz-pariv.de/ Bernsdorfer Str. 210-212, 09126 Chemnitz, Tel.: 0371/5347-917 TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~--~~~~--~~--~--~---
Deploying CSS/JS with pip
Hi, I like one part of fanstatic[1]: You can create dependencies to JS modules. The JS files are available on pypi and this way installing them is very easy. example: You can have a requirement on "js.jquery_datatables" in you requirements.txt file: https://pypi.python.org/pypi/js.jquery_datatables This makes automated deployment very easy. There is a django integration, but it looks dead. There was no development during the last months. There are some parts of fanstatic which are not need if you use django, but the js/css packages could be useful for us. Does anybody use fanstatic together with django? My goal is to easy the automated deployment. How do you handle the dependency on external resources like jquery libraries? Do you store a tgz file inside your source code repository? Regards, Thomas Güttler [1] http://www.fanstatic.org/en/latest/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Middleware + Transactions
Dear Django developers, we currently have the following issue when upgrading from Django 1.5 to Django 1.6: https://github.com/etianen/django-reversion/issues/268 As it seems, since Django 1.6, middlewares are not supposed to be executed within the same transaction as the view function is. We would like to understand why that is the default behavior now and we are supposed to re-organize our code base to work with that changes. What is the rationale behind middlewares not being executed within the same transaction as the view function? Furthermore, decorating all view functions as suggested here http://django-reversion.readthedocs.org/en/latest/api.html#revisionmiddleware is quite not feasible for large projects. Especially given that reversion is not the only middleware that needs to be executed within the same transaction as the view function. It would basically mean that each view function needs to be decorated potentially n times. We understand that transactions might effect performance, thus lesser transactions being in a transaction means faster execution. However, shouldn't there be the possibility to include distinct middlewares into the view transaction? Regards, Thomas Güttler -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54CB8E78.7060604%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
App for storing ChangeLogs in database
Hi, we want to make the changes in our applications better visible for our customers. We use several git repos: - foo_customer: Here settings.py lives. It is quite small. - foo_core: Central part of our application. The same code gets used for several customers. - foo_plugin_bar: Just an example. There are several optional plugins. Here is my current road map: A nice interface for the customer implies: The changes need to be stored in the database. This makes it easy to sort and filter the changes. The origins of the changes are the git repos. I don't want to show the customer our commit messages. I want a manual step from commits to ChangeLog. But that's ok. This could be optimized later. Use Case: A developer merged a feature branch into foo_core. He needs to create a ChangeLog. The ChangeLog gets stored into the git repo, but on the next deploy some tool reads the new changes and puts them into the database. ChangeLogs need to be tag-able: You can apply tags like "performance-improvement" "new-feature" "bug-fix". I searched the web, but could not find something like this. Before I start to code, I want to get some feedback: What do you think? How do you handle your ChangeLogs. PS: Our customers are normal (non programmers) people. They don't want to see diffs or commit messages they don't understand. -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54D4B260.8030402%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: App for storing ChangeLogs in database
Am 07.02.2015 um 00:31 schrieb Russell Keith-Magee: ... To me - it sounds like something pretty closely tied to your own development process, branching policies, and customer relationships. I have no difficulty seeing how this could be implemented as a Django app - and a fairly trivial one at that - your average change log is really not much more than: class Change(Model): message = TextField() created = DateTimeField() change_type = IntegerField(choices=CHANGE_TYPES) How do you handle your ChangeLogs. Through a process that is completely unrelated to the commit process. For me, minimising the number of customer communications is key. I have difficulty getting users to read and comprehend the notifications I *do* send them - sending them complete change logs would be overkill, and would result in important messages (like YOU NEED TO UPDATE YOUR ACCOUNT SETTINGS OR THINGS WILL STOP WORKING) being ignored. As it is, these messages are often ignored, and I need to follow up with individual users. My audience would gain nothing from a fine grained commit log telling them about every bug fix or performance improvement. They just want the system to work. If it doesn't work, they email me, and they'd like to know when it is fixed. To that end, I might not even send out a notification for a new *feature*, unless that feature is something that has been requested by them, or it will impact on the way they're using the system. Thank you for your reply. That's the same here: The customer just want the system to work. And I don't want to waste our customers time with announcements like "on page ... we improved the ... input field. You can do ... now". The are not interested most of the time. But sometimes they are. And if they are interested, the customers should be able to get the changes without talking to developers. And the changes should be aggregated to human non programmer readable sentences. The ChangeLog I have in mind aggregates information of commit messages and tickets. This aggregation needs to done by a human. It can't be automated, and I think it is worth the effort. Regards, Thomas Güttler -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54D8A438.1080704%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
cache.set(key, timeout=0)
I want the cache timeout to be configurable: - N --> number of seconds - None --> cache for every - 0 --> do not cache at all. I am not sure if timeout=0 really does what I want. I could not find it explicitly in the docs: https://docs.djangoproject.com/en/1.7/topics/cache/#basic-usage I don't want to put a lot of "if default_cache_timeout==0: " into my code. It would be nice if django would support this. This would make my code simpler. Does cache.set(key, timeout=0) do no caching at all? If yes, shouldn't this be stated in the docs explicitly? Regards, Thomas Güttler -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54D9C6A3.9030506%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: Global access to request.user
Am 27.03.2015 um 15:49 schrieb Cal Leeming: There is a reason that state is passed around from method to method, rather than being stored as a global, because this is the correct way to do things. Is a threadlocal global state part of the correct way, or is it "evil"? However, it sounds like the architectural design of your code is flawed, as throwing around the request object indicates that you don't have modularity. It is legacy code. Complaining does help your soul for a short time. But after that moment it is the same code :-) If you only need the user object, then why not replace all instances of "request=request" with "user=request.user". Yes, that could be done. But it is not much better. I am still searching a for a "third" way. The alternative is to have some magic threadlocals which stores the current user, but this is a particularly disgusting way of writing code and I could not recommend it at all. It would be better if you could explain a little more about how/where this request object is being passed around, then we'd be in a better position to give you the correct advice. Example: You have an instance method to render one row of a search result (a custom paginator). One column of this row displays a link. Some users are allowed to follow the link, some are not. You need to check the (row level) permissions before displaying it as link or as plain text. The render_row() method is deep inside OOP python code. The method needs to know which user is logged in to return the correct result. Of course I could always return a hyperlink. And users which don't have the permission will see the permission denied page. But this is not user friendly. Can you understand this use case? Regards, Thomas Güttler -- Thomas Guettler, http://www.tbz-pariv.de/ Bernsdorfer Str. 210-212, 09126 Chemnitz TBZ-PARIV GmbH Geschäftsführer: Dr. Reiner Wohlgemuth Sitz der Gesellschaft: Chemnitz Registergericht: Chemnitz HRB 8543 -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/55157785.20505%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: Global access to request.user
Am 27.03.2015 um 17:16 schrieb Cal Leeming: Hmm this all sounds quite dirty :/ However if you absolutely want to have a global object, you could try something like [1], although I don't recommend it at all. There are some situations where your modelling needs request introspection, for example row level auditing, but these are very specific situations and most of the time it's just outright abuse/bad code. No, I don't want to use a global object. I am still searching for a way that I like. If you're using template tags and performing rendering within Django, then you are already doing things the wrong way [2], unless your application has a heavy SEO requirement. What is a better way? Sadly this is where the weaknesses of Django, and indeed many other web frameworks, start to appear. As such, you probably shouldn't be worrying too much about the "passing state around being ugly", because the code is already architecturally flawed and inherently ugly to start with. Also, abusing globals starts to get real ugly when you introduce co-routines and overall makes for much less readable code (imho). Yes, I think co-routines make this worse. Regards, Thomas Güttler -- -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/551BAE1B.2040605%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: Global access to request.user
Am 27.03.2015 um 19:05 schrieb Stephen J. Butler: On Fri, Mar 27, 2015 at 10:30 AM, Thomas Güttler wrote: You have an instance method to render one row of a search result (a custom paginator). One column of this row displays a link. Some users are allowed to follow the link, some are not. You need to check the (row level) permissions before displaying it as link or as plain text. The render_row() method is deep inside OOP python code. The method needs to know which user is logged in to return the correct result. Of course I could always return a hyperlink. And users which don't have the permission will see the permission denied page. But this is not user friendly. How important is it that the legacy code retain the same structure? This is not important. As long as the result does not change. You have the choice here to either break Django or refactor your legacy code. Doing the refactor is what will cause you the least headaches as you move forward (and as Django moves forward). What you really need to do here is move render_row into a template include or a template tag (which gets the template context, which includes user). That's the proper place for it IMHO in the MVC paradigm, which is the Django way. ok, this way is better than the current: pass around the context everywhere where the request gets passed around up to now. Headache makes the code which gets called outside the request-response cycle. For example cron jobs. Example: We create reports for users in cron jobs. Here we need a user object and have no context. Regards, Thomas Güttler -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/551BAFBD.8010804%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
setup.py for project?
Using a setup.py for reusable apps makes sense. This way you can share the code via a pypiserver. Our projects are very small. They don't have models, only config. With "project" I mean the small (in our case) git repo which holds settings.py urls.py. But does a setup.py make sense for the project? How do you manage your projects (not apps)? Regards, Thomas Güttler -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/551BB0C1.6000406%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: setup.py for project?
Am 02.04.2015 um 03:13 schrieb Ilya Kazakevich: Hello. What exactly are you trying to achieve? If you have some part of functionality that is interesting for other people/projects and hence should be shared via pypi, you should extract it as reusable app. Projects, how ever, are not reusable. If you need a fast way to install al project requirements on your new server, you need to use requirements.txt (and pep freeze). Some people use virtualization (vm images, vagrant, or even docker) to deploy "project" (with all environment including databases, daemons etc) on staing or production machines. Environment configuration engines like saltstack/chef/cfengine/puppet are also used. An excelent book "Continuous delivery" is all about "how do you deploy your code on production with one click". It may be interesting for you. I just checked my favourite book seller. There are many books about this topic. Which one do you recommend? Regards, Thomas Güttler -- -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/551D2071.2040201%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Warnings instead of only errors in Django Forms
Is there a solution to this? I want to display additional text next to a form field. There is a four years old question on stackoverflow[1], but the solution to use the message framework does not help me, since I want to see the additional text next to the form field. Message at the top of the page won't help me. I need a python solution (without templates), since the form rendering is done by a third party library. [1] http://stackoverflow.com/questions/2270550/warnings-or-even-info-messages-instead-of-only-errors-in-django Regards, Thomas -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/53EB260F.6010908%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: Install Django Apps via Admin Interface
Am 10.09.2014 um 11:07 schrieb Avraham Serour: you can't, you would need to write something yourself capable of doing this. that's sad. in any case why would you want to do that? Convenience. It would be great if some admin plugin could do this: Connect to pypi and list all available packages which can be installed into django ... I see a lot of **not DRY** docs in django packages: Over and over again the same instructions: Add "foo" to INSTALLED_APPS adding an app to a project may involve not only installing the python package and adding the app to INSTALLED_APPS, but also adding configurations to settings.py, running syncdb/migrate and reloading the instance. I guess django experts have a good solution for this small technical problem. Thomas -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5412BC60.2080705%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: Install Django Apps via Admin Interface
Am 12.09.2014 um 18:23 schrieb Collin Anderson: And you would expect that to happen just through admin? Would you trust your users really to do all that - basically giving full control what users installs to your system without discretion? Installing apps via the admin would be useful when the user is the same person as the sysadmin.\ However as we mentioned, Django really isn't architected for this. I could see Django-CMS creating a sub architecture that would allow for this sort of thing. Basically, you would need to create some sort of package of code that would work without getting added to INSTALLED_APPS. It would be nice if such a sub architecture would be outside of django-cms, to make it more reusable. Thomas -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54199A90.3030002%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Config: DB or git?
Hi, of course we separate data from code: - code belongs into version control (git) - data belongs into a database (postgres) But where does configuration belong? Since I am a developer I like version control. But the longer I think about this question, I think the perfect configuration for an app just contains one entry: How to connect to the DB. Sooner or later you want things to editable via an admin interface. And if you look at big systems like SAP. There is only very little config in files. I think config should be done in the database, not files. It is hard to accept this, since version control is great for files, and not so good for databases, but I think it is the way to go. What do you think? Thomas -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/542958FB.5010800%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: Config: DB or git?
I see configurable settings, like those in the settings module, as code settings, and those you would put in the DB as user customizable settings. The former are meant to be changed by developers and sys admins, and the latter by website users. In my opinion settings module changes are mostly related to staging or performance rather than user oriented. Apart from there are a number of interesting Django apps in Djangopackages [1] that allow you to put your settings in the DB. [1] -> https://www.djangopackages.com/grids/g/configuration/ Regards Thank you for this link. Unfortunately the feature "data store" is not evaluated up to now. But I created a feature request: https://github.com/pydanny/djangopackages/issues/293 Thomas -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/542A5407.1020500%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Exceptions in signal handlers pass silently
I just discovered, that exceptions in signal handlers pass silently. Is there a way to not silently ignore errors? >>> import this -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/542A6149.90309%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Including JS/CSS in reusable widget library
The way django handles static media works very well for js/css files which are included in the library. But if you want to build in external js/css files it gets ugly. For example nice django-selectable widget. Has a long documentation on how to include jquery-ui: http://django-selectable.readthedocs.org/en/latest/quick-start.html#including-jquery-jquery-ui I came across this, because we use django-selectable in one project with success, but it failed in an other. The reason was the missing jquery-ui js-files. Ain't there a better solution for this? Documentation like the above pages are good. But it is even better if there is a common way how to handle this in the django world. Thomas -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/542AA3F1.7030403%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: Exceptions in signal handlers pass silently
Am 01.10.2014 um 14:39 schrieb Collin Anderson:
use send() instead of send_robust().
I am sorry, I don't understand this answer. I subscribe to "post_init". I don't
send the
signal, I receive it.
Is there a way to tell django to use send() for signals?
.
I found this solution:
{{{
from django.dispatch import Signal
Signal.send_robust = Signal.send
}}}
Source:
http://giovanni.bajo.it/post/47207612849/djangos-signal-send-robust-is-broken-by-design
--
Thomas Güttler
http://thomas-guettler.de/
--
You received this message because you are subscribed to the Google Groups "Django
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/542D2DF6.5060505%40tbz-pariv.de.
For more options, visit https://groups.google.com/d/optout.
Re: Including JS/CSS in reusable widget library
Am 01.10.2014 um 14:44 schrieb Collin Anderson: I usually use "assets" (class Media) for including cdn hosted libraries. https://docs.djangoproject.com/en/dev/topics/forms/media/ Example: how can a reusable widget library tell that it needs jquery-ui? Up to now the only way I see is, that the reusable widget library includes jquery-ui in its assets (static files via Media). But if you use two or three reusable widget libraries on one page each widgets loads its own version of jquery-ui. Loading one js library several times is looking for trouble. If you just reuse the widget library in a commercial closed source environment, you can define fixed paths to libraries like jquery, jquery-ui, ... But this does not work for reuse in the open source world. I am missing something for a better reuse in the django world here. Unfortunately I don't see a solution today. But maybe some else does. Thomas -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/542D3149.9090902%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: Config: DB or git?
Am 01.10.2014 um 14:56 schrieb Collin Anderson: If you're a programmer or sysadmin, configuration should be done in files. If you're not a programmer or sysadmin, it should be done in the database. Why do you look the person for a decision like this? Wouldn't it be better to look at the data which gets configured here? I love git like most programmers love their version control system. But for most stuff config in DB is much better. example: INSTALLED_APPS Wouldn't it be really cool if you could add an app by pressing a button? Thomas -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/542D353D.7090803%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: Config: DB or git?
Am 02.10.2014 um 14:11 schrieb Tom Evans: On Thu, Oct 2, 2014 at 12:21 PM, Thomas Güttler wrote: Am 01.10.2014 um 14:56 schrieb Collin Anderson: If you're a programmer or sysadmin, configuration should be done in files. If you're not a programmer or sysadmin, it should be done in the database. Why do you look the person for a decision like this? Wouldn't it be better to look at the data which gets configured here? I love git like most programmers love their version control system. But for most stuff config in DB is much better. example: INSTALLED_APPS Wouldn't it be really cool if you could add an app by pressing a button? I have developed, maintained, managed and supported a generic ORM that stores all details about how things are configured - models, fields, classes, behaviours - in the DB for the past ten years, and I can tell you that, no, it is not really cool, it is a massive pain in the proverbial. Yes, you are right. Storing the ORM models in DB is too much. Thomas -- Thomas Güttler http://thomas-guettler.de/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/542D5946.8020706%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
True Model Inheritance
I know that there are several model inheritance extensions available: https://www.djangopackages.com/grids/g/model-inheritance/ But it is hard for me to decide which one to take. The most common solutions seem to be: django-model-utils django-polymorphic My use case is simple: This query should return instances of child classes: for obj in BaseClass.objects.filter(...) ... Which solution do you use, and why? Thomas -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5347E419.3050503%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
editable models (db schema) for admin (no developer)
Hi, I am a software developer and like the way django ORM defines the database (via models.py) very much. Unfortunately for a new project, we have the constraint, that the admin must be able to add some columns. The admin is not a developer, and he only uses a web interface. I don't want to make model.py files editable via an admin interface, since running migrations and all that does not fit into "web editable". Any hints how to solve this? Thomas -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/538DD465.3060300%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: editable models (db schema) for admin (no developer)
Am 03.06.2014 16:27, schrieb Erik Cederstrand: Den 03/06/2014 kl. 15.57 skrev Thomas Güttler : I am a software developer and like the way django ORM defines the database (via models.py) very much. Unfortunately for a new project, we have the constraint, that the admin must be able to add some columns. The admin is not a developer, and he only uses a web interface. I don't want to make model.py files editable via an admin interface, since running migrations and all that does not fit into "web editable". Are you *really* sure you want to do this? Monkey-patching running code, adding class attributes and inserting database columns on the fly to a production system isn't something recommended in textbooks. Try describing your situation a bit. Maybe you could use a key-value approach and m2m relations instead? I am sure: I don't want it. I guess you have read my post too fast. Another possibility is that you avoid editing models.py by creating the new database column manually using raw SQL, so Django doesn't know about it. Then override __getattr__ on the model so my_obj.extra_col_123 circumvents the ORM and fetches data by other means, or simply issue raw SQL when you need to access 'extra_col_123' in your code. Yes, this would be a solution. Thank you for your feedback. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/538DDCE5.2000108%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: editable models (db schema) for admin (no developer)
I found several solution here: http://stackoverflow.com/a/7934577/633961 Am 03.06.2014 15:57, schrieb Thomas Güttler: Hi, I am a software developer and like the way django ORM defines the database (via models.py) very much. Unfortunately for a new project, we have the constraint, that the admin must be able to add some columns. The admin is not a developer, and he only uses a web interface. I don't want to make model.py files editable via an admin interface, since running migrations and all that does not fit into "web editable". Any hints how to solve this? Thomas -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/538EF626.5010709%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
URLs: mymodel_id vs object_id vs pk ....
What is the best practice for named URL parameter which refer to a primary key of a model? I have seen many ways: - object_id - mymodel_id - pk - id - . example: urlpatterns = [ url(r'^article/(?P\d+)/$', 'article.view'), ... ] Up to now we used "mymodel_id" but it gets boring to type in "mymodel". This is a question about best practice: Which do you use (and why)? Related: https://docs.djangoproject.com/en/dev/topics/http/urls/#named-groups Thomas -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/538F19FF.1090209%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
Re: URLs: mymodel_id vs object_id vs pk ....
Thank you for answering my question. Unfortunately "slug" does not work in my context. My model does not have a "slug". It is like a ticket/issue system. There are several hundred of tickets each day. Thomas Güttler Am 04.06.2014 15:07, schrieb Thomas Güttler: What is the best practice for named URL parameter which refer to a primary key of a model? I have seen many ways: - object_id - mymodel_id - pk - id - . example: urlpatterns = [ url(r'^article/(?P\d+)/$', 'article.view'), ... ] Up to now we used "mymodel_id" but it gets boring to type in "mymodel". This is a question about best practice: Which do you use (and why)? Related: https://docs.djangoproject.com/en/dev/topics/http/urls/#named-groups Thomas -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/53903B4C.7070409%40tbz-pariv.de. For more options, visit https://groups.google.com/d/optout.
