No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] Announcing: Spindle v0.1 An MVC web framework for Tcl/XOTcl
From: Kristoffer Lawson <setok_at_scred.com>
Date: Sat, 22 May 2010 01:12:43 +0300
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?
Date: Sat, 22 May 2010 01:12:43 +0300
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/