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. The simplest is problem the Item- ItemDecription pattern, which as an abstraction that models Car- CarModel
Simple Example class Car: vin = '' color = '' model = CarModel() class CarModel: modelName = '' make = '' so I may have a given instance of a Car with a given vin and color ( a silver Honda Accord) which is a given Model ( Accord ). This pattern is nothing new; it's a fairly common occurrence in lot of software, particularly anything involving Products. It's also fairly simple. But similar sorts of "common solutions to common problems" occur pretty regularly. Assets->CurrentLocation->OwningLocation, etc.. 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. For example, I could have Item-ItemDescription as a pattern of classes and then provide that "Car plays the role of Item, CarModel plays the role if ItemDescription", not through inheritance but through aggregation. Thus your local domain class of Car captures your specific domain information, but also picks up the data, and most importantly the behavior and relationships within the pattern, of Item. 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 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? ) Take care, Jay On Jun 10, 2:05 pm, Erkan Özgür Yılmaz <eoyil...@gmail.com> wrote: > Hi James, > > I've been searching for a good way of developing an open source Scheduling, > Asset Tracking and Project Management system too. > > But I think your idea is something bigger than mine. I was trying to design > a software system specialized for animation and fx studios. Actually, what I > aim is pretty much like this (www.shotgunsoftware.com). But also has asset > management and pipeline stuff. > > I would love to here more about what you have in you mind. > > E.Ozgur Yilmaz > Lead Technical Director > eoyilmaz.blogspot.comwww.ozgurfx.com > > > > On Thu, Jun 10, 2010 at 7:54 PM, James O'Connor <jayfr...@gmail.com> wrote: > > I've been toying with the idea of building some higher level > > components for Python. More of business frameworks for solving > > certain kinds of problems. Most of the frameworks I see for Python > > and Django are fairly horizontal and low level, for which I think > > there is a great need, but my interest is in building more vertical- > > market frameworks that developers and businesses can use as building > > blocks for applications (By horizontal I mean things like > > contrib.auth which solves a technical issue for pretty much any > > application and by vertical I have more in mind things like > > Scheduling, Asset Tracking, Item-Model sorts of Patterns and setups) > > > Does this seem like something people could actually find a use for? > > > -- > > 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<django-users%2bunsubscr...@google > > groups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/django-users?hl=en. -- 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.
