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?

On 22 May 2010, at 02:11, Victor Mayevski wrote:

...

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

http://woof.magicsplat.com/woof_home

Cheers. Yes, I actually had heard of that before, but then couldn't find it at one point and thought I probably mixed with something else. I'll have another look at that.