> The decision to implement "pull" or "push" really rests in the hands
> of the page designers. Although there will be some advantages to
> "pull", like the ability for someone creating a "wizard" to pick and
> choose what data to place on what page, the "push" model is still
> extremely easy to use and requires less "programming" on the part of
> the page designers.
> There is lots of talk about creating that boundary between content and
> view. But, in the end, no tool will solve it completely (although
> Turbine and Velocity are a good tool to use). It would be impossible
> (in my humble estimation) to make a product that forced this boundary,
> because for one application, it will be necessary to do 90% push/10%
> pull, and for another, it will be %10 push/90% pull.
>
> The question comes down to this: who programs (yes, programs) the user
> flow? If you don't want your web page designers "programming"
> (whether that be in Java, JSP, or VTL), then you better go 100% push
> and let the application engineers do the programming (of both the
> content and the user flow). But, if you want the web page designers
> to do the flow programming, then go for a bigger "pull". The page
> designers will have to become fluid with programming VTL, but it isn't
> a difficult language to learn... just limited.
Are you sure you got it right, im having trouble seing how the pull model
requires the web page designers to do more programming.
> If I have a global PullTool but no default screen of my own, has does
> the PullTool get added to the context? Or am I missing something
> obvious...
>
TurbinePullService is where the magic happens.
- Kasper
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
