Re: magic-removal: plans/estimates for the trunk-merge?
Hi I have been using it, and I have found a few bugs. Some posted some not. An example would be the limit_choices_to. But Luke fixed it almost stragith away. There is also every changing landscape, just take a look at the commit log. http://code.djangoproject.com/log/ The point is to develop an application which will support a business requires at least two things I think: 1) All the features you expect should work. Ie it must be polished. the limit_choices_to is an example of small feature that got over looked in the MR changes originally. 2) Stability, you cant spend weeks developing stuff and then have one change to framework complelty change the landscape forcing you to recode some stuff. Its not that I need someone to ';bless' it, its that I want it stabilised, made whole and complete and new branch made to continue all the raidcal and experimental stuff. That said, MR is openly advertised as a development branch. So you cant expect the above. However I am not comfortable starting a project against the current 0.91 because I beleive some of the changes in MR are key. In fact MR branch syntax and features are what made choose Django over dozens of other frameworks. Which is why I mentioned above a stable release of it would be brillaint. But its shapipng up to be a really nice framework :-) C --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: magic-removal: plans/estimates for the trunk-merge?
Hi I am very interested in starting aproject at my company in Django, but am not keen on starting one of 0.91. So I am hoping the MR will be merged soon too :-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
MR: Bug with Class Meta verbose name
Hi I think I have found a bug in the MR branch with verbose name. According the (out of date) documentation verbose_name_plural will use verbose_name + 's'. However when I just set verbose_name, Admin still shows the wrong name. If I set the verbose_name_plural, it works. Example: Class TelDirEntry(): class Meta: verbose_name = 'Telephone Directory' In admin this shows 'TelDirEntrys' as the name. But Class TelDirEntry(): class Meta: verbose_name = 'Telephone Directory' verbose_name_plural = 'Telephone Directory Entries' will produce ''Telephone Directory Entries'' in admin. Any thoughts? Thanks, C --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: magic-removal: plans/estimates for the trunk-merge?
This is a common thread :-) and one I am interested in, but you can search the forumn for the results. Bascially it will be done when its done it seems :-) S --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: also: multiple databases
>However, I don't like it if it's going to be introduced as a scaling >solution; I'd rather have the various tiers of infrastructure (load >balancing at the front, application in the middle, database in the >back) remain as loosely coupled as possible. Absolutly, scaling is the last reason to introduce it and is not in anyway why it a such feature gap. As mentioned, there are dozens of scenarios in modern cororations where you have access multiple databases. I could a several tens. Take the company I work at now. We have an ERP system in oracle. The ERP system itself splits its data in 3 seperate instances (SYSTEM/CONTROL/DATA). We then have business intellgence system. We have EDI systems. We have a zillion dodgy access databases. We have home grown maintaince systems. A lot of the requirements for building websites is to show data from multiple of these systems. While this can be done with pure SQL now, it would be nicer if it could done through the ORM because of all the benefits that brings in Django. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: limit_choices_to
I used it on several examples and in each case it worked. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: limit_choices_to
Your patch seems to be work. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Fixing edit_inline on magic-removal
I am +1 on the idea of a feature freeze and was going to make a seperate post on this idea but read this post first. I think there is a lot of good stuff in MR now, and a move towards getting a stable version 0.92 with these features would be brilliant. Naturalyl I want all the future proposed functionality, but I think MR have enough meat to count as very usefull improvment over 0.91, assuming its stable. So I am all for locking down the features and then polishing it up and getting it stable. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Tutorial updates for magic removal
On the Ticket. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Latest MR Branch and "_user_source"
Hi This worked. I take it Request User Middleware is now always required ? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Tutorial updates for magic removal
Hi Added an attempt at Tut 4 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Generic View - Proposed Patch for 'template_model_name'
Also one more point, which Tom did point out. This is a use it if you want it feature. If you like generic names this wont change anythign your currently doing. So you increasing the flexibility of Django. Giving more features not less. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Generic View - Proposed Patch for 'template_model_name'
I can see how on occasion you might swap out one template for another, but its more a rarity (in my experience). I agree with Luke, in that templates are alsmot always specific. Why not help make them more readable and easier to use? If you go along with the idea that template designers are not coders, then it makes more sense to give then names they understand. This idea should make it much more non-coder friendly. And as a coder myself, I have, after years of doing ERP coding and web ERP coding, come to the conclusion code can never to be too self documenting. object list means nothing without a specific context in which to place it. survey_list or person_list is immedialy more specific and thus more relevant and easier to understand. As to Toms response, I highlight the word VIEW. Generic View. Not Template. And yes this would make generic views more generic and templates more specific. Which is entirly the point. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Generic View - Proposed Patch for 'template_model_name'
Yes Generic VIEWS. Where does the word veiw imply template? The view is generic the template is specific. My proposal is make the views even more generic and templates even more usefull. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: magic-removal Q: tagging/auditing functionality -- howto
Hi I have been thinking about doing something like this, and it seems you probably would have to use the new save() method. However you would still need a model for each history table. Although I was toying with a genric history table (more akin to a log) where you could then easly code it up once and reuse it everywhere. Still pondering at this point though. If you get something let us know. S --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Re: Magic-Removal Branch
Hi I am using manage.py from /manage.py Can you send me an examlpe model file ? I would just like to make sure it nothing do with my typing. Thanks, S --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
Magic-Removal Branch
Hi I hope this is the correct place. I just took downloaded the magic removal branch, and entered some models in the new way. manage.py sql* functions dont seem to work. if i run the manage.py shell, and import manually it appears to work, but manage.py sql or sqlall or install, just error. Is anyone else noticeing this ? Thanks, error dump: BEGIN; Traceback (most recent call last): File "H:\Programming\Data\eefy\manage.py", line 11, in ? execute_manager(settings) File "H:\Programming\Python\Python24\lib\site-packages\django\core\management. py", line 1230, in execute_manager execute_from_command_line(action_mapping) File "H:\Programming\Python\Python24\lib\site-packages\django\core\management. py", line 1198, in execute_from_command_line output = action_mapping[action](mod) File "H:\Programming\Python\Python24\lib\site-packages\django\core\management. py", line 353, in get_sql_all return get_sql_create(app) + get_sql_initial_data(app) File "H:\Programming\Python\Python24\lib\site-packages\django\core\management. py", line 292, in get_sql_initial_data app_label = app_models[0]._meta.app_label IndexError: list index out of range --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers -~--~~~~--~~--~--~---
