django-templatesadmin - Project Hosting on Google Code

Project Home

Earlier this year Aug 08, 2009 issue 11 (Copy-on-Write Templates) Status changed by mahner.martin - Status: WontFix Status: WontFix Aug 08, 2009 issue 11 (Copy-on-Write Templates) commented on by mahner.martin - I'm not 100% satisfied with this idea. TemplatesAdmin should never been able to write files. (Except the backup thing). If you have a good solution for this, please fork the project on Github. I'm not 100% satisfied with this idea. TemplatesAdmin should never been able to write files. (Except the backup thing). If you have a good solution for this, please fork the project on Github. Aug 08, 2009 issue 10 (Edit Page Title Improvement) Status changed by mahner.martin - Status: WontFix Status: WontFix Aug 08, 2009 issue 10 (Edit Page Title Improvement) commented on by mahner.martin - I don't understand this completely. While I just refactored all the templates, please have a look on it. It's a bit easier now, you have one variable "template_path" that holds the absolute path and there is a templatetag "template_path" which has one option: the count of directories to show. So "/foo/bar/foo/bar/foo.html"\|template_path:"2" shows "foo/bar/foo.html" I don't understand this completely. While I just refactored all the templates, please have a look on it. It's a bit easier now, you have one variable "template_path" that holds the absolute path and there is a templatetag "template_path" which has one option: the count of directories to show. So "/foo/bar/foo/bar/foo.html"\|template_path:"2" shows "foo/bar/foo.html" Aug 08, 2009 issue 9 (Nitpick: Template nitpicks) Status changed by mahner.martin - Everything fixed in [master 5180f0d]. 1. Sorry thats odd. And I absolutely don't know how the \t get there :) 2,3,4: I've converted all templates to the actual Django1.1 admin structure by default. Templatesadmin was created in a time of the newforms-admin refactor so I didn't extented the templates. Works now for me properly. Status: Fixed Everything fixed in [master 5180f0d]. 1. Sorry thats odd. And I absolutely don't know how the \t get there :) 2,3,4: I've converted all templates to the actual Django1.1 admin structure by default. Templatesadmin was created in a time of the newforms-admin refactor so I didn't extented the templates. Works now for me properly. Status: Fixed Aug 08, 2009 issue 8 (Nitpick: Add periods to the ends of sentences.) Status changed by mahner.martin - Fixed in [master a2b1442] Status: Fixed Fixed in [master a2b1442] Status: Fixed Aug 08, 2009 issue 7 (Provide templatedir to templates) Status changed by mahner.martin - Status: Fixed Status: Fixed Aug 08, 2009 issue 7 (Provide templatedir to templates) Status changed by mahner.martin - Fixed in [master 75108c5] Status: Started Fixed in [master 75108c5] Status: Started Aug 08, 2009 issue 6 (Please use RequestContext) Status changed by mahner.martin - Fixed in [master bf90c52] Status: Fixed Fixed in [master bf90c52] Status: Fixed Aug 08, 2009 issue 5 (<script> contents are not marked as CDATA) Status changed by mahner.martin - Status: Fixed Status: Fixed Aug 08, 2009 issue 5 (<script> contents are not marked as CDATA) commented on by mahner.martin - Fixed in [master 826a908] Fixed in [master 826a908] Jul 30, 2009 issue 11 (Copy-on-Write Templates) reported by rlaager - I'd love to see this application take advantage of the fact that template directories are (generally) stacked. Imagine this: I have an application specific template directory at /srv/www/foo/templates. I also have Django installed at /usr/share/django. Thus, I might have a read-only template at /usr/share/django/contrib/admin/templates/change_list.html. If I click on that (and /srv/www/foo/templates/admin/change_list.html does not already exist), I'd like to be able to edit it and save it. When I click save, if the file was actually modified, it would be written to /srv/www/foo/templates/admin/change_list.html, creating the admin directory if necessary. Why? I could then modify my templatesadmin overview.html template to present a flat list of templates without regard to their writability. I'd be able to see and edit every template from one list. Right now, I have to either remember that templates are structured and look in each directory in turn, or copy all the templates into my project up front. I'd love to see this application take advantage of the fact that template directories are (generally) stacked. Imagine this: I have an application specific template directory at /srv/www/foo/templates. I also have Django installed at /usr/share/django. Thus, I might have a read-only template at /usr/share/django/contrib/admin/templates/change_list.html. If I click on that (and /srv/www/foo/templates/admin/change_list.html does not already exist), I'd like to be able to edit it and save it. When I click save, if the file was actually modified, it would be written to /srv/www/foo/templates/admin/change_list.html, creating the admin directory if necessary. Why? I could then modify my templatesadmin overview.html template to present a flat list of templates without regard to their writability. I'd be able to see and edit every template from one list. Right now, I have to either remember that templates are structured and look in each directory in turn, or copy all the templates into my project up front. Jul 30, 2009 issue 10 (Edit Page Title Improvement) reported by rlaager - I'd like to see the title on the edit page be the "template path" (i.e. "admin/edit_inline/tabular.html". Right now, I get "edit_inline/tabular.html". Likewise, I get "templates/index.html" instead of "index.html" for something at the top level. To implement this, something would have to look at the list of template directories until it found the one that matched the start of the path of the file being edited and then chop that much off. I'd like to see the title on the edit page be the "template path" (i.e. "admin/edit_inline/tabular.html". Right now, I get "edit_inline/tabular.html". Likewise, I get "templates/index.html" instead of "index.html" for something at the top level. To implement this, something would have to look at the list of template directories until it found the one that matched the start of the path of the file being edited and then chop that much off. Jul 30, 2009 issue 9 (Nitpick: Template nitpicks) reported by rlaager - If you're willing to commit a fix for any/all of these items, feel free to ask me to generate a patch. 1. The default templates have some stray end-of-line whitespace, which made for spurious diffs when I was working. I'd recommend something like this to fix them: for i in templatesadmin/templates/templatesadmin/.html ; do sed -i "s\|[[:space:]]\+\|\|" $i ; done 2. The breadcrumbs block in the templates is actually called breadcumbs (no second r). See also #3 next. 3. The breadcrumbs in the default template are defined like this: <div class="breadcrumbs">{% block breadcumbs %}{% endblock %}</div> This creates additional work if you're trying to inherit from admin/base.html. Would it be possible to define it like this instead (note the corrected typo from #2): {% block breadcrumbs %}{% endblock %} Then the <div class="breadcrumbs"> bit could be moved into the child templates, which would mean less changes in the child templates if a user wanted templatesadmin/base.html to inherit from admin/base.html 4. Similar to #3, could the "main" block be renamed to "content"? This again would mean less changes to the child templates if a user wanted templatesadmin/base.html to inherit from admin/base.html If you're willing to commit a fix for any/all of these items, feel free to ask me to generate a patch. 1. The default templates have some stray end-of-line whitespace, which made for spurious diffs when I was working. I'd recommend something like this to fix them: for i in templatesadmin/templates/templatesadmin/.html ; do sed -i "s\|[[:space:]]\+\|\|" $i ; done 2. The breadcrumbs block in the templates is actually called breadcumbs (no second r). See also #3 next. 3. The breadcrumbs in the default template are defined like this: <div class="breadcrumbs">{% block breadcumbs %}{% endblock %}</div> This creates additional work if you're trying to inherit from admin/base.html. Would it be possible to define it like this instead (note the corrected typo from #2): {% block breadcrumbs %}{% endblock %} Then the <div class="breadcrumbs"> bit could be moved into the child templates, which would mean less changes in the child templates if a user wanted templatesadmin/base.html to inherit from admin/base.html 4. Similar to #3, could the "main" block be renamed to "content"? This again would mean less changes to the child templates if a user wanted templatesadmin/base.html to inherit from admin/base.html Jul 30, 2009 issue 8 (Nitpick: Add periods to the ends of sentences.) reported by rlaager - The attached patch adds periods to the ends of two complete sentences. The attached patch adds periods to the ends of two complete sentences. Jul 30, 2009 issue 7 (Provide templatedir to templates) reported by rlaager - I wanted to group my templates not by parent directory but by template dir. In other words, if my application is overriding admin/... and templateadmin/..., instead of seeing two headings on the overview page, I'd see only one. I was able to do this in a template. If you'd like me to provide that diff, please let me know. Either way, the attach patch was required so the view would provide the templatedir to the template. If you'd like to rename the variable, that's fine by me. :) I wanted to group my templates not by parent directory but by template dir. In other words, if my application is overriding admin/... and templateadmin/..., instead of seeing two headings on the overview page, I'd see only one. I was able to do this in a template. If you'd like me to provide that diff, please let me know. Either way, the attach patch was required so the view would provide the templatedir to the template. If you'd like to rename the variable, that's fine by me. :) Jul 30, 2009 issue 6 (Please use RequestContext) reported by rlaager - django-templatesadmin should use RequestContext when possible so that overriden templates can rely on variables set by context processors. The attached patch fixes this issue for me. django-templatesadmin should use RequestContext when possible so that overriden templates can rely on variables set by context processors. The attached patch fixes this issue for me. Jul 30, 2009 issue 5 (<script> contents are not marked as CDATA) reported by rlaager - My project has a default content-type of application/xhtml+xml when the browser supports it. The JavaScript code in django-templatesadmin is not marked as CDATA, so the ampersand breaks page loading. Given the page claims to be XHTML, I figured the attached patch was the correct fix. My project has a default content-type of application/xhtml+xml when the browser supports it. The JavaScript code in django-templatesadmin is not marked as CDATA, so the ampersand breaks page loading. Given the page claims to be XHTML, I figured the attached patch was the correct fix. Older Dec 12, 2008 issue 4 (bug in views.py causes content lose in templates) Status changed by mar...@mahner.org - This has been fixed, I hope we have no problems longer. Thank you! :) Status: Fixed This has been fixed, I hope we have no problems longer. Thank you! :) Status: Fixed Dec 12, 2008 issue 3 (hg commit hook) Status changed by mar...@mahner.org - Status: Fixed Status: Fixed Dec 12, 2008 issue 3 (hg commit hook) commented on by mar...@mahner.org - Finally I've integrated it to the mainline :) Thank you!!! Finally I've integrated it to the mainline :) Thank you!!! Sep 22, 2008 issue 3 (hg commit hook) Status changed by mar...@mahner.org - Status: Accepted Status: Accepted Sep 22, 2008 issue 4 (bug in views.py causes content lose in templates) Status changed by mar...@mahner.org - Status: Accepted Status: Accepted Sep 22, 2008 issue 3 (hg commit hook) commented on by mar...@mahner.org - Sorry for delay. I'm currently getting familiar with mercurial to check this. Sorry for delay. I'm currently getting familiar with mercurial to check this. Sep 22, 2008 issue 4 (bug in views.py causes content lose in templates) reported by v.oostveen - lines 169 in views.py states: # strip \n at end of file. In practice this line just deleted the last character. Even if it isn't a \n. Or if it's an \r\n it leaves an \r. (And i was wondering why a lot of my templates suddently ended with </body></ instead of </body></html>) A solution could be using content.rstrip() as in the applied patch. But another way could be to use content.rstrip("\n") though in that case one should also check if it's DOS/Unix or MAC style line ending as all these cases one should rstrip on different things. The default rstrip() would remove all whitespace and line-endings from the end of the string. lines 169 in views.py states: # strip \n at end of file. In practice this line just deleted the last character. Even if it isn't a \n. Or if it's an \r\n it leaves an \r. (And i was wondering why a lot of my templates suddently ended with </body></ instead of </body></html>) A solution could be using content.rstrip() as in the applied patch. But another way could be to use content.rstrip("\n") though in that case one should also check if it's DOS/Unix or MAC style line ending as all these cases one should rstrip on different things. The default rstrip() would remove all whitespace and line-endings from the end of the string. Sep 18, 2008 issue 3 (hg commit hook) commented on by v.oostveen - updated version this one works correctly :) some bits and pieces are still a little ugly code wise. (like the extraction of the path within template_path) there two things that i think will be important to add. 1) auto add template if it isn't in the repository already. (it should be there already since you cannot 'add' a template online. but it could happen) 2) add some extra try-except's or checks for mod_wsgi. (sometimes mercurial api has a tendency to try and open stdout/stderr which breaks on mod_wsgi) updated version this one works correctly :) some bits and pieces are still a little ugly code wise. (like the extraction of the path within template_path) there two things that i think will be important to add. 1) auto add template if it isn't in the repository already. (it should be there already since you cannot 'add' a template online. but it could happen) 2) add some extra try-except's or checks for mod_wsgi. (sometimes mercurial api has a tendency to try and open stdout/stderr which breaks on mod_wsgi) Sep 10, 2008 r24 (Merge branch 'master' into svn ) committed by mar...@mahner.org - Merge branch 'master' into svn Merge branch 'master' into svn Sep 10, 2008 r23 (Fixed security flaw. What a sh. ) committed by mar...@mahner.org - Fixed security flaw. What a sh. Fixed security flaw. What a sh**. Sep 09, 2008 r22 (Merge branch 'master' into svn Conflicts: .gitignore ) committed by mar...@mahner.org - Merge branch 'master' into svn Conflicts: .gitignore Merge branch 'master' into svn Conflicts: .gitignore Sep 09, 2008 issue 3 (hg commit hook) changed by mar...@mahner.org - Status: Started Labels: Type-Enhancement Priority-Low −Type-Defect −Priority-Medium Status: Started Labels: Type-Enhancement Priority-Low −Type-Defect −Priority-Medium Sep 09, 2008 r21 (Updated to version v0.5 ) committed by mar...@mahner.org - Updated to version v0.5 Updated to version v0.5 Sep 09, 2008 issue 2 (views.py:174 has one key to many for formatting) Status changed by mar...@mahner.org - Status: Fixed Status: Fixed Sep 09, 2008 issue 1 (templatesadmin/edit.html contains german string) Status changed by mar...@mahner.org - Thank you v.oostveen. :-) Changed that string and streamlined all the other strings. German and english locales are now included. Status: Fixed Thank you v.oostveen. :-) Changed that string and streamlined all the other strings. German and english locales are now included. Status: Fixed Sep 09, 2008 r20 (Fixed issue 1, 2. Streamlined all translation strings and ad...) committed by mar...@mahner.org - Fixed issue 1 , 2. Streamlined all translation strings and added locales for English and German. Fixed issue 1 , 2. Streamlined all translation strings and added locales for English and German. Sep 09, 2008 r19 (Copy from my git-repository. Version 0.4-stable. I hate git-...) committed by mar...@mahner.org - Copy from my git-repository. Version 0.4-stable. I hate git-svn. Copy from my git-repository. Version 0.4-stable. I hate git-svn. Sep 09, 2008 r18 (Merge branch 'master' of git@github.com:bartTC/templatesadmi...) committed by mar...@mahner.org - Merge branch 'master' of git@github.com:bartTC/templatesadmin Merge branch 'master' of git@github.com:bartTC/templatesadmin Sep 09, 2008 r17 (Removed hidden files. ) committed by mar...@mahner.org - Removed hidden files. Removed hidden files. Sep 09, 2008 r16 (Merge branch 'master' of git@github.com:bartTC/templatesadmi...) committed by mar...@mahner.org - Merge branch 'master' of git@github.com:bartTC/templatesadmin Merge branch 'master' of git@github.com:bartTC/templatesadmin Sep 09, 2008 r15 (Removed hidden files. ) committed by mar...@mahner.org - Removed hidden files. Removed hidden files. Sep 09, 2008 r14 (Merge branch 'master' of git@github.com:bartTC/templatesadmi...) committed by mar...@mahner.org - Merge branch 'master' of git@github.com:bartTC/templatesadmin Merge branch 'master' of git@github.com:bartTC/templatesadmin Sep 09, 2008 r13 (Removed all files for upcoming git-svn sync :) ) committed by mar...@mahner.org - Removed all files for upcoming git-svn sync :) Removed all files for upcoming git-svn sync :) Sep 09, 2008 r12 (Applied new directory structure from git repository. Version...) committed by mar...@mahner.org - Applied new directory structure from git repository. Version 0.4-stable Applied new directory structure from git repository. Version 0.4-stable Sep 09, 2008 r11 (Removed old directory structore for new one. ) committed by mar...@mahner.org - Removed old directory structore for new one. Removed old directory structore for new one. Sep 08, 2008 issue 3 (hg commit hook) commented on by v.oostveen - sorry there's still a problem in there somewhere... will fix it as soon as i can sorry there's still a problem in there somewhere... will fix it as soon as i can Sep 08, 2008 issue 3 (hg commit hook) commented on by v.oostveen - updated, fixes some issues with template directories and hg... maybe this could be handled better then looping through all TEMPLATE_DIRS... updated, fixes some issues with template directories and hg... maybe this could be handled better then looping through all TEMPLATE_DIRS... Sep 08, 2008 issue 3 (hg commit hook) reported by v.oostveen - attach patch adds an hgcommithook in similar style to the gitcommithook. attach patch adds an hgcommithook in similar style to the gitcommithook. Sep 08, 2008 issue 2 (views.py:174 has one key to many for formatting) reported by v.oostveen - attached patch will use: message=_(u'Template \'%s\' has not been saved! Reason: %s' % (path, e)) instead of: message=_(u'Template \'%s\' has not been saved! Reason: %s' % (template_path, path, e)) attached patch will use: message=_(u'Template \'%s\' has not been saved! Reason: %s' % (path, e)) instead of: message=_(u'Template \'%s\' has not been saved! Reason: %s' % (template_path, path, e)) Sep 08, 2008 issue 1 (templatesadmin/edit.html contains german string) reported by v.oostveen - i expect this should be english and converted to a localized language by the trans tag. attached patch translates the word 'sichern' to 'save'. on related note; i had some trouble running makemessages on the code base. {{{ Error: errors happened while running xgettext on views.py ./views.py:174: warning: 'msgid' format string with unnamed arguments cannot be properly localized: The translator cannot reorder the arguments. Please consider using a format string with named arguments, and a mapping instead of a tuple for the arguments. }} i expect this should be english and converted to a localized language by the trans tag. attached patch translates the word 'sichern' to 'save'. on related note; i had some trouble running makemessages on the code base. {{{ Error: errors happened while running xgettext on views.py ./views.py:174: warning: 'msgid' format string with unnamed arguments cannot be properly localized: The translator cannot reorder the arguments. Please consider using a format string with named arguments, and a mapping instead of a tuple for the arguments. }} Sep 08, 2008 r10 (Templatesadmin v0.4. This is the latest stable version out o...) committed by mar...@mahner.org - Templatesadmin v0.4. This is the latest stable version out of my git repository. Now with "edithooks" and "hide readonly files" support. Templatesadmin v0.4. This is the latest stable version out of my git repository. Now with "edithooks" and "hide readonly files" support. Sep 08, 2008 r9 (Templatesadmin v0.4. This is the latest stable version out o...) committed by mar...@mahner.org - Templatesadmin v0.4. This is the latest stable version out of my git repository. Now with "edithooks" and "hide readonly files" support. Templatesadmin v0.4. This is the latest stable version out of my git repository. Now with "edithooks" and "hide readonly files" support.

issue 9 (Nitpick: Template nitpicks) reported by rlaager - If you're willing to commit a fix for any/all of these items, feel free to ask me to generate a patch. 1. The default templates have some stray end-of-line whitespace, which made for spurious diffs when I was working. I'd recommend something like this to fix them: for i in templatesadmin/templates/templatesadmin/*.html ; do sed -i "s|[[:space:]]\+||" $i ; done 2. The breadcrumbs block in the templates is actually called breadcumbs (no second r). See also #3 next. 3. The breadcrumbs in the default template are defined like this: <div class="breadcrumbs">{% block breadcumbs %}{% endblock %}</div> This creates additional work if you're trying to inherit from admin/base.html. Would it be possible to define it like this instead (note the corrected typo from #2): {% block breadcrumbs %}{% endblock %} Then the <div class="breadcrumbs"> bit could be moved into the child templates, which would mean less changes in the child templates if a user wanted templatesadmin/base.html to inherit from admin/base.html 4. Similar to #3, could the "main" block be renamed to "content"? This again would mean less changes to the child templates if a user wanted templatesadmin/base.html to inherit from admin/base.html

If you're willing to commit a fix for any/all of these items, feel free to ask me to generate a patch. 1. The default templates have some stray end-of-line whitespace, which made for spurious diffs when I was working. I'd recommend something like this to fix them: for i in templatesadmin/templates/templatesadmin/*.html ; do sed -i "s|[[:space:]]\+||" $i ; done 2. The breadcrumbs block in the templates is actually called breadcumbs (no second r). See also #3 next. 3. The breadcrumbs in the default template are defined like this: <div class="breadcrumbs">{% block breadcumbs %}{% endblock %}</div> This creates additional work if you're trying to inherit from admin/base.html. Would it be possible to define it like this instead (note the corrected typo from #2): {% block breadcrumbs %}{% endblock %} Then the <div class="breadcrumbs"> bit could be moved into the child templates, which would mean less changes in the child templates if a user wanted templatesadmin/base.html to inherit from admin/base.html 4. Similar to #3, could the "main" block be renamed to "content"? This again would mean less changes to the child templates if a user wanted templatesadmin/base.html to inherit from admin/base.html

Earlier this year

Older