Re: How about a Django apps public repository?
>> I'm the guy that started this thread and had pledged to take the lead >> on this. Ironically, I'm also the guy who started the recent thread >> "Why I'm giving up on Django". So for now, it looks like I'll be >> taking an indefinite hiatus from Django dev. > > just curious - did you indulge in all this fanfare when you left PHP > for django? Fanfare? Not sure what you mean really. The only reason I added to this thread again was because I have some domain names I'd like to donate which might be useful to the community. I posted publicly about giving up on django because I thought it might help air out some niggling issues in django. I was also curious to see if I was the only one struggling with these issues or if these were actually problems worth addressing. I certainly didn't mean to offend anyone or to "indulge" myself in any way. Best wishes, Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: How about a Django apps public repository?
Hi, I'm the guy that started this thread and had pledged to take the lead on this. Ironically, I'm also the guy who started the recent thread "Why I'm giving up on Django". So for now, it looks like I'll be taking an indefinite hiatus from Django dev. If someone wants to take this idea and run with it, I think that would be great. Then down the road sometime when Django's little idiosyncrasies are resolved and I come crawling back to the platform, maybe there will be a repository all ready to rock too! If anyone is seriously interested, I've registered the domains djangoforge.com, .net, and .org. I'd be happy to donate those to the cause along with my apps so far. Best wishes, Sean On Oct 1, 2006, at 9:44 AM, Marc Fargas wrote: > > Uhm.. > I was waitting for Ian Holsman who said had something on pending of > some 'styling', if no body is on it I can take over it ;) > > Cheers, > Marc. > > On 9/30/06, Steven Armstrong <[EMAIL PROTECTED]> wrote: >> >> On 09/30/06 17:35, Lucas Vogelsang wrote: >>> Hi, >>> Is this project/thread dead or is someone working on it? >>> >>> I'd like to use this repository, however I am fully tied up with my >>> other projects and can't help pushing it forward. >>> >>> regards, >>> lucas >>> >> >> looks like all the others have the same problem ;) >> >>> >> > > > -- > The probability of failure of a (computer) system is exponentially > proportional to the physical distance between it and the one who could > fix it. -- Martin F. Krafft > > > -- > The probability of failure of a (computer) system is exponentially > proportional to the physical distance between it and the one who could > fix it. -- Martin F. Krafft > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Why I'm giving up on Django
Hi Guys, I just wanted to share with the community my personal experience with Django in the hopes that maybe some of my petty gripes might be somehow helpful. Before doing that, I have to thank everyone in the community for being so helpful and just so damn nice! Thanks so much to all on this list and on the IRC channel. So here's the thing... I came from a background of PHP and then Ruby on Rails. I was drawn to Django because it seems more modular and a better match for my goal of creating web *sites* with apps the live *in* the sites. Rails doesn't really work that way at all. And PHP? -- well, you know. PHP lends itself to a style of coding that is so not DRY, it's like coding underwater. So I went on a quest to find a well-polished, easy to use framework that is modular, object oriented, does the basics like database abstraction and form validation, is easy to deploy, and most importantly: *doesn't get in my way*. After exploring lots of options, I settled on Django. I bought a book on Python, went though the Django tutorials, read the docs, etc. It all looked fantastic! The things I was most excited about were: (1) Clean modular design with 'apps' that can be imported into 'projects' (2) Included libraries for things like authentication (3) Reasonably easy forms with form wrappers/manipulators (4) The free Admin section! (5) Overall really polished look and feel -- even the error pages (6) Super simple deployment with mod_python (7) Opinionated design decisions start you off with something sensible so you don't have to reinvent the wheel for things like naming conventions or directory structure. -- But I'm very sorry to say that one by one, all of these things turned out to be not so great after all. Here's what I found after six weeks of struggling to build a site in Django that would have taken a week or so in PHP. -- (1) The clean modular apps aren't totally decoupled because they still have to use the project's template directory and css (which makes sense perhaps but complicates things for what I'm trying to achieve). More importantly, there's no built-in facility for rendering templates which are just static pages. Yes I know there's flatpages and templatepages but it would be a lot nicer if Django just served up the template in the absence of a url-routed view. I ended up writing my own little app to do this which took the better part of a day. So it took extra work to accomplish something as simple as serving a static html page. (2) This is a biggie for me. I can't believe that the authentication module forces you to use hard coded urls for login/logout pages -- that's just maddening! So if you want to do it your own way, you have to totally roll your own authentication from scratch. More work. I ended up hiring a guy to write a basic auth system that lets me set my own urls. (3) FormWrappers are great until you need to do anything even slightly different from the django prescribed method, then you have to use custom manipulators which I found to be a giant pain in the ass. I spent literally several days working on one form (yes it's a complex form -- but 4 days is ridiculous). The first thing that threw me was that I wanted to use a more traditional method of inputting a date -- just three pulldown menus for month, date, year. Instead of providing some simple facility to let you override parts of the standard manipulators, as soon as you find something you want to do that isn't included, you have to write a whole custom manipulator for it. (4) The admin section is certainly pretty enough for production use -- but it isn't flexible enough in my opinion. Take my 3-pulldown menus for inputting a date as an example. How would you go about doing that in the admin section? I suppose there's probably some way -- but this is another example of django getting in the way -- adding extra work where I'd hoped it would be reducing work. After identifying a few things that wouldn't work easily with the free admin section, it looked like the easiest solution was to do my own custom admin section rather than try to sculpt the django admin section into what I wanted. (5) The polish is very nice -- no question. But I was disappointed to discover that many of those sexy error messages didn't reveal *my* coding error but just reported problems as they occurred in the django stack. So I was often left to guess about what part of my code was causing the issue. (6) Not really a django issue but disappointing nonetheless. If you want to deploy to a cpanel server (which is stuck in the 1900's using Apache 1.3), you'll have to mod_proxy out to another web server such as Lighttpd with FastCGI. That's exactly how Rails apps are typically deployed and one of the reasons I went hunting for an alternative. So much for the easy deployment advantage. (7) The
Re: How to pass object *and* subobjects to FormWrapper?
Thank Patrick but I'm using a *custom* manipulator so my manipulator doesn't have those attributes. Sean On Sep 20, 2006, at 4:39 PM, patrickk wrote: > > not sure if this will solve the problem, but according to the > documentation you should use > 1. manipulator = Place.ChangeManipulator(place_id) > 2. place = manipulator.original_object > 3. new_data = manipulator.flatten_data() > > nr. 3 has been changed in the docs recently: > see http://www.djangoproject.com/documentation/forms/#using-the- > changemanipulator > > patrick > > > Am 20.09.2006 um 08:03 schrieb Sean Schertell: > >> >> Using a custom manipulator, I'm trying to populate my form with >> existing data. But I can't get the data from the FK tables to show >> up. >> >> Here's a simplified example: >> >> Group >> name >> >> Member >> first_name >> last_name >> >> >> So let's say a Group can only have up to 6 members. And I have a form >> that lets you add a group and up to 6 members all in one go. My add >> form works fine. And my edit form works to the point of populating >> the group -- but not the members. >> >> Here's basically what I'm doing to get the data into the form: >> >> In my custom GroupManipulator, I fetch the data like this: >> self.original = Group.objects.get(id=group_id) >> >> Then in my edit_group view, I do this: >> new_data = manipulator.original.__dict__ >> >> And pass new_data to a FormWrapper as normal. >> >> Like I said, this all works perfectly except that the members of my >> edit form are blank. >> >> How can I pull in subobjects along with the parent object and pass it >> to the FormWrapper? >> >>> > > > > > > DataFly.Net Complete Web Services http://www.datafly.net --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
How to pass object *and* subobjects to FormWrapper?
Using a custom manipulator, I'm trying to populate my form with existing data. But I can't get the data from the FK tables to show up. Here's a simplified example: Group name Member first_name last_name So let's say a Group can only have up to 6 members. And I have a form that lets you add a group and up to 6 members all in one go. My add form works fine. And my edit form works to the point of populating the group -- but not the members. Here's basically what I'm doing to get the data into the form: In my custom GroupManipulator, I fetch the data like this: self.original = Group.objects.get(id=group_id) Then in my edit_group view, I do this: new_data = manipulator.original.__dict__ And pass new_data to a FormWrapper as normal. Like I said, this all works perfectly except that the members of my edit form are blank. How can I pull in subobjects along with the parent object and pass it to the FormWrapper? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: How to save parents and multiple children with single form?
Anyone? Please? My project is stalled until I learn how to do this and it's no where in the docs. I'm dead in the water until someone takes pity on me and explains how to do this. > Let's say I have a form called add-new-group.html that looks like > this: > > Group Name: __ > > Member 1 --> Name:___ Age: > Member 2 --> Name:___ Age: > Member 3 --> Name:___ Age: > > So when the form is saved, it needs to save the new group to the > 'group' table, and it needs to save up to three new members to the > 'member' table. > > How in the world can I do this? > > Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
How to save parents and multiple children with single form?
Let's say I have a form called add-new-group.html that looks like this: Group Name: __ Member 1 --> Name:___ Age: Member 2 --> Name:___ Age: Member 3 --> Name:___ Age: So when the form is saved, it needs to save the new group to the 'group' table, and it needs to save up to three new members to the 'member' table. How in the world can I do this? Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Flakey file uploads in Safari
When submitting a simple form with just a name and a file, Safari
hangs while submitting the form. If I click the submit button again,
it usually works on the second or third click (totally inconsistent).
In Camino, it submits every time flawlessly. What the FiretrUCK?
Sean
Code
---
Model
==
class Band(models.Model):
name = models.CharField(maxlength=255)
photo = models.ImageField(upload_to='images/bands/image_raw',
blank="true")
def __str__(self):
return self.name
View
==
def add_band(request):
manipulator = Band.AddManipulator();
# Was form submitted?
if request.POST:
new_data = request.POST.copy()
new_data.update(request.FILES)
errors = manipulator.get_validation_errors(new_data)
if not errors:
manipulator.do_html2python(new_data)
new_band = manipulator.save(new_data)
return HttpResponseRedirect('/admin/schedule/list-bands')
else:
# Intialize form
new_data = errors = {}
form = forms.FormWrapper(manipulator, new_data, errors)
return render_to_response('admin/schedule/add-band.html',
{'form': form})
Template
==
My template validates and is very simple, not worth posting. But
here's the form tag:
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Has anyone run Django on a cpanel box (w/root access)
Right, rebuilding Apache 1.3 with mod_proxy looks like the only viable option at this point. I just wanted to see if anyone else had gone through this dilemma before and had some better ideas. Anyone? Django vs CPanel experience? :-) Sean On Sep 15, 2006, at 3:49 PM, Ian Holsman wrote: > > why not build mod-proxy into the apache13 ? > that would be the simplest option. > > regards > Ian > On 15/09/2006, at 2:50 PM, [EMAIL PROTECTED] wrote: > >> >> Hi guys, >> >> I need to install a django app onto a client's cpanel box. I have >> root >> access and can install whatever's needed. But the trouble is that >> cpanel still uses Apache 1.3 (ugh). And to make matters worse, it >> uses >> Apache 1.3 without the mod_proxy module. >> >> I can't install Apache2 without breaking cpanel which means that >> running django through mod_python is out. I've had really bad >> FastCGI/Apache experiences in the past with Rails so I think that's a >> bad idea. The only option I can think of is to recompile Apache with >> mod_proxy and run Lighttpd/FastCGI proxied through Apache. >> >> Any other suggestions? >> >> Sean >> >> >>> > > -- > Ian Holsman > [EMAIL PROTECTED] > > > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Rails/Django comparison synopsis
Hi Jeff, I defected to Django from Rails and so far I'm loving it. But it really depends on what you need to do. If you're creating a single monolithic application, Rails is pretty sweet. I did a giant invoicing/accounting application for an insurance company in Rails. It handles tens of thousand of members and processes over a million dollars in transactions per month through an excruciatingly convoluted billing process. In my opinion, Rails is perfect for this kind of thing. I'm sure I could have accomplished the same thing with Django, but Rails just feels a little better geared to this type of thing -- single, large applications. The built-in ajaxy stuff came in very handy too. And the Ruby syntax is a real pleasure to work with (although I'm definitely warming to Python). But here's where Rails falls down in my opinion, and the reason why I switched: (1) Rails apps aren't portable. At all. Not even a little. Personally, I don't spend most of my time building billing apps for insurance co's. I mostly build web sites with little apps in them such as a photo gallery, a blog, a shopping cart. With Django you can build an app, put it on the server somewhere, and for as many sites (projects) as you like you can pull in that app, skin it and use it. With Rails, there's no concept of 'apps' which can be imported into 'projects'. There's just this one big monolithic app which *is* your project. For website development, this sucks. (2) Rails apps are a little flaky to deploy. I hear Apache2/Mongrel is well on the way to solving this. But the standard method of deploying Rails apps has been using Lighttpd with FastCGI proxied through Apache. Kind of convoluted and sometimes the FastCGI processes go nuts and eat up all your resources until you hunt down and kill each process. Typical Django deployment uses Apache/ mod_python. It's fast and stable and easy to deploy. (3) Documentation!!! I'm surprised that you mentioned that as a benefit of Rails. That's one of the very few things that I found downright annoying about Rails. The docs just aren't there. Sure you can google up some tutorials or buy the Agile book (which is excellent by the way). But the actual documentation on the Rails site is horrible. Mostly user submitted wiki stuff -- some of it is outdated or just wrong, and there are gaping holes too. The Django docs are one of things that drew me in right away. Shopping for an alternative to Rails, when I saw the documentation section of the Django site, it was like a breath of fresh air. A now *this* is what documentation should be :-) Now the flip-side: There are a couple things I've found in Django that are not so great. (1) The admin section is assumed. The admin section is unbelievably cool when it meets 100% of your needs. But if you decide for whatever reason that you wanna do your own custom admin section, prepare to endure some funkiness. For example, basic authentication. You can use the bundled auth system, but then you're required to use hard-coded urls for your login/logout pages. Don't like those urls? Well then, you're gonna have to write you own authentication system from scratch. I've found this to be the case for a lot of stuff. Django gives you some stuff for free, but it's not as flexible as I'd hoped. And writing your own from scratch feels like more work to me than it did in Rails (for example the auth system). (2) No ajaxy stuff. There's nothing stopping you from using prototype or dojo or whatever. But I have to admit that I do miss the Rails way of doing it where using ajax isn't really any harder than not using it. One final point about fit and finish: Probably the biggest surprise for me coming to Django is how well-polished the framework is. Rails and Django are really equals in this department I think. To be honest, I had expected to find Django a little undercooked in some areas, but it's not the case at all. It's very solid and well- documented and it works very very well. The community is great too. Django is very much on par with Rails in terms of polish. Okay that's it -- back to work. Hope this helps somewhat :-) Sean On Sep 12, 2006, at 8:41 AM, Jeff Rodenburg wrote: > I'm trying to get some education on rather quick order and was > looking for feedback from the Django side of the equation. > > I've seen a bit of comparison in public forums of Rails and > Django. I'm trying to eval these things from a higher level, or > one might call "management" perspective. (No, I'm not management; > I just work for them. ;-) ) > > On observation, the frameworks seem rather similar with subtle but > key differences, i.e. interpretation of the MVC terminology and > structure. On a quick-read basis, Rails seems to have an advantage > of a lot of documentation, more publicity (the Hanson kid sure > knows how to work a crowd) and a nice IDE
Re: How about a Django apps public repository?
Okay then, let's do it :-) I can get started in October putting this together. I have servers, bandwidth, and general webdev skills. I've registered djangoforge.net for us to use, and I can commit to maintaining the site. Any other volunteers for helping to develop the system? Any other apps contributions? Also, more thoughts on how you'd like to see this implemented would be much appreciated. How would you like this site to work? What features do we need at a minimum? Thanks! Sean On Sep 9, 2006, at 12:33 PM, Jeff Forcier wrote: > > Sean Schertell wrote: >> >> Any other contributors? > > I've got a handful of templatetags, which while somewhat outdated > (built against ~0.91) should still be useful. I also have a (very) > small forums app which I plan on expanding when I find the time, > although it would need some cleanup to use outside of the site it's > currently in. > > There are a couple of other things I've written up but one of them > sucks and the other one is really just documentation which should > go in > a blog post or on the Django wiki. > > > > > > DataFly.Net Complete Web Services http://www.datafly.net --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: How about a Django apps public repository?
Funny how in a "room" full of web developers, lots of us have bandwidth and servers for hosting this stuff. ;-) But what about the actual stuff? So far we've got a couple people willing to contribute an app or two. And as I've said, I've got three I can put in to get started. I run a smallish web hosting company so I'm happy to provide the servers/bandwidth. What we really need is apps and folks who want to contribute ideas or actual code to making the space. So how about it guys? Got apps you wanna contribute? or ideas for how this thing should work? anyone wanna volunteer to help build it? :-) Sean On Sep 9, 2006, at 9:16 PM, charles sibbald wrote: > I have a dual processor opteron server located in a Tier 1 internet > site at manchester university. > > We could probably use this, I currently have it set up to serve > VPS's specific to Django and would be willing to use it also for > this purpose. > > - Original Message > From: Marc Fargas <[EMAIL PROTECTED]> > To: django-users@googlegroups.com > Sent: Saturday, September 9, 2006 1:01:22 PM > Subject: Re: How about a Django apps public repository? > > On 9/8/06, Jeff Forcier <[EMAIL PROTECTED]> wrote: > > Well, I would imagine that many other Djangonauts have their own > cheapish hosting that they use for personal websites or other > projects, > which are more than capable of handling Trac. I mean, I can't be the > only person who already has a $40/mo VPS with a ton of bandwidth > available, right? > > You're not alone! I also have a server out there which currently > only handles a mailling list... (the HD broke down and hadn't had > time /willing to upload my site again, I'm watting for a nice blog > app for django for that.. hehehe)... > > Unless the Django community is a lot bigger than I think it is, or my > estimates of the processing power needed to host a Trac site are way > off (both quite possible, of course) I'd wager I could host such a > system on my own resources, and I'd also wager there are folks out > there with more such resources available. > > Maybe the community is big, but sure there are not "too many" > contributions to kill a server ;) Maybe the biggest issue is to > automattically create trac's and subversion repositories but it > shouldn't be too hard. So if there is a common willing of getting > this up we can go over it! And with two servers at least we can do > backups ;)) > > Not everything has to be 100% free as in beer :) > > Maybe someday... someday near 2111011. > > By the way, to the djangoproject.com DNS admin, would it be > possible to get a CNAME forcontrib.djangoproject.com ? ;oP > or djangofans.com .. hehe. > > The question: Who would really like, and activelly support that > initiative? (having a repository of un-official templatetags, > filters, patches and applications) > > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: How about a Django apps public repository?
I'm willing to invest the time and bandwidth to get this thing off the ground. And it sounds like a lot of folks would be happy to have such a repository. But if we want to make it work, it has to have some content from the very beginning. So how many of you actually have code that you want to share? Anyone willing to make a commitment to contribute apps if set this thing up? I'll start with the following three: Newsletter: A handy newsletter app for (opt-in) mass mailing BasicAuth: A simpler authentication system for people who use a custom admin site StaticPages: A very lightweight request to template mapper (similar to TemplatePages) Any other contributors? Sean On Sep 9, 2006, at 4:35 AM, Jeff Forcier wrote: > > Marc Fargas wrote: > >> I like the idea of the Cheeshop and more the one of different >> TRACs, but on >> the three options given, hosting TRACs is not as easy, Cheeshop >> and google >> are free.hosting a TRAC isn't. dejavu doesn't seem an option if >> you need to >> wait for an invite code for every project. > > Well, I would imagine that many other Djangonauts have their own > cheapish hosting that they use for personal websites or other > projects, > which are more than capable of handling Trac. I mean, I can't be the > only person who already has a $40/mo VPS with a ton of bandwidth > available, right? > > Unless the Django community is a lot bigger than I think it is, or my > estimates of the processing power needed to host a Trac site are way > off (both quite possible, of course) I'd wager I could host such a > system on my own resources, and I'd also wager there are folks out > there with more such resources available. > > Not everything has to be 100% free as in beer :) > > > > > > DataFly.Net Complete Web Services http://www.datafly.net --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: How about a Django apps public repository?
Very interesting points. Does anyone have any thoughts on using Google code hosting for this idea? Anyone know off the top of their heads whether or not we'd be able to create a Django "category" within Google or would it just sort of be lumped in with all the other Python stuff? Sean On Sep 8, 2006, at 9:59 PM, Jeff Forcier wrote: > > I'd like to note that this is not the first time this has come up, > although I don't wish to imply we should not be discussing it (it > seems > to be one of those issues that comes up periodically). > > > http://groups.google.com/group/django-users/browse_frm/thread/ > 5e5a61a14c2e519a > > There was also a discussion on IRC from even farther back: > > http://simon.bofh.ms/logger/django/2005/11/18/09/17 > > I actually wrote up some random thoughts about this issue on a > personal > wiki page, and I figure I might as well throw those out now. Apologies > for the length and the formatting (it's obviously in wiki source > format). > > > re: "Djangoforge" > > [The links I shared above were also pasted here at the top of the > page] > >> From that discussion plus a handful of others, it looks like an > official one ''is'' planned for the 1.0 release? > > * Should it be official or unofficial? > ** If it's official, that would be "nicer" because there would be a > mandate for it, it would be in a central location along with > everything > else, etc. > ** However, if official, we might run into the problem of people > expecting official support for the non-core-dev-written code contained > therein. This is probably the #1 reason to make it unofficial--or not > to have it at all, since even an unofficial one would really need > to be > linked from the official site, and thus gain officiality by > association. > *** So then the question becomes, is its usefulness going to outweigh > that support concern? > ** Also, I found a reference on the IRC channel from 2005.10.03 > quoting > one of the core devs as saying such a thing would be a "conflict of > interest" but that they'd be happy to have someone else host it. If > still true, this would make this official/unofficial issue moot (and > the wiki-related items below would have to pertain to some non-Django > wiki). > * What should it contain? Most of these are possibilities, I'm not > necessarily saying I think they should all be included. > ** Anything that does not belong in the core "contrib" directory, > stuff > that is not in the official trunk code. I.e. when someone says "Why is > Common/Useful Feature X not in Django?" and the core devs do not want > to include that feature in the short/long term, someone could make one > (app/templatetag/patch) and stick it on the Djangoforge. > ** Common model examples and/or fleshed-out explanations of the ones > already included in the docs. For example, how to do tags correctly > (and/or a small discussion of the different approaches to that problem > and their pluses/minuses). > ** Common templatetags, such as ones for len(), 'if x in y', etc. > ** Full applications, probably the primary reason people mention this > sort of project. Blog, photo gallery, wiki, etc. > * What format should it be in? > ** Is there a good reason NOT to have it in the code.djangoproject > wiki? I'd say that depends on exactly what is provided (see previous > point re: what should it contain?). For simple stuff like code > snippets > (templatetags, model layouts) we already have many on the wiki. Full > apps/projects would be something else--yes, you can attach archives to > wiki pages, but we probably want source control for this stuff, right? > *** Furthermore, the wiki provides, well, a wiki--built-in discussion > and unlimited expandability by the users. At least some of a wiki's > functionality is really required for this sort of thing, IMO. > ** Should we use whatever OSS "Forge" systems already exist? I have > not > examined them closely, but my gut instinct from using them to some > degree is that they're kinda "loud" UI-wise, plus they aren't as > collaborative as we might need (which brings us back to the wiki). > However, if good ones exist, they have theoretically solved all these > problems before and we might not want to reinvent the wheel. > ** Roll something new (with Django, of course)? See previous point re: > reinventing the wheel; but a roll-our-own could, of course, provide > exactly the features we need in the way we need them (note to newbies, > this duality of thinking is why the open source community is so damned > fragmented ;)). > > > > Regards, > Jeff > > > > > > --~--~-~--~~~---~--~~ 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
Re: How about a Django apps public repository?
Hey thanks for all the positive feedback on this. It seems like lots of folks share my sentiments. That's nice :-) It would be really nice to hear the devs' thoughts on the subject. Adrian, Jacob, Simon? A penny for your thoughts? Ironically, the whole point of this idea is to avoid unnecessary duplication of efforts -- so if you guys already cooking something up to address this apps repository idea, please let us know! :-) Also to devs: If a few of us cook something up, would it be possible to have you guys add it to official djangoproject site rather than us hosting it off-site somewhere? (more likely to really get used if it's on the official site). Cheers, Sean On Sep 8, 2006, at 12:07 AM, limodou wrote: > > +1 > > I also suggested similar subject before. > > -- > I like python! > My Blog: http://www.donews.net/limodou > UliPad Site: http://wiki.woodpecker.org.cn/moin/UliPad > UliPad Maillist: http://groups.google.com/group/ulipad > > > > > DataFly.Net Complete Web Services http://www.datafly.net --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
How about a Django apps public repository?
I wonder how many of us are writing nearly identical apps at any given time. For example, I just hired a guy to write a really basic newsletter app for my project. Now I'm working on a fairly typical "upcoming events" schedule. And soon I'll be working on a simple photo gallery that makes thumbnails as you upload, etc. I'd bet dollars to donuts that many of you have written these apps already. Wouldn't Django be that much sexier if it came with an ever-expanding repository of apps that we could all share with each other? The fact that apps are modular plug-and-play in Django is *really* cool (Rails can't do that). So why not leverage the "pluggability" of Django's app architecture by making a bunch of these apps public? Am I alone on this? If I created such a repository would anyone use it? Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Custom manipulators: How to associate a model?
Thanks so much for your help Ryan. Unfortunately though, I think I'm missing some crucial bits of detail here so I still have a couple basic questions: (1) Where should my custom manipulator code live? I would think it's in the view, since it really is view code after all. But maybe the need to associate it with a model means it has to live in the model? (2) Ryan said "If your custom manipulator is for creating a new instance of the model, just have save() create on and return it." -- how do I make my custom manipulator create a new instance of the model? This is really the crux of my initial question I think -- and the docs really don't seem to address this at all. Please help! -- my deadline is looming! :-) Thanks all, Sean On Sep 4, 2006, at 11:19 PM, [EMAIL PROTECTED] wrote: > > If your custom manipulator is for creating a new instance of the > model, > just have save() create on and return it. > > When I am writing a custom change manipulator, I either pass the > instance being changed to the __init__ method and save it as > self.model_name or pass it to the save() method and use it instead of > creating a new one, depending on the situation. > > I don't know if that's the standard solution, but it seems to work. > > > > > > DataFly.Net Complete Web Services http://www.datafly.net --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Custom manipulators: How to associate a model?
When writing custom manipulators, how do I associate my model with it? Using standard manipulators, I do something like this: manipulator = MyModel.AddManipulator() But for custom manipulators, I do something like this: manipulator = MyManipulator() So, if I later do a manipulator.save(), how does django know what model we're dealing with? The docks are pretty sparse about custom manipulators. Thanks, Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: How to use month/date/year menus for date?
> On 9/3/06, Jakub 'teodor' Krajniak <[EMAIL PROTECTED]> wrote: >> Sean Schertell wrote: >> (...) >>> The question is, how can I get those three menus to create a single >>> date object that plays nice with Django? >> >> I think that writing CustomForm with SelectFields would be good idea. >> Next in views or in overwritten save() method, >> you could join data from those fields into one date field and save >> it. >> See in django source how is written ChangeManipulator. > > I would also use a custom form. > > Also, if there are more than two or three date fields, it may be > worthwhile coding up your own subclass of django.forms.FormField or > django.forms.HiddenField, which renders the three drop-down lists and > does the validation. > > Alan. Thanks Alan and Jakub. It seems like I've found the first chink in the armor. In my opinion, the worst sin a framework can commit is getting in the way of accomplishing basic, simple tasks making you work *harder* to accomplish something that's normally easy. This looks like one of those cases :-( Oh well, off to research CustomForm with SelectFields -- hopefully it's easier than it sounds. Thanks for the tips, Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: How to use month/date/year menus for date?
Thanks for the tips folks. I'm a little surprised that Django makes you work so hard to make such a totally standard form element (a date as three pulldown menus). Is there really no easier method? Sean On Sep 3, 2006, at 1:31 AM, Jakub 'teodor' Krajniak wrote: > > > Sean Schertell wrote: > (...) >> In my view, I'm using FormWrapper and that automatically makes a text >> field for the date where the user is expected to enter the date as >> -mm-dd. Personally, I think that's not the most user friendly way >> to collect a date from the user. I like the more typical method of >> having three select menus: one for month, one for date, and one for >> year. >> >> The question is, how can I get those three menus to create a single >> date object that plays nice with Django? > > I think that writing CustomForm with SelectFields would be good idea. > Next in views or in overwritten save() method, > you could join data from those fields into one date field and save it. > See in django source how is written ChangeManipulator. > > Regards, >Jakub > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: How to use month/date/year menus for date?
Sorry, perhaps someone can clarify this for me -- or maybe I didn't
ask my question very clearly.
I have a model called Event. In that model, I have a line that looks
like this:
date = models.DateField()
In my view, I'm using FormWrapper and that automatically makes a text
field for the date where the user is expected to enter the date as
-mm-dd. Personally, I think that's not the most user friendly way
to collect a date from the user. I like the more typical method of
having three select menus: one for month, one for date, and one for
year.
The question is, how can I get those three menus to create a single
date object that plays nice with Django?
Thanks,
Sean
On Sep 1, 2006, at 11:55 PM, coulix wrote:
>
> Building a menu i dont know,
> bu getting the data yes
>
> exemple the month list of a Entry model with a create date field.
>
> month_list = Entry.objects.dates('created', 'month')
>
>
> >
>
>
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
How to use month/date/year menus for date?
Hi, My model has a date field in it and I want to collect that data in my form with a more traditional method than the default text field that the FormWrapper generates. I want to use three select menus with month/date/year pulldowns. What the best way to do this while keeping my model happy? Thanks in advance, Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Advice for Rusty Python Programmer and New Django Consumer
I'm new to Python but not new to programming. I picked up this book recently and couldn't be happier: Beginning Python: http://www.amazon.com/Beginning-Python-Novice/dp/159059519X/sr=8-4/ qid=1156946981/ref=pd_bbs_4/002-6713626-9604860?ie=UTF8 You said you're not new to Python but I wouldn't be too put off by the word "beginning" in the title. This is no "dummy's guide" to be sure. The explanations are very well thought out, usually with a problem and solution and then an even better solution. Leaves you with a very clear understanding of how to do things rather than just a book of magic spells if you see what I mean. Highly recommended (although I'm only halfway through the book so far). -Sean On Aug 30, 2006, at 9:54 PM, Jon Atkinson wrote: > > For a quick update on Python's data structures, I always find Dive > Into Python by Mark Pilgrim to be a good read. > > The book is FDL, and you can read it online here: > http://diveintopython.org/toc/index.html > > --Jon > > On 30/08/06, Pete Abilla <[EMAIL PROTECTED]> wrote: >> Group: >> >> Any book Advice or good Sites to visit for a Rusty Python >> Programmer and New >> Django Consumer (aka - me)? >> >> -- >> Pete Abilla >> blog: www.shmula.com >>> >> > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Multiple choice conditionals in templates?
Thank you! I did read the template docs but I missed that one. Works great! :-) Sean On Aug 30, 2006, at 6:30 PM, Kenneth Gonsalves wrote: > > > On 30-Aug-06, at 2:45 PM, Sean Schertell wrote: > >> Obviously this doesn't work because you can't use "==" in templates. >> So how can I achieve this? > > use ifequal > > -- > > regards > kg > http://lawgon.livejournal.com > http://nrcfosshelpline.in/web/ > > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Multiple choice conditionals in templates?
How can I display different things in my template depending on the
value of a single column in my database?
For example:
{% for e in events %}
{% if e.status == '1' %}Buy
Tickets{% endif %}
{% if e.status == '2' %}SOLD OUT!
{% endif %}
{% if e.status == '3' %}Cancelled!
{% endif %}
{% endfor %}
Obviously this doesn't work because you can't use "==" in templates.
So how can I achieve this?
:-)
Sean
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Lost in the Admin section...
On Aug 23, 2006, at 5:32 PM, Reinhard Knobelspies wrote:
Thanks for all your help so far everyone. So I'm still in search of
answers to these questions:
(2) The 24 hour clock widget doesn't work for me. This is a nightclub
so shows are almost always listed as 7:00pm or 12:30am etc. (am/pm).
Is there a way for me collect this information more naturally in the
admin form and then convert it for mysql storage? (note: it needs to
be stored as a time object so it can be sorted chronologically)
(3) I'm using a pull-down menu for the event status -- using the
"choices=( ('1','blah'), ('2', 'blahblah'), )" format. I've also got
a sensible default selection. But the menu still displays this
option: "". How can I remove this option from the list?
(5) Nine times out of ten, the user is going to want to edit or add
events immediately after logging into the admin section. Can I set
the events list page as the index?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Lost in the Admin section...
Hi Guys,
A few things I'm trying to figure out -- any pointers would be great!
(1) My model includes an Event class. Events should be displayed
using the date as their name. So the name of the event might be
"August 25th, 2006". But if I add a def(self): __str__(self.date) to
the class, I get an error "__str__ returned non-string (type
datetime.date)" -- how can I make it a pleasantly formatted date string?
(2) The 24 hour clock widget doesn't work for me. This is a nightclub
so shows are almost always listed as 7:00pm or 12:30am etc. (am/pm).
Is there a way for me collect this information more naturally in the
admin form and then convert it for mysql storage? (note: it needs to
be stored as a time object so it can be sorted chronologically)
(3) I'm using a pull-down menu for the event status -- using the
"choices=( ('1','blah'), ('2', 'blahblah'), )" format. I've also got
a sensible default selection. But the menu still displays this
option: "". How can I remove this option from the list?
(4) I don't want to use Users/Groups/Sites at all. What's the best
way to make it completely go away?
(5) Nine times out of ten, the user is going to want to edit or add
events immediately after logging into the admin section. Can I set
the events list page as the index?
(6) I meticulously followed instructions for overwriting the admin/
base_site.html template. It worked before when I went through the
tutorial but now I can't get it to work for some mysterious reason.
I've checked all the obvious stuff and don't know where to go from
here. Any tips for troubleshooting this?
(7) For each band that gets displayed, there's an associated photo.
The admin section displays the filepath -- any way to get it to
display the actual photo instead?
(8) Any way to make the file upload a little nicer? Like to give you
some indication that something is happening (ideally a progress bar)?
Sorry to overwhelm the list with noobie questions -- I promise to
help out other noobs once I get a handle on Django :-)
Sean
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Admin section: Possible to integrate image manipulation?
Looks very interesting Bryan. But I wonder if you could tell me what advantages this would offer over just using the Python Image Library. Same question regarding Joe's suggestion of using pymagick. btw: Thanks Joe for answering my original question, a post-save hook sounds like just what I need. Sean On Aug 22, 2006, at 8:55 AM, Bryan Chow wrote: > > On 8/21/06, Sean Schertell <[EMAIL PROTECTED]> wrote: >> ... I need my client to be able to upload some images in >> the admin section, then have Python do some resizing >> and cropping behind the scenes ... > > Take a look at PhotoField. Sounds like it would provide exactly what > you're looking for. > > http://www.verdjn.com/wiki/PhotoField > > Cheers, > Bryan > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Admin section: Possible to integrate image manipulation?
I'm trying to decide whether to build my own admin section or use the free one. The thing is, I need my client to be able to upload some images in the admin section, then have Python do some resizing and cropping behind the scenes. Do I need to make my own admin section for this? Or is there some way to add that kind of functionality to the django admin section? Any tips would be very helpful (this is my first django project). Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Easy template vars question
Thanks Malcom. That's sorta what I expected to hear. I'm still trying to work out the best way to do what I want to do (mostly static websites with django's awesome templates and the occasional reusable django app plugged in). Maybe writing views for each page and setting those types of variables there is the better way to go after all. Thanks for the tips. Sean On Aug 18, 2006, at 5:28 PM, Malcolm Tredinnick wrote: > > On Fri, 2006-08-18 at 12:14 +0900, Sean Schertell wrote: >> Hi folks, >> >> Okay, so I got my little staticpages app working (thanks adrian), and >> now I can happily throw sometemplate.html in my templates/ directory >> and I can view the page at mysite/sometemplate. Great! And it extends >> my base.html template too so all my header/footer stuff is DRY. >> Hooray! >> >> But what about the bits that change from page to page, like the page >> title, or the body "id" attribute, html metatags, etc. Is there any >> convenient way to pass those values in from the child template? Right >> now I'm using blocks in my base.html like this: >> >> > [...] > >> Is there any way then to more elegantly set the page title, body id, >> etc without using blocks and without writing view methods? > > You have to do it the way you are doing it now. Template inheritance > only allows you to override blocks, not set variables in the context. > > Remember that you are in a slightly fringe area. Normally, if you were > having per-page id settings, you would creating the pages through > views > and you would pass in the appropriate id value(s). If you don't > want to > have views and just have templates, then you have to do it via blocks. > > Regards, > Malcolm > > > > > > > DataFly.Net Complete Web Services http://www.datafly.net --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Easy template vars question
Hi folks, Okay, so I got my little staticpages app working (thanks adrian), and now I can happily throw sometemplate.html in my templates/ directory and I can view the page at mysite/sometemplate. Great! And it extends my base.html template too so all my header/footer stuff is DRY. Hooray! But what about the bits that change from page to page, like the page title, or the body "id" attribute, html metatags, etc. Is there any convenient way to pass those values in from the child template? Right now I'm using blocks in my base.html like this: Obviously it would be much nicer though to have something like this: But then I have to set that variable in the view right? The thing is, I want to use url mapping to templates for static pages so that I don't have to write a view method for every static page of the site. Is there any way then to more elegantly set the page title, body id, etc without using blocks and without writing view methods? Cheers, Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [Solved] Re: Django chokes on template blocks?
Thanks Malcom :-) On Aug 18, 2006, at 10:58 AM, Malcolm Tredinnick wrote: > > On Fri, 2006-08-18 at 09:51 +0900, Sean Schertell wrote: >> Yay!!! It works like magic! >> >> Would anyone be so kind as to reveal the mysteries of this "Context >> ()" function? I'd love to know what this code is doing and why it >> fixes my problem. > > Context() isn't a function, it's creating a class instance > (django.template.context.Context is the class involved). The Context > class acts like a dictionary and a stack: you can push a new empty > dictionary onto the stack, fill it with keys and values, use it a bit > and then pop it off later to get back to your previous dictionary > instance. This feature is used in a few places, block overriding being > one of them. > > Regards, > Malcolm > > > > > > > DataFly.Net Complete Web Services http://www.datafly.net --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Solved] Re: Django chokes on template blocks?
Yay!!! It works like magic! Would anyone be so kind as to reveal the mysteries of this "Context ()" function? I'd love to know what this code is doing and why it fixes my problem. Thanks again everyone -- especially you Adrian H. -- you're too much! :-D Sean On Aug 18, 2006, at 8:34 AM, Adrian Holovaty wrote: > > On 8/17/06, Sean Schertell <[EMAIL PROTECTED]> wrote: >> --- modulalib/views.py --- >> http://rafb.net/paste/results/fzWg1g26.html > > The problem is in the staticpages() function. Specifically, the > default value for the context_processor argument is None -- which > means you're passing None to t.render(). Instead, t.render() needs to > be passed a Context object. Add these lines as the first lines within > the function: > > if context_processors is None: > context_processors = Context() > > Also, make sure to do a "from django.template import Context" atop > the module. > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django chokes on template blocks?
>> But django barfs up this error: >> - >> AttributeError at / >> 'NoneType' object has no attribute 'push' >> - > > Let's see the index template. :) Thanks jeremy, here's the index template: http://rafb.net/paste/results/X5LCeK54.html Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Django chokes on template blocks?
Hi guys, I'm trying to get my first django project off the ground but I've hit snag that I can't seem to get around. I've made a base.html template and an index.html template that extends the base (pretty standard stuff I think). But django barfs up this error: - AttributeError at / 'NoneType' object has no attribute 'push' - Huh? Here's a screenshot that should clarify: http://datafly.net/django-error.png Anybody got any idea why I can't use blocks in my templates? What am I doing wrong? :-) Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
OT: Sort messages by thread in OS X Mail
Hey guys, I hope I'm not the only schmuck to arrive so late to the "sort by thread" party. If any of you folks have a "django" mailbox for this mailing list in OS X Mail and you haven't tried using the sort message by thread feature -- you're really missing out! Just select your django mailbox, then choose "sort messages by thread" from the View menu. Neato! I'm sure you can probably do this in Thunderbird, Kmail, etc. But I didn't know OS X Mail had this feature (and it's really nice too). Hope that helps someone. Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Yet another "directory sutructure" question
Thanks a lot for the tips Malcolm... "suck and see", eh? Okay, will do ;-) That said, I'm still very interested to see anyone else's approach to this basic organization question. Any other thoughts out there? Cheers, Sean On Aug 16, 2006, at 9:26 AM, Malcolm Tredinnick wrote: > > On Wed, 2006-08-16 at 08:56 +0900, Sean Schertell wrote: > [...] >> Here's the type of thing I'm after: >> >> shared_apps/ >> mysuperblog >> mysuperforum/ >> >> sites/ >> mysite1/ >> base/ >>__init.py__ >> manage.py >> settings.py >> urls.py >> views.py >> templates/ >> base-template.html >> about-us.html >> contact-us.html >> www/ >> css/ >> images/ >> mysite2/ >> ... > > I don't see any obvious problems here. I also don't see that you are > locking yourself into too much if you want to shuffle things around a > bit later on -- given that you have already moved your > Django-application-level bits elsewhere already. That leads nicely > into > my next point... > > I would encourage you to just try it and see if it works for you. Even > if nobody else is doing this yet, I will return to one of my pet hobby > horses that we (collectively) don't have enough experiences to know > what > is universally best yet. We know what works acceptably well in a > lot of > cases (including areas like large newspaper sites). Not that this > should > discourage you from asking for a check for obvious problems (many > design > plans come unstuck at the first review), but I guess I'm saying not to > sweat the really fine points too much too early. Write a few pages, > hook > them up. See if it feels workable. Write a few more. If something > clearly doesn't work, it will generally show up early on and you won't > have wasted too much time. > > "Suck and see" is not a bad development strategy -- particularly in > Python. > > Cheers, > Malcolm > > > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Yet another "directory sutructure" question
I'm still not clear about the best way to organize my site directories. Can you kind folks please share your strategies? If possible, I'd like to keep my site bundled together -- I'm particularly allergic to the idea of storing all my sites templates off in a separate dir somewhere. To my mind, the site is the parent. The exception is any apps which are shared amongst more than one site. Another thing is... I'm a big fan of keeping my top level uncluttered -- anyway to do this? Here's the type of thing I'm after: shared_apps/ mysuperblog mysuperforum/ sites/ mysite1/ base/ __init.py__ manage.py settings.py urls.py views.py templates/ base-template.html about-us.html contact-us.html www/ css/ images/ mysite2/ ... So the idea is that each site is nice and tidy at the top level with three dirs. Django stuff goes in base/. Templates for my static pages unique to this site as well as my base template will live in templates/. And the stuff that get served directly by the webserver (media) goes in www/ Does this seem like a sane/workable approach? Anyone got a better way? Thanks, Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Creating a "mostly static" site with Django -- dumb idea?
Wow! Ask and ye shall receive! TemplatePages is *precisely* what I was looking for :-) I can't wait to get to the office and try it out. Yay! Sean On Aug 16, 2006, at 6:33 AM, Bryan Chow wrote: > > On 8/15/06, Sean Schertell <[EMAIL PROTECTED]> wrote: >> I'd really like to use Django templates and stay DRY by using the >> same base template for my static pages as I do for any apps in the >> site. > > On 8/15/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: >> ... you just need an easy way to serve those pages. Well, they >> have no >> need for anything context specific, so presuming you have a way to >> map >> URLs to the right template name, write a simple view ... > > Ian Clelland and I wrote a Django app that does just that (mapping > URLs to mostly-static templates). Our code also takes several other > issues into consideration, such as sanitizing the URL so that > arbitrary files on the filesystem won't be served. > > http://www.verdjn.com/wiki/TemplatePages > > Hope this helps :) > > Bryan > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Creating a "mostly static" site with Django -- dumb idea?
Hi guys, I mostly create pretty boring websites with little apps built-in. For example, a 6 to 10 page website full of static pages about a company, plus a couple of small apps -- maybe a blog or a custom photo gallery. I'm very excited about Django's approach toward keeping apps/ decoupled from the website -- so I can recycle! So the apps part of Django is fine. But the thing is, like I said, most of my sites are *primarily* static content, ie: about-us, company-history, etc, etc. I'd really like to use Django templates and stay DRY by using the same base template for my static pages as I do for any apps in the site. But I'm a little bit put-off by the "flatpages" middleware because it store the content in a database -- seems to complicate things unnecessarily (and seems to require a separate base template too). Soo what's a boy to do? Ideally, I want something like this: mysite/ apps/ blog/ ... templates/ static-page1.py static-page2.py static-page3.py static-page4.py static-page5.py static-page6.py blog/ view.py list.py (or something) Am I just totally barking up the wrong tree here? How do you guys do it? Thanks! Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Simple: How do you organize your directories?
Thanks guys! Very helpful tips :-) Sean On Jul 25, 2006, at 6:03 PM, Ivan Sagalaev wrote: > > Sean Schertell wrote: >> In the tutorial, it says to not keep your app in the document root >> for security reasons. Okay that makes sense. But what *does* go in >> the document root? > > I keep all my code off the webroot including js and css (I have > aliases > for them to be visible from the web). In the web root I tend to put an > index.html saying something along the lines "If you see this then our > server is misconfigured, mailto:; > > > > > DataFly.Net Complete Web Services http://www.datafly.net --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Simple: How do you organize your directories?
In the tutorial, it says to not keep your app in the document root for security reasons. Okay that makes sense. But what *does* go in the document root? I generally like to do things like this this: projects/ foo.com/ application/ public/ bar.com/ application/ public/ ...then just configure my vhosts to serve whatever.com/public as the document root. Is this a good way to do it in Django? Thanks, Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Any good Python book recommendations?
Thanks all, I'm leaning towards "Beginning Python: From Novice to Professional". The Amazon reviews sound right up my alley. Anyone had any experience with this one? Sean On Jul 23, 2006, at 3:11 PM, Alessandro Bottoni wrote: > > Sean Schertell ha scritto: >> Any recommendations? I'm brand new to Python and want to learn for >> use with Django. > > The two books I found most useful were: > > Learning Python > Mark Lutz & David Ascher > O'Reilly > > Python Cookbook > Alex Martelli & David Ascher > O'Reilly > > HTH > > Alessandro Bottoni > > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Any good Python book recommendations?
Hi guys, I've downloaded Dive into Python and it looks good. But I need something I can read on the subway or in the bathtub. Something I can dog-ear and highlight -- a real book! Any recommendations? I'm brand new to Python and want to learn for use with Django. Thanks! Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Is Django the framework I've been looking for?
Thanks everyone for your input. So far I'm really pleased with what I see. I'm gonna take Django for a test drive on a website project I'm about to start now and see how it goes -- but I do get the feeling I'm falling in love :-) The one thing I think I may miss about Rails most is Ruby. Python is absolutely gorgeous when compared to PHP or Perl (then again, so is toe fungus). But I think Ruby may have a slight edge in terms of elegance and terseness. But that's just based on passively reading some code -- maybe I'll feel differently once I explore Python's classes and get my hands a little dirty. Anyway cheers for the tips! Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Is Django the framework I've been looking for?
Thanks so much for your reply Adrian! Can you also please comment a bit on how well Django works in a shared environment? > How about memory footprint? Can I run 100+ > Django sites on a shared server and expect smooth sailing? Thanks! Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Is Django the framework I've been looking for?
Greetings Djangoers, I'm thinking of defecting from the Ruby on Rails camp because I think Django may be more in line with what I want to do. If you have a couple minutes, could you please tell me if I'm on the right track? What I want to do === Basically, I want to speed development of *websites* with applications built into them. Emphasis on the word "sites" as opposed to "applications". Almost every site I build has some element of interactivity, whether it be a simple contact form or basic shopping cart or full-on web forum. I tend to prefer building in these things myself rather than trying to wedge some 800 pound PHP monster into an otherwise elegantly coded site. I'd ultimately like to develop my own little suite of plug-in apps -- a basic forum, blog, shopping cart, etc. Then building a client's unstyled but semantically-coded working site would be totally trivial, and 90% of the work would happen after that in CSS land. That's the Grail for me ;-) Why I think Rails is the wrong tool for the job = I was really *really* excited about Rails when I first discovered it about a year ago (ask my poor wife how excited I was). But there are two things about Rails that are problematic for me. (1) Rails seems more geared towards writing single monolithic applications rather than websites with little apps built into them. I suppose I could explore the "plug-in" architecture more -- but I suspect it won't be as elegant as I'd like for building websites with mini-apps in them as described above. (2) I run my own shared servers. I need to be able to deploy 100+ sites on a single box. This is a nightmare with Rails because it hasn't had a very solid deployment platform (although maybe Apache2/Mongrel solves this). Rails also tends to eat RAM the way my mom eats cheesecake. Specifically what I'm hoping Django will do for me = (1) Portable apps across projects architecture. From what I've read, it sounds like a perfect fit for what I want to do. Is it really that great? (2) Stable deployment with mod_python instead of some wonky FastCGI jalopy. Is it *really* stable -- enough for mission critical production environment? How about memory footprint? Can I run 100+ Django sites on a shared server and expect smooth sailing? (3) I still get to keep most of what I love about Rails. Pure object- oriented MVC (MTV) development stucture, free stuff like form validation, code generation, pagination, input sanitization, etc. Is it true? What will I miss most about Rails? Sorry for the looong post. Any feedback at all would be very much appreciated! Cheers! Sean --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
