The configurable PULL MVC is the way to go IMHO!
Daves approach with the TemplateTag and the XML configuration
seems to be a good idea. But for a simplest PULL implementation
its initially an overkill.
My 2c: currently I'm experimenting in using Velocity as the
configuration language - instead of writing XML and the parsing
application! The approach seems simple and is yielding fruits!
Extension is done via templates/control and mainly reusing
predefined java classes (e.g. url/script calls, file loads, dir
list access). Additional classes may be placed in the webapp and
be accessed either as static functions, singletons, or as beans.
Velocity can place parameters into the context via the #set
directive to be used by the PULL MVC pattern. By adding some tools
to the control context allows instantiating/calling any java class
and placing the resulting objects into the screen context.
I'm using a templates/control path and a VelocitySiteControl class
(a VelocitySiteScreen extension) that loads a control template that
defines the context for the screen/navigation/layout. It essentially
maps actions to the template/control pages and provides a default
control action for every screen.
The VelocitySiteControl also loads a set of constants at startup
(from a *.vm file!) defining constants and context objects for
every screen. It also could load a defaults.vm file before the
control template is loaded/run (could be done also by a #parse
within the control template itself).
I'm also thinking in using a $param stack to pass in and out values
to views (essentially reusable velocity screen fragments) to be used
as a HVMC pattern. This will avoid poluting the main screen context
with variables.
The above stated adds the long-missing control branch to the
Turbine Model2+1 paradigma, making it a real HMVC. Maybe a
module/control could be added to tubine with the Control!
I guess the driving of it could be an extension of
TurbineVelocityService which is currently defining the default
context contents (e.g. make these configurable via a controller!).
I'll post more when I have the pattern running.
Any interest, ideas, comments - specifically in using velocity as
the controller scripting language setting up the Pull MVC context?
:) Christoph
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
