Malcolm -- Thanks for taking the time to read it and write back. I apologize if what I said at first didn't come across clearly -- I often need two or more stabs at explaining something before I get it across with its semantic integrity still in place.
It's not clear what problem(s) you are actually trying to solve here in > these paragraphs, so your ideas come across as a little abstract. Okay, that seems like a good place to start. Problems: 1) While there is a good degree of drop-in replacability of parts in the Django stack as I outlined (db backend, authentication backend, etc.) there is not a clean way for programmers to grok what specific contract various components have to comply. An example: How do I implement a template loader? While I can trace the behavior of the existing template loaders and try to guess what each of the methods do and the data that their arguments and return values should contain, there is not a defined contractual interface for a template loader. I have no way of knowing that the "filepath" returned from load_template_source will then be expected to be used by Template's origin kwarg for reloading the source. The Django team put so much effort into making these parts componentized without having a component system to delineate and document contracted interfaces. 2) There is not replaceability for every component unless such replaceability is specifically engineered in by the Django team. An example: I want to replace the session backend with something not database bound. I can't until Django commits an extensibility for that interface. Or I want to have User objects that implement additional methods, but if I subclass it then all of the other apps won't use instances of my subclass and won't have access to my extensions. 3) Without some sort of agreed upon standards to support interaction between apps, we will not be able to harness the wealth of django apps being written right now into complete, integrated sites. An example: I like Suzy Creamcheese's Blog application but she used django.contrib.comments in it, and I want Joe Schmoe's slashdot style commenting system. I also want people who have blogs to be able to post their own photos, but Suzy Creamcheese's Blog application uses a BlogAuthor model for biographical data and needs it set as the PROFILE model and John Shaft's photo gallery application uses a Profile model for biographical data and also needs it set as the PROFILE model. I can't integrate these without hacking on them. But if Suzy wrote her Blog application to implement IBlog and IBlogManager which contained extension points for IComment and ICommentManager, I could integrate the two systems without having to alter code. And if both the BlogAuthor model and the Profile model implemented the same interface then I could still use them together as User can provide the extension point for that interface. Or if I'm using Satchmo and I've written an excellent CRM system in Django, I want Satchmo to use the shipping and contact information that I've defined in my CRM system, and if they both implemented IPerson, IPostalAddress, and IPhoneNumber, I could drop in those replacements. Without that, I'm bound to either duplicate my data across the two applications, hack Satchmo to use my CRM, or constrict my CRM system to require Satchmo. Firstly, you seem to be conflating core and application, which is a > misunderstanding. django.contrib is just one directory where > applications live. It's only "special" in that it's owned by Django > itself -- i.e. it's where the maintainers might put any apps we ship > with Django. But that's the complete limit of it's specialness. Apps are > just importable Python packages. Stemming the proliferation of > applications sounds like an anti-problem: we want to encourage people to > write apps, not stop them. I don't have any such confusion in my head. I know that django.contrib is for apps that Django has blessed as standard and other than their integration into the default DJango build, there's nothing special. I'm not wanting to stem the proliferation -- I'm wanting to maximize the integration and utility. Including an application in django.contrib is one way for the community to enforce standardization. If Django Tagging were included in django.contrib, if I were writing an application that needed tagging services, I'd just use django-tagging because everybody who has django has django tagging. It would be foolish of me to require a foreign dependency. But I don't think we necessarily want to as a community try to produce canonical, standard applications and continue expanding contrib for the utility applications that we all reimplement. Secondly, keep in mind that infinite flexibility is not necessarily a > pragmatic goal. Partly because it means you spend forever tweaking the > interfaces between sections and it actually restricts what you can do > (because any single change has enormous external implications). Django > already allows a lot of replacement of core components. ORM, templates > and URL dispatching can all be done by other means if you like. You can > use whatever web front-end you like and we have plans to fix things like > the slight WSGI incompatibilities we currently have. Besides those > things, there's not much else in core when you break it down. In most > cases, it's not even a lot of code to do these replacements. I totally agree. Having this sort of interface definition does require much more planning and more difficulty before breaking exposed interfaces. Perhaps at this young age of Django, it's inappropriate to discuss a component framework and just rely on the solid engineering to have fuzzily defined components. But there is not (necessarily) the same sort of discoverability, rigid contractual obligation, or interchangeability of these components. Like I said, we have all of the intention of a componentized framework without any of the actual code to make it work like one should. So maybe there is a particular thing you are trying to solve here. If > so, have another shot at explaining what it is, with real-world > examples. Which pieces aren't flexible enough? Abstract conversations > aren't particularly productive (and you'll see that they've come up here > before) because there's no path towards any sort of goal that comes out > of them. Django strives to find a reasonable between "batteries > includes" and allowing customisation. Where do you want to tweak that > balance? Does what I said above provide some more concrete definition as to what I'm thinking? Let me know if I need to explicate further. Thanks again for taking the time. -jag (aka j00bar) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
