Diez B. Roggisch wrote:
>
>
>
> *BUT* given the massive MS-and-enterprisy background of your project,
> I could imagine it would be better implemented in the MS-websolution
> to-jour (possibly even PHP), because you will have way less friction
> when being able to run on the CLR or at least easily access
> webservices build by it (*NO*, SOAP is not a standard, it's a
> nightmare in disguise of a standard) and is easily deployed because MS
> already paved the path for that, and so forth.
>
> Of course this reasoning does only apply if you really interface with
> code, not "only" with a database.
>
> Bringing an additional toolchain into the mix makes it harder to
> maintain, acquire new talent to work on it (hands up who's proficient
> in the MS-technologies *and* full open source stacks) and thus might
> be more frustrating than the possible gain from a nice, clear-cut MVC-
> based RAD-tool like TurboGears. Especially since essentially
> everything one does ends up in layers of proprietairiness anyway
> (regardless of stack and environment).
>
> Diez
>
>
>
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.
--
View this message in context:
http://old.nabble.com/Why-TG-is-a-better-option-than-RoR--tp31033408p31054232.html
Sent from the Turbogears General mailing list archive at Nabble.com.
--
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.
