> Well, buzzwords depend on background: I find a lot of the Python stuff > equally confusing :) But you do raise some very important points. About > the only reason I'm considering Visual C# is because of the mix of > technologies. > > Also, it depends on your theory of who should be developing. Some of the > reasons the company I have just left is getting into problems with more > complex implementations is that they expect their engineers to design and > develop the entire stack, as well as integrate with 100s of target > applications. > As a result, the design and architecture side of things suffers badly, and > some of the code is pretty bad as well. > > The current front-end (such as it is) was developed using a proprietary IDM > tool customized with javascript: basically the UI and business logic is > javascript contained in a sort of workflow engine, which is extremely > inflexible and inefficient on developer resources as well as run time. > > The architecture is very loosely coupled at this time, most integration is > done through the DB. > Most of the real work is either done off-line, driven by source system > feeds with applied policy to generate the necessary access requests, with > the balance being either dumping requests into SQL Server using stored > procedure interfaces (which are then scheduled into a process queue in the > DB), or allowing users to perform approval and other functions from work > lists in the DB. > > I know that can all be decoupled, as that is the situation today. Today > clients have embedded the application into existing Java forms hosted in a > portal, as an example. > The same thing applies to the configuration management interface: it should > not require any more integration than DB objects. > > I am less certain about SSRS (SQL Server Reporting Services) integration, > but I assume that the SSRS reports should be embeddable as links into any > decent framework. > > While the current implementation is M$ based, over time I'd like possibly > to substitute out components for more open and robust solutions, but > that's another discussion.
Funny, this sounds a lot like financial industry or government to me (spent years in that sector). Here's a point that hasn't been made yet: you can pretty much skip all the ORM features of SQLAlchemy and just issue plain old SQL statements directly to the engine. That's one of the reasons why I used and still use TG. Personally I hate ORMs as for me - someone who can actually write SQL with no intention to switch databases - it's overly complicated to form a 10 line pretty much unreadable statement in python that's just one line in SQL. But that may just be me. The upside on using the ORM sure is the mapping which makes is very simple to access the data. Complicated joins however are a PITA with an ORM, so I use views and procedures for those, just to map them via the ORM in a simple "select whatever from (view, procedure) where (restriction)". Whenever I need to change the logic I don't even touch the python code - I just change the view or procedure and best of all I can do it while in production and the next request will get the new version. That really suits my insurance customers. Uwe -- You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en.
