A: 

I've worked on a few web games in the past and, to be honest, none of them have ever needed anything this complex and unwieldy.

Robert Rouse
And that's why most web games suck ass, and are hard to maintain, and it takes months for new features to appear.
analytik
+2  A: 

XSLT can be bulky to manage, and essentially adds an extra programming language that developers would have to work in (at least if I understand your description correctly). My experience has been that relatively few people know it, and even fewer can make it do what they want.

acrosman
My experience with XSLT has shown none of these drawbacks.
dacracot
You raise a valid point about amount of people mastering XSLT; there is some dichotomy in coupling PHP with XSLT, but it seems to be the only formal language for transforming XML. I'll probably want to offer an alternative to XSLT. Thanks.
analytik
+1  A: 

I think you are looking at a highly complicated solution. It is a major effort to simply design and build out the Schema's that you will be using. If your on a project that involves more than 5-6 people total you likely need to have an organized schema design effort. I think this is a point you are aware of.

I question and possibly take issue of the selection of PHP on the front end. I also think you are deciding on XML in a large sense mistakenly.

Here is what I do:

  1. Build a service layer using Grails.org
  2. Keep every resource that can be RESTFUL in rest
  3. Use the X-fire plugin in Grails to build out any SOAP services that need to be built
  4. Take advantage of GORM and RAD functionality of Grails to reduce development time.
  5. Construct clients in X or Y language or platform to consume these services.

I definetly would want the speed of pure Java doing all of my XML translation/processing. If you have large documents then it will take considerable time processing these.

You understand the forces of your environment better than anyone, but I would caution you to do the simplest thing that works first and not over-architect.

DanielHonig
Thanks for the opinion. However, even when my idea is overly complex for a simple CMS, it won't involve lengthy document processing - I'm quite sure that processing my XML with XSLT in PHP will be much faster and a lot less complicated than calling a webservice that was built using YET another lang.
analytik
+2  A: 

I'm not sure what "flexible framework" to suggest to you either. It all kinda depends on what you're comfortable with and your personal taste.

One thing I do know is that, how appealing it may look at first, is to stay away from XSLT. Doing Hello World type stuff and simple examples with XSLT is pretty straight forward. However, more complex projects become completely unmanageable (not to mention unreadable) with XSLT. My experience is that it puts a massive strain on the project.

Luke
My experience with XSLT has shown none of these drawbacks.
dacracot
Thanks for the warning, much appreciated.
analytik
+1  A: 

What you describe could likely be implemented using tox. It uses a hybrid MVC-ARS architecture. The obstacle that I see is the cost point tox presents because of its dependency on Oracle. Of course, since it is open source, you could convert it to Postgresql.

dacracot
looking into it right now, thanks.
analytik
let me know if you have any questions about tox, the question button of the web site come to me
dacracot