[Xotcl] Announcing: Spindle v0.1 — An MVC web framework for Tcl/XOTcl

[Kristoffer Lawson]

On 22 May 2010, at 00:20, Victor Mayevski wrote:

> With your project people need to learn what MVC is, how it works  
> etc. I tried to look at your examples and I could not understand at  
> all how it works. I suspect that there is prior knowledge of other  
> things required to grasp what you are trying to accomplish. And your  
> assumption is that most people already have that knowledge. I don't  
> know about others, but I probably don't have that knowledge,  
> although I understand the http/html very well.

You're right. But to be fair, I just haven't had time to write all the  
documentation and stuff. I don't intend to keep it this way. As the  
README says, this is 100% pre-beta early alpha stuff. However, it does  
work. FWIW I just added a tiny bit more documentation in there. One  
reason to not write too much in the way of a "user manual" yet is that  
this is work in progress. Things might still change.

So definitely at some point I want some diagrams and clear mini  
tutorial and stuff. I don't want to assume everyone knows MVC and my  
thinking! However, if you look at the README and check the examples,  
you might figure it out, as it's a simple but effective model. But  
yeah, prior knowledge of the MVC pattern does help you along at this  
stage — in particular Apple's Cocoa has had some influence.

> My suggestion is that you provide very simple examples that explain  
> what each example does (what/how/why).

Take a look at that and the 'foo' widget. It is linked to the '/foo'  
URL and contains the 'bar' widget (sure the names could be better :-)  
within it, that it uses.

FooController has a method "setName" which is connected to the POST  
with the appropriate submit name ("submit-setName"), which would be  
submitted to '/foo'. The method is called with the form data built  
into a FooNameForm object when the user submits their name into the  
form. FooController also has a method "world", which is connected to  
the URL '/foo/world'. That gets called when that URL is accessed. Here  
both of those methods are dead simple, just setting internal things  
inside the Controller (perfectly fine), but they could do stuff like  
write to database, have checks on the data, decide to switch the sub- 
widget to be shown ('bar' here), or whatever else.

If the user accesses '/foo/world' or submits the form, the related  
methods get called *before* rendering. Their responsibility is thus  
not to render the HTML, but to set stuff within FooController. Then a  
separate View object (basically defined in this case by the template  
foo/view.tml) fetches information from that Controller instance, and  
renders it out.

That template model is very different from the normal way e.g. Django  
does it, where you pass in information to the template and where  
basically control and render are kind of the same thing (annoyingly  
Django uses the 'view' term to cover everything). I've done a fair bit  
of Django coding and this can get incredibly messy. I've grown to  
really dislike it and effectively began to write my own web framework  
on top of Django which we may still use for Scred.com :P

Anyway my solution means that the functionality and control of the  
application and its components are completely separated from the  
rendering. This is a Good Thing and offers great flexibility, code  
reuse and power. Believe me, with large projects this is the way to  
go, but also adds a great model for quick and small apps too. It's  
also great because you can test the "back end" of a website with good  
unit tests, without caring about the rendering at all — and those  
tests are often the most important ones. Additionally you can also  
test the Views separately, by giving them static Controllers with  
exactly the test data you want. They'll just render it out and you can  
have tests to see they're doing it correctly.

Each page can be formed from multiple widgets, and each widget can  
have more widgets within. Each level controls the widget by talking to  
its controller. The rendering is done automatically later by going  
through each widget and telling its View to give out the HTML (takes  
place in the template with the [widget] command).

Sorry for this crummy explanation, but it's been a long day and I'm  
half asleep! As mentioned, I do plan really clear and proper  
documentation. But for now I'll just have to say it's a cool way to do  
things :-)

As for the Ruby / Tcl thingy ... first I've ever heard of it. Got any  
pointers to it?

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/