Alright, I know I've asked similar questions, but I feel this is hopefully a bit different. I'm integrating django.comments into my application, and the more I play with it, the more I realize it may not even be worth my while at the end of the day. That aside, I've managed to add Captcha to my comments, and I've learned that customizing the form is a terrible idea (hiding that honeypot is stupidly difficult, and from what I can tell requires JS to hide. Pity.). That's alright though, I've managed to work with it. However, the templates for the comments (preview and posted) are frustrating.
When a user is sent to the preview or posted templates, I'd like my sidebar's that have dynamic data to still be functional, however they're not. Do I have to override/rewrite the comments views to push data to these views? At that point it seems like I'm rewriting a major chunk of the comment system anyway, and it'd almost be beneficial to just write my own in that case. I'm more than willing to do that, and totally understand that I'm not entitled to a perfect comments system from Django. I just want to make sure I'm thinking right, and that if I want more than what I get from the comment views, that rewriting them is my only path.
Surely someone's found a healthier way though, so I thought I'd poll the audience. Any thoughts? If you need more info, just lemme know!
Dynamic data in sidebars is what template tags are for.
There's absolutely no need to muck around with the built-in views - just define the tags add them to your templates.
I user template tags as well. Templates in Django are truly for displaying data only.
I think Django believes in separation between the Designers and the Developers. So, they are enforcing the idea of templates should be simple enough for web designer to work with. (the photoshop guys)
So, as long as you don't need complected functionality, just pass the info to a filter and have it do the data manipulation and return the final string that you need.
Related
I was troubleshooting a problem with obtaining the request obj with a new project and realized "django.core.context_processors.request" was commented in vanilla installs of Django.
Like the title suggests, why would this seemingly helpful context processor be turned off by default?
Is it an issue with performance?
Is it an issue with security?
Is it somehow redundant?
Some mild searching has not turned up anything for me, but I thought I'd ask here.
This is a good question. The docs say Note that this processor is not enabled by default; you’ll have to activate it. but no explanation.
My take on it is due to django's intense desire to separate view logic from the template.
The request object is the gateway to all data that view logic is built from (given what the browser sent us, do X, Y, Z) - therefore allowing it in the templates is akin to giving the template huge amounts of control which should be placed in the view under normal circumstances. The idea is to populate the template context with specifics, not everything.
Removing them is just some more encouragement that "most things should be done in the view". The common django.contrib apps mostly don't rely on it, if it's not required by default.
And of course, that's further proof the request object isn't necessary in the template except for special use cases.
That's my take, anyways.
I need to make a tabular data structure (tab delimited text file) available for viewing as a web based solution. I am a bioinformatics programmer with almost no experience in web based development. I know that django is very hot in the python community but I wanted to ask here before I went ahead and buy a book on django. What would be your choice of technology stack to accomplish something like this.
I need to display a table of 40-50 columns and 100.000 rows and hopefully let the user filter the data based on certain data items ( i.e only show rows that have a certain value in a certain column , show only data that was recorded on Monday and hide all other weekdays)
I am sorry if this question is too vague or stupid but I really need some basic guidance here.
Thanks
Django can do this fairly easily.
Django can do this, but I think the best way to go is to use a Javascript framework ontop of django, I am currently doing this. ExtJS has various types of grids in your situation I think a 'Live' grid would be perfect.
It loads x amount of rows, so that you dont have to load 100,000 rows everytime, just what the user sees. Also, filters etc are built in as well as many other features
Other javascript frameworks that do similar things are YUI and in my opinion JQuery to a lesser extent
Edit/Elaborate
So obviously here isnt the place for a beginners crash course, but in my opinion there is a couple of things you need to do and know.
This will work by firstly creating a django view that returns a JSON string. (If that sentence didnt make a whole bunch of sense, I would recommend skimming over the Django tutorial...actually, you probably should do that anyway) Python has methods to turn datatypes such as dictionaries/csv's (in your case, I guess a TSV lol) to this format. THEN, when you have this (can be pointed to by a url...when you dive into Django it will make more sense) then you create the ExtJS grid and point it to that url.
There is a whole bunch of tutorials about ExtJS grids here, notably the Tutorial:Grid PHP SQL I think would be helpful. Obviously not php, but the concept is the same.
Unfortunately I dont have any examples of my own to show you, but there are TONS of resources about this stuff, I wouldnt bother buying a book
I think this could be done easily without JavaScript. What neolaser is outlining is my preferred solution as well, but django could do this no sweat. You would need
to configure your models.py to match your database
a view that accepts get requests and makes queries based off of their contents. http://docs.djangoproject.com/en/dev/ref/models/querysets/
a template that displays the results of those queries and allows you make get requests which your view will interpret.
Because django is such a well-used framework, it's pretty easy to find a run down on the various terms (google: "django views", "django models", etc).
If what you describe is really all you're doing, then I'd say Django may be overkill. Maybe first try a simpler basic framework like Cherrypy (see tutorial) to serve your simple page/form (you don't even need templates, just spit back HTML yourself). Now all you need is a bit of code to read, filter and/or page, and format your CSV.
If you want to put something like this together very quickly and easily and you don't have much web development experience, I think your best bet would be web2py. It requires no installation or configuration, has no dependencies, and includes a web server, a relational database, a web-based integrated development environment and admin interface (demo), and jQuery integration (for Javascript and Ajax). It's very easy to learn and was designed for ease of use and developer productivity. You can get a lot done with very little code thanks to the included scaffolding app along with many sensible default behaviors.
As for table/grid displays, you could probably use:
The jqGrid plugin - a web2py plugin for jqGrid
powerTable (source code) - a web2py plugin for DataTables
If you need help getting started or have any questions, you'll get lots of help from the very friendly and responsive mailing list.
I mean I understand that these templates are aimed at designers and other less code-savvy people, but for developers I feel the template language is just a hassle. I need to re-learn how to do very simple things like iterate through dictionaries or lists that I pass into the template, and it doesn't even seem to work very well. I'm still having trouble getting the whole "dot" notation working as I would expect (for example, {{mydict.dictkey}} inside a for loop doesn't work :S -- I might ask this as a separate question), and I don't see why it wouldn't be possible to just use python code in a template system. In particular, I feel that if templates are meant to be simple, then the level of python code that would need to be employed in these templates would be of a caliber not more complicated than the current templating language. So these designer peeps wouldn't have more trouble learning that much python than they would learning the Django template language (and there's more places you can go with this knowledge of basic python as opposed to DTL) And the added advantage would be that people who already know python would be in familiar territory with all the usual syntax and power available to them and can just get going.
Am I missing something? If so I plead django noob and would love for you to enlighten me on the many merits of the current system. But otherwise, any recommendations on other template systems that may be more what I'm looking for?
The reason that most people give for limited template languages is that they don't want to mix the business logic of their application with its presentation (that wouldn't work well with the MVC philosophy; using Django I'm sure you understand the benefits of this).
Daniel Greenfeld wrote an article a few days ago explaining why he likes "stupid template languages", and many people wrote responses (see the past few days on Planet Python). If you read what Daniel wrote and how others responded to it, you'll get an idea of some of the arguments for and against allowing template languages to use Python.
Don't forget that you aren't limited to Django's template language. You're free to use whatever templating system you like in your view functions. However you want to create the HTML to return from your view function is fine. There are many templating implementations in the Python world: choose one that suits you better, and use it.
Seperation of concerns.
Designer does design. Developer does development. Templates are written by the designers.
Design and development are independent and different areas of work typically handled by different people.
I guess having template code in python would work very well if one is a developer and their spouse is a designer. Otherwise, let each do his job, with least interference.
Django templates don’t just use Python code for the same reason Django uses the MVC paradigm:
No particular reason.
(ie: The same reason anyone utilizes MVC at all, and that reason is just that certain people prefer this rigid philosophical pattern.)
In general I’d suggest you avoid Django if you don’t like things like this, because the Django people won’t be changing this approach. You could also, however, do something silly (in that it’d be contradictory to the philosophy of the chosen software), like put all the markup and anything else you can into the "view" files, turning Django from its "MVC" (or "MTV" ) paradigm into roughly what everything else is (a boring but straightforward lump).
I'm split between writing my own comments model (pretty easy model, foreign key it to the entry) or using the full-out Django comment framework.
I mean, for right now, I just want a basic box for people to post a comment. That's it.
Um... yes?
More seriously - whatever makes you happier. If you're in a hurry, roll your own; if you have a bit more time, by all means get to know the Django system; it'll probably be worthwhile in the longer run.
I'm working in pylons with mako, and I'd like to create forms and validations with FormEncode for several parts of my application. I can't seem to find any good examples of the whole process. My question is twofold:
Technical
FancyValidators and Schemas - Their relationship and syntax
Pylons controllers and mako templates - how to collect, handle, and validate the data
Stylistic
Best practices for controller methods
Easing the reuse of forms (for update vs create, for example)
So if you know of any complete examples, it would be much appreciated. I would think this would be a common combination with more examples/tutorials out there.
I don't know if you've gone through the pylons book, but I found chapter 6 to be very thorough in regards to forms.
As far as best practices go, I'm not exactly sure what you are looking for. A controller method maps to a url and needs to return a string-like object. How you arrive at that is largely application specific and you are free to choose how you structure the application.
For form reuse, I don't know if it would be considered a best practice but tw.forms I find pretty useful for just that (and toscawidgets for general html snippet reuse). If you anticipate having to reuse fields in forms, you may have some success with fieldsets.
If you are looking for complete examples, I would consider turbogears2 a good resource. It's built on top of pylons so any information on tg2 is equally applicable to pylons.
You can also look at the reddit source code
And finally, someone will suggest django. :)