@Ian: Each dynamic part of the code is a component, and is marked with a generated ID. When the user hits a button or link to initiate an action, it initiates a XMLHttpRequest that tells the server what action to perform on what component
Sounds pretty cool, and I think it's a good approach. The only challenge is the underlying platform, as you mention.
@Andrew Barry: I'd argue that this was an implementation detail rather than a key requirement
I'm not sure what you mean exactly, but the main reason I commented on the dialog box example is that I personally don't agree that "regular applications are often a sea of interconnecting MVC applications." Though to be fair, I don't really have enough context to know what you mean.
The core issue is how confident you are moving your business logic down to the client ... If the data in the database was well secured, then I'd have no trouble opening up SQL access directly to the client
This approach doesn't seem right to me. A lot of this is due to the fact that I, "well secured" is sort of a matter of perspective. It also probably helps to remember the context: a small company with little or no dedicated programmers on staff.
The sort of strategies that would be approriate for an internal enterprise app or even a public app with a dedicated technical staff has more options. In this case, the app needs natural barriers in place. One of those is not exposing raw SQL queries and internal structure in the JavaScript.
Oh yes, and PHP is truly horrible
As a language, I think it's actually pretty good. The problem has historically been lack of design patterns or built-in frameworks. The Zend Framework may change that. It certainly can't do the acrobatics that Ruby can, but it is a fairly dynamic language and is ridiculously fast, which puts it ahead of a lot of other options.
@Sean: For what you are trying to achieve I would suggest that if you approach writing the client web app with MVC and look at the 'server side' as just another mechanism for accessing data
In theory, I agree with this. In practice, I still actually have to implement each side using a completely different language, frameworks, etc. The main question I had when I posted this is: what do people do to unify the two separate worlds? The answer I've seen so far is that there really is no unification for the most part -- although things like Jaxer seem to be moving in that direction.
by Scott Stevenson — Aug 03
Sounds pretty cool, and I think it's a good approach. The only challenge is the underlying platform, as you mention.
@Andrew Barry: I'd argue that this was an implementation detail rather than a key requirement
I'm not sure what you mean exactly, but the main reason I commented on the dialog box example is that I personally don't agree that "regular applications are often a sea of interconnecting MVC applications." Though to be fair, I don't really have enough context to know what you mean.
The core issue is how confident you are moving your business logic down to the client ... If the data in the database was well secured, then I'd have no trouble opening up SQL access directly to the client
This approach doesn't seem right to me. A lot of this is due to the fact that I, "well secured" is sort of a matter of perspective. It also probably helps to remember the context: a small company with little or no dedicated programmers on staff.
The sort of strategies that would be approriate for an internal enterprise app or even a public app with a dedicated technical staff has more options. In this case, the app needs natural barriers in place. One of those is not exposing raw SQL queries and internal structure in the JavaScript.
Oh yes, and PHP is truly horrible
As a language, I think it's actually pretty good. The problem has historically been lack of design patterns or built-in frameworks. The Zend Framework may change that. It certainly can't do the acrobatics that Ruby can, but it is a fairly dynamic language and is ridiculously fast, which puts it ahead of a lot of other options.
@Sean: For what you are trying to achieve I would suggest that if you approach writing the client web app with MVC and look at the 'server side' as just another mechanism for accessing data
In theory, I agree with this. In practice, I still actually have to implement each side using a completely different language, frameworks, etc. The main question I had when I posted this is: what do people do to unify the two separate worlds? The answer I've seen so far is that there really is no unification for the most part -- although things like Jaxer seem to be moving in that direction.