Re: Admin UI Improvements for Ordered List Using Through Inline?
Check out grappelli: http://www.grappelliproject.com/
On Saturday, December 1, 2012 6:24:49 AM UTC-3, Andrew Brown wrote:
>
> Greetings,
>
> I'm hopeful someone can point me in the right direction to improve the
> admin UI for my app. I need to allow for the creation and display of an
> ordered list of books. I had no problem setting this up and editing the
> lists in the admin UI, but the UX for an admin leaves much to be desired.
>
> The two biggest issues are that books can be saved to the same position as
> books already on a list, and the admin always has to specify a position on
> the list for each book (rather than simply adding the most recent book to
> the end). Ideally books could even be dragged around and visually
> reordered. This is a pretty classic ordered-list scenario, so I'm hoping
> someone has already done some work to improve the admin UI for this case.
> Is anyone aware of anything that might help?
>
> The code I'm using in my app is below- it is dead simple and pretty much
> straight from the documentation. I have created two models for this
> purpose- Book and List, which are associated by a ListMember class using a
> through relationship.
>
> class Book(models.Model):
>
> title = models.CharField(max_length=200)
>
> class List(models.Model):
>
> books = models.ManyToManyField(Book, through="ListMember")
>
> class ListMember(models.Model):
>
> list = models.ForeignKey(List)
> book = models.ForeignKey(Book)
> position = models.IntegerField()
>
>
> Then in my admin code I've created BookAdmin, ListAdmin, and
> ListMemberInline. I've also included simplified code for these classes
> below.
>
> class ListMemberInline(admin.TabularInline):
>
> model = List.books.through
>
> class ListAdmin(admin.ModelAdmin):
>
> inlines = ['ListMemberInline',]
> excludes = ('books',)
>
> class BookAdmin(admin.ModelAdmin):
>
> inlines = ['ListMemberInline',]
>
> If anyone is aware of improvements to the admin UI for this case that I
> could reuse I would really appreciate a pointer in the right direction.
> Alternatively, guidance on how to improve this myself would also be very
> helpful.
>
> Thanks!
> Andrew
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/3swNLrI-vQYJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Re: Location of non-app-specific static files?
Check this out: https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#staticfiles-dirs I put a static folder in my project root where I put all the project specific (ant not app specific) static files. The folder's path is then added to STATICFILES_DIRS. But note that this static folder is different than STATIC_ROOT folder where the collectstatic management command collects all static files for deployment (https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-STATIC_ROOT) I separate them because the first one is checked into version control, while the second one is not. On Monday, November 5, 2012 5:53:33 AM UTC-3, Ryan wrote: > > That is not a bad idea as everything that is project specific, but not app > specific, would live in one place. > > Thanks, > > Ryan > > On Sunday, 4 November 2012 15:14:43 UTC, Xavier Ordoquy wrote: >> >> Hi, >> >> One thing I've seen - and adopted - is to have one application that >> contains the static files. >> It looks like: >> >> └── mysite >> ├── __init__.py >> ├── settings.py >> >> ├── theme >> >> ├── __init__.py >> >> ├── models.py (empty file) >> >> └── static >> >> ├── static >> ├── templates >> ├── urls.py >> └── wsgi.py >> >> >> Then you add the application in your INSTALLED_APPS and you're done. >> >> Regards, >> Xavier Ordoquy, >> Linovia. >> >> Le 4 nov. 2012 à 00:23, Ryan a écrit : >> >> Hi, >> >> I have been wondering where people put their non-app-specific static >> files in their django projects? For example, the base css file that >> applies to all pages across the project or perhaps the jquery file? >> >> Currently I have the following structure: >> >> . >> ├── app >> │ ├── __init__.py >> │ ├── models.py >> │ ├── static >> │ │ └── app >> │ │ ├── css >> │ │ ├── img >> │ │ └── js >> │ ├── templates >> │ │ └── app >> │ ├── tests.py >> │ └── views.py >> ├── manage.py >> └── mysite >> ├── __init__.py >> ├── settings.py >> ├── static >> ├── templates >> ├── urls.py >> └── wsgi.py >> >> My STATIC_ROOT setting points to the ./mysite/static directory as this is >> where I would like collectstatic to dump all the static files for >> deployment, however this is also the obvious place (for me anyway) to place >> non-app-specific static files as they apply to the project as a whole like >> the templates directory at this level. >> >> Does any one have any input on this? >> >> Thanks, >> >> Ryan >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django users" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/django-users/-/4H39KqmnTugJ. >> To post to this group, send email to django...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-users...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-users?hl=en. >> >> >> -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/vi2h0QwI0hsJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Choosing a JS framework to go together with Django
By writing a custom serialization for your models you have a good place to handle variations to those models. You don't really have to dump all of your fields, you can even create a custom field specifically for the frontend, but doesn't really exists in your backend model. Besides, If and when your model changes, the frontend part that depends on what changed will probably have to be adjusted, regardless of it beeing a plain old django template or something else. On Thursday, September 6, 2012 12:30:30 AM UTC-3, dotnetCarpenter wrote: > > @Kelly Nicholes In backbone.js everything is in JS, meaning that there > could be no conflict between declarative code and Django handled templates. > If I can expose my python models, through auto serialization (JSON) from > Django, I can see a productivity win. But I'm a little afraid of the tight > coupling in data models between back-end and front-end. My main concern is > that I'll have to rewrite large parts of JS if/when the models change. Have > you any experience ironing out these issues? Maybe it's not a problem but I > lack experience with both frameworks. > > I'll look more into backbone.js :) > > Den onsdag den 5. september 2012 16.34.29 UTC+2 skrev Kelly Nicholes: >> >> It would be a travesty to not mention backbone.js. >> >> On Tuesday, September 4, 2012 7:39:49 AM UTC-6, dotnetCarpenter wrote: >>> >>> Hi all. >>> >>> I'm new here and just took over a Django project for the first time. I'm >>> still getting to grip with Django but as a front end dev for the past 5 >>> years, I'm also looking for a client-side library/framework to go together >>> with my project. >>> My requirements for a JS framework is that it: >>> >>>1. is unobtrusive (Django rendered HTML will be shown to scraper >>>bots like google) >>>2. provides some sort of structure (MVC, MVP, MVVM ect.) >>>3. embraces standards >>>4. doesn't conflict with Django templates or does so intentionally >>>5. ideally uses the same template language as Django >>> >>> In the ideal world a request/response scenario would look like this: >>> >>>1. A client make a (HTTP) request to the (django powered) web site >>>with (HTTP) Accept header text/html >>>2. Django response in the usual way by rendering the assign View >>>(django template) >>>3. The view figure out if JS is supported (implemented in JS). If >>>no, this scenario stays in loop 1-3. If yes, then 4. >>>4. The client (usually a browser) wire up the client-side app >>>structure, hook in to URI links, add transitions between views, >>>data-bindings ect. >>>5. Subsequent request are now handle by the JS framework, either >>>user initiated (e.g. clicking a link) or app initiated (e.g. pulling >>> extra >>>data), that will modify the request header to Accept header >>>application/json or application/django-template. >>>6. If django receive a request with an application/django-template >>>header it will serve the view as plain text. E.g. Content-type: >>> text/plain. >>>On the other hand if django receive a request with application/json, it >>>will send the object model defined in the view as JSON. >>>7. The client-side JS framework will receive a template to render in >>>the first request and the data to render in the template in the second >>>request. A promise object could be used to synchronize the two calls. >>> >>> This way django will work as intended for non JS clients and silently >>> convert to a RIA in clients that supports JS, with minimal double work for >>> the two execution contexts. >>> A big pro in this is the fact that both django and the JS framework >>> share template and data (only has to defined once - in django) - we'll duck >>> type all the way. But does this JS framework exist? Does anyone have any >>> experience with working with django and JS frameworks? Is there any obvious >>> pitfalls in my ideal world scenario in regard to Django? And finally, is it >>> possible to serve templates as plain text with django? >>> >>> >>> Cheers, Jon and thanks in advance >>> >>> PS. I accidentally cross-posted this to the Django Developers group >>> before realizing it was the wrong forum. Sorry about that. >>> >>> -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/LspqoxAlnbwJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Announcement of GUI for Creating Models
This could be very useful for generating dynamic forms. You create the model and then just have some views that generate and process a ModelForm that uses the created model with this interface. Also having a "simple" mode for the client who will actually use this would be helpful. For example, instead of enabling blank/null checkboxes, just add one "required" checkbox. Just some ideas On Friday, September 7, 2012 11:42:55 PM UTC-3, Timothy Clemans wrote: > > I've developed a GUI for creating models, see > https://github.com/timothyclemans/django-admin-models-editor > > Would this be helpful for developers? Would it be useful for you? Should I > keep developing it? What features would you like to see added? > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/YjY0voEABLsJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: setting up Django Compressor
Just to cover the basics, did you follow all installation steps described
here:
http://django_compressor.readthedocs.org/en/latest/quickstart/#installation
Mainly adding 'compressor.finders.CompressorFinder' to STATICFILES_FINDERS
Another thing kind of odd is that your css URL starts with /media/. Whats
your STATIC_URL and MEDIA_URL setting? Check this
out:
http://django_compressor.readthedocs.org/en/latest/settings/#django.conf.settings.COMPRESS_URL
It looks like its defaulting to MEDIA_URL, but you said you were using
Django 1.4, which should have STATIC_URL available.
On Sunday, September 2, 2012 11:13:53 AM UTC-3, Phil wrote:
>
> Hi Joni,
>
> Thanks a million for reply.
>
> Yes I am using django runserver, its a working site just trying to get
> compressor working locally before moving to production. My css works fine
> without the compressor app. I can't see the file if I copy it in my url I
> get a 500 error and the "CACHE" folder doesn't seem to exist anywhere. I
> didn't have anything in my "urls.py" for media, but I added the following
> to see if it would help but it still didn't work...
>
> ***
> if settings.DEBUG:
> urlpatterns = patterns('',
> url(r'^media/(?P.*)$', 'django.views.static.serve',
> {'document_root': settings.MEDIA_ROOT, 'show_indexes': True}),
> url(r'', include('django.contrib.staticfiles.urls')),
> ) + urlpatterns
> ***
>
>
>
> On Saturday, September 1, 2012 3:09:42 PM UTC+1, Joni Bekenstein wrote:
>>
>> The generated css file seems to be in your media directory. If you copy
>> that URL, can you see the css file? Are you using Django's dev server
>> (runserver)? If so, did you add to your urls.py a view to serve the media
>> files? (and that view should only exist when DEBUG is true since in
>> production you're probably going to serve static files and media files
>> directly with your webserver)
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/0iBQbggGm8UJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
Provide editable single text field (through admin) w/o using a whole model
There are 2 answers to your question here: https://groups.google.com/forum/m/?fromgroups#!topic/django-users/0uU1zYH_yOw -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/rElDeRwtiCAJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Provide a single text field (editable through admin panel) w/o using a whole model
How about https://github.com/comoga/django-constance ? -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/ECCuEvzTJbIJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
setting up Django Compressor
The generated css file seems to be in your media directory. If you copy that URL, can you see the css file? Are you using Django's dev server (runserver)? If so, did you add to your urls.py a view to serve the media files? (and that view should only exist when DEBUG is true since in production you're probably going to serve static files and media files directly with your webserver) -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/jHs112LcrVAJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: How to perform a simple search ignoring characters with accents (á, é, í, ó, ú)
django-haystack seemed overkill for me. django-unaccent looks pretty good, since I'm using PostgreSQL. I'll take a look into that, thanks! -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/Y51OtiwSWsgJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: django 1.4, wsgi, flex deploy best practices
Well, since this is the django group, I'll suppose that *${application}* is
a template variable (Maybe it's a template used by ant when compiling the
flex app).
If this index is indeed handled by a django view, you could then configure
the basePath / host like this:
1. You could add it to your settings.py or even better some kind of
local_settings.py if you have that kind of setup. Then the index view would
pass on that setting to the template so that you can pass it through
flashvars.
2. You could also use the Sites app already integrated into django. So each
deploy would properly configure the site domain (through the admin site),
and you'll pass that through flashvars.
Just some ideas, hope it helps.
On Monday, June 4, 2012 10:47:02 AM UTC-3, fred wrote:
>
> That’s a nice clean solution requiring only a minimal edit on a
> redeploy(server move).
>
>
>
> I had previously tried to semi-automate this using the javascript code
> below; but that did not provide a host or hostname; however I’m not really
> a javascript guru and may have missed something.
>
>
>
> var flashvars = {};
>
> flashvars.hostname = window.location.hostname;
>
> flashvars.host = window.location.host;
>
> flashvars.port = window.location.port;
>
> flashvars.mode = "fred put this in to test";
>
> var params = {};
>
> params.quality = "high";
>
> params.bgcolor = "${bgcolor}";
>
> params.allowscriptaccess = "sameDomain";
>
> params.allowfullscreen = "true";
>
> var attributes = {};
>
> attributes.id = "${application}";
>
> attributes.name = "${application}";
>
> attributes.align = "middle";
>
> swfobject.embedSWF(
>
> "${swf}.swf", "flashContent",
>
> "${width}", "${height}",
>
> swfVersionStr, xiSwfUrlStr,
>
> flashvars, params, attributes);
>
>
>
>
>
> *From:* django-users@googlegroups.com [mailto:
> django-users@googlegroups.com] *On Behalf Of *Joni Bekenstein
> *Sent:* Friday, June 01, 2012 9:40 AM
> *To:* django-users@googlegroups.com
> *Subject:* Re: django 1.4, wsgi, flex deploy best practices
>
>
>
> You can configure a basePath through flashvars as you said, but you don't
> have to make django serve the index.html to set that dynamically. You can
> put it by hand, allowing you to deploy on different servers in a decoupled
> manner.
>
>
>
> Maybe I'm missing something here but I don't see anything wrong with that
> approach. I almost always use flashvars to specify at least one location,
> probably for a configuration file, which contains the paths to the backend
> services, external assets, etc.
>
>
>
> Another thing you could do is configure a CNAME record so that
> backend.frontendserver.com points to backendserver.com.
>
>
>
>
> El jueves, 31 de mayo de 2012 15:54:35 UTC-3, fred escribió:
>
> I use Flex for the client side and XML between client and server. I am a
> “one man team” and so elegance sometimes gets sacrifices for “it works”.
> My typical deploy has been
>
> /var/www/html/my flex swf and html code
>
> And
>
> /home/projectname/current/djangositename
>
>
>
> This works well, except that I have to use absolute URL’s in Flex
> (including the server name) because Flex will use either absolute or
> relative to the location of the .swf file. This means I have to rebuild
> for different servers.
>
>
>
> Are there any recommendations of “best practices”
>
> 1. I could have the django view return the html page that includes
> the swf file. This has the advantage of allowing django to pass in some
> flashvars to the application, the disadvantage is closer coupling (at
> least for deploy) of client and server; or
>
> 2. I could use the url redirect to allow a relative reference to
> get redirected to my django home.
>
>
>
> I’m not an Apache expert and so I defer to the community which is more
> experienced with these issues for a clean, generic solution I can use going
> forward as I port to Django 1.4 and CentOs 6.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/KqN3HWLknioJ.
> To post to this group, send email to
How to perform a simple search ignoring characters with accents (á, é, í, ó, ú)
I need to do a simple search ignoring some characters with accents. The idea would be that "hola" matches the search term "holá". What I'm currently doing is adding a CharField to my model to store the searchable term. For example: class Book(models.Model): title = models.CharField(max_length=100) searchable_title = models.CharField(max_length=100) When I save a Book I'll replace the accented characters in title with their non-accented counterparts and store the result in searchable_title. The, I'll also do the same thing with the search term before actually doing the query. I don't like this approach because if I need to add more searchable fields things start getting noisy in my models. Any ideas? -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/tdIUkptWpZgJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: django 1.4, wsgi, flex deploy best practices
You can configure a basePath through flashvars as you said, but you don't have to make django serve the index.html to set that dynamically. You can put it by hand, allowing you to deploy on different servers in a decoupled manner. Maybe I'm missing something here but I don't see anything wrong with that approach. I almost always use flashvars to specify at least one location, probably for a configuration file, which contains the paths to the backend services, external assets, etc. Another thing you could do is configure a CNAME record so that backend.frontendserver.com points to backendserver.com. El jueves, 31 de mayo de 2012 15:54:35 UTC-3, fred escribió: > > I use Flex for the client side and XML between client and server. I am a > “one man team” and so elegance sometimes gets sacrifices for “it works”. > My typical deploy has been > > /var/www/html/my flex swf and html code > > And > > /home/projectname/current/djangositename > > > > This works well, except that I have to use absolute URL’s in Flex > (including the server name) because Flex will use either absolute or > relative to the location of the .swf file. This means I have to rebuild > for different servers. > > > > Are there any recommendations of “best practices” > > 1. I could have the django view return the html page that includes > the swf file. This has the advantage of allowing django to pass in some > flashvars to the application, the disadvantage is closer coupling (at > least for deploy) of client and server; or > > 2. I could use the url redirect to allow a relative reference to > get redirected to my django home. > > > > I’m not an Apache expert and so I defer to the community which is more > experienced with these issues for a clean, generic solution I can use going > forward as I port to Django 1.4 and CentOs 6. > -- You received this message because you are subscribed to the Google Groups "Django users" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-users/-/KqN3HWLknioJ. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
