On Sep 21, 4:26 pm, "klaasvanschel...@gmail.com" <klaasvanschel...@gmail.com> wrote:
> One thing that deserves extra stress is that apss should be easily > extendable. Exactly the fact that every customer want something that > is slightly different from the next is how we're able to provide > value. (This is also the reason I like Django in the first place: > making stuff "your own way" is very easy). So: if no one want exactly > the same, extensibility is a major prerequisite for reusability. I've used several different frameworks and languages and all of require the developer to have a special kind of discipline if you are going to write apps (modules, classes, beans whatever the framework calls them :) that are 100% reusable. The challenges are *always* the same: * Easily extending an app without breaking upgradeability. * Dealing with interdependencies between apps, particularly where upgrades and patches are concerned. * For web apps, Dealing with graphic design issues where we want to be able to customize, but we don't want to lose compatibility with future versions. * Presenting back end screens. For me, Django has been a remarkable improvement from php and Python based tools I've used in the past primarily because Django isn't a content manager that is being devolved from its original form to create a new application and Django isn't a framework that forces a strict way of doing things on you (see cake and Smarty from the PHP world). If anything loose coupling is what makes all of this so difficult - and so easy. Django begs you to write lots of simple apps and tie them together - the question is how to tie them? In my case I've found that django.contrib.auth.user is a great tool for simplifying things, and if you d things right, you can leverage Django's automatic two way relationships to avoid using lots and lots of decorators to control access. I'm sure there are other ways to do things, and probably some that might be better (most of what I've been working on is very transaction centric, so who has access to what transaction data is the question, not who has access to what view). Another item that is particularly challenging is that Django doesn't do hooks the way that some php based systems do. Want to extend something? Hook it. It's super easy for the developer, and can protect upgradability if the programmer maintaining the function you are hooking cares about backwards compatibility and doesn't go renaming everything. On second thought, I hate hooks :) -- Mike -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
