[Templates] Template Tookit Vs HTML::Template

[Rafiq Ismail (ADMIN)]

On Wed, 20 Nov 2002, Andy Wardley wrote:

> Perrin Harkins wrote:
> > That definitely is what I've always meant by MVC.

> When I said "Most people don't seem to understand MVC..." I should have
> added "...present company excepted, of course"  :-)

I'm likely to be in the prior camp.

> course :-) would have you believe that HTML::Template is the only
> template module worth using because it's the only one that supports MVC.

I've heard this a lot in the past couple of weeks.

> These people are not worth saving...  It's too late for them  :-)

The problem is that to get things done, sometimes you have to do this.

> As I was writing my tirade, I did wonder if you could build a pure MVC
> system, treating each incoming URL like a controller and each side-effect
> (including data impressions, page generation, etc.) as a view.

I've built a system here, which was originally spec'ed to work through
different interfaces, shell, apache, whatever.  I was told not to tie it
to one technology and allow it to spew out any out put format.  I've built
a system, which is either MVC or not, however essentially it falls down to
a set of 3 subclasses Model, View and Control (surprise), in which we see
the following behaviour:
	* Control
		- subclassed per interface passing it request, key
		strokes, whatever.  Encapsulates Parent Model and Parent
		View objects.
		- determins 'which' models are required.
		- Builds up a ViewModel, through it's interfacing with
		  model.
		- Request all Views to be rendered
		- sends views output to whatever output device or
		  'driver (like a filter)' requested.


	* Model
		- represents data logic
		- data access methods.
		- subclassed per entity involved in problem domain
		- can hold submodels, each with generic interface
		- can request specialised views (EMAIL, FAX) whatever,
		  in addition to the main view which was originally
		  determined by control.
		- Control cascades through Models based on input/request,
		  however model can 'request' submodels added to this this
		  chain of handlers.

	* View
		- All going through tt2
		- subclassed through different presentation mediums (HTML,
		  PDF, XML, EMAIL which perform i18n tweaks and medium
		  dependent tweaks before processing.
		- Templtes have plugins for designers and i18n plugins
		  related to the current language, wrappers for
		  Dynamic Translation::Language models.
		- pass requests to control for any specialised response
		  when  presenting the view.

	Does it have to be this way?  Dunno.
	The beauty is that I have a neat object orientated project which
properly encapsulates each 'area' of each 'domain' which I'm dealing with.
I can sell it with a buzz-word and I have generic-reusable mechanisms
where the involved objects can have a say in how their handlers are
overloaded, without making the decision or taking the action.  Thus I have
one point of reuse and subclass at will..

It's a little tidier than it sounds.  I also have an acronym to sell it
buy.  What I've taken out of MVC is:

1) The idea of MV and C being able to address one another, and adjust the
final result, prior to it being re-rendered on the screen, fax machine, or
whatever else

2) Clear subclassing and parent child heirarchies.

3) The headache of explaining it to others.

I guess there isn't a clear guideline of what MVC means in terms of a web
environment, but the fact that we are still using the acronym, shows that
the important aspects of the original paradigm come from it's separation
of the 3 domains, whilst still maintaining uniformity in behaviour across
all cases determining how an object behaves.  I think that for me it comes
down to one api for everything and fitting that in anywhere.  The
subclasses request events and the control knows which callbacks to use.

What am I getting at?  It's an approach to solving a problem.  It's a
framework and how each person adapts it, will be derived from her problem
domain.  I'm not writing a window manager, thus I can learn from the
original idea, without having to stick by it dogmatically.  I can use the
acronym to make managers smile.

Perhpaps the way forward would eventually come from one standard way of
building such architectures finally being discovered as correct and
efficient.  Personally, I think that MVC gives you boundaries and there
after TMTOWTDI.  And on that note, being distracted by other things, I've
lost my train of thought and will now end. The end.



R.