... long live push. :)
> No more push. I don't even want that to be a word in our vocabulary any
> longer. :-)
Parts of this push v. pull discussion are troubling to me. As I understand,
the 'push' under debate is that Turbine populates a context object with
dynamic info that is then passed into the template engine - the 'push' - for
use by the template designer. This does have limitations, the main one
seemingly being that since the context is populated with java code you have
to modify java code to change what's available in the template.
Let me say now, tho, that I consider this to be one of the best features of
Turbine - and there are a lot of very good features :). The point of a
template engine like Velocity is to enforce the seperation of display and
logic in an app. The context mechanism enforces this at the runtime level
as well. The only info available to the template for a particular screen is
what's relevant to that screen (more or less.) But more importantly the
objects that the template is accessing are simple, data-only (to the best of
my knowledge) and do not have to go back into the system programatically to
get an info.
I point this out because some of the 'pull' suggestions that seem to be
under consideration suggest putting much more complicated and general
objects in the context for access by the template engine. I think this is
the wrong way to go, especially if what this means is that there are APIs
accessible in the template that can actually go back into the server, query
the database, change state, etc. This would seem to break the seperation of
logic and display that the template engine is there to enforce.
There are other ways to address the limiations of the 'push' mechanism - see
my previous post.
My 2 cents,
PaulO.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
