On Jun 11, 7:17 pm, "James O'Connor" <jayfr...@gmail.com> wrote: > Wel what I have in mind is wondering if it would be useful to build > full implementations of what would normally be called "Analysis > Patterns", like Designed Patterns but commone object modeling > solutions to common domain problems.
I've been struggling with much the same idea through several technical platforms (I am an old Smalltalk programmer, too). My conclusion has become that starting with the abstractions can cause a lot of problems. I have evolved to starting with the particular (concrete users with concrete problems) and generalize reusable apps from several instances of them. That's a slow way to go. We'll see if it proves out. I do have common patterns in the back of my mind, but they tend to miss a lot of the interesting real-world kinks. > So what I've been thinking about is building up implementations of > those patterns as re-useable components. Similar to what we have in > infrastructures that handle common problems at lower levels (anyone > actually written a CGI handler recently?). When I worked in Smalltalk > I did very similar work and one thing I worked on was the idea of > building up such patterns as interactions of Roles and being able to > assign other classes to play certain roles in those patterns. I tried an Inventory app like that once, which you can see here: http://dpaste.com/206415/ I had in mind a set of reusable/plug-compatible business apps in Pinax style, but never went any farther, because it always smelled like premature abstraction for the actual projects I had going. I'm also an old ERP programmer, and consider those systems to be dreadful design monstrosities, so would not like to work on anything that emulates them (which is what I see in most open-source business software projects). > Now, as I was thinking about that, I ran across the issue that , at > least with Django (and TG, IIRC) you can't simply write python classes > and count on them to be put in the database properly. They have to be > subclasses of objects.Model. The good part of this is that when you > write your classes, you get DB support for free. The bad part is that > it's a little harder to write "Architecture Neutral" domain classes so > you need implementations of your domain architecture written against > several possible ORM architectures If you use abstract base class models, you can separate yourself from the DB in Django, but not from the ORM architecture. (P.S. I don't think that "Architecture Neutral" domain classes would be useful. You'd do lot of this stuff differently in Smalltalk, for instance. Almost the same for different ORMs.) > So, I've been wondering if this is a bit idealistic or whether it > could be of use to anyone (yeah, I can write it, I've done it > before :) would anyone use it? ) Brian Rosner's django-groups is a Django app that is actually being used that might be close to what you have in mind. http://github.com/brosner/django-groups It gets mixed reviews: powerful, flexible, ingenious, but some people find it easier and simpler to roll their own. And Brian generalized from some earlier use cases, he did not start out with the abstraction. -- 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.
