You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by "David N. Welton" <da...@dedasys.com> on 2002/12/06 00:50:11 UTC
web app commands
I'm looking at implementing something for Rivet that might end up
looking like what Websh has, for more "web application" style
programming. I'm curious if you guys have any thoughts, after having
used it for a while, on how you might do the 'dispatch' part of your
code better? Anything you're not happy with?
I would really like to seperate out the M, V, and C components
completely, though, something that, at least in the Websh examples
I've seen isn't really prevalent.
I think I may have something interesting - I rewrote my TclChat app in
such a way as to completely seperate the display, control and data
model. More later...
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: web app commands
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> Usage right now is ok I think.
Ok.
> Regarding the MVC pattern, it certainly has nothing todo with the V,
> but it does not cleary distinguish between its M anc C components:
> On the one hand it's clearly the M: it controlles the model of what
> commands we have and it reacts to C (the user input). But it's also
> part of the C, because the query parameter and form vars are only
> set up from within web::dispatch. (I.e. now you can only read query
> string params using [web::param] after [web::dispatch] is called,
> because by how you (the developer) call web::dispatch you decide
> what data to use as source for the params and form vars.) Maybe
> these two parts should be separated somehow. From what I know of
> Rivet, you have the input (C) processed separately anyway, so the
> question would just be how to add the dispatch. But the dispatching
> alone is pretty simple: basically its just a switch that evals a
> command specified by a parameter.
> > I would really like to seperate out the M, V, and C components
> > completely, though, something that, at least in the Websh examples
> > I've seen isn't really prevalent.
> See above and: the examples are certainly not great in that
> area. Much of it has not really to do with Websh itself but more
> with how it is used. (Specifically separating the V from the rest.)
The system I threw together differs slightly from websh, but only
superficially.
I think that either one can do MVC without problems - the way I did
things was like so:
web dispatcher - this file receives the dispatches for different V
states.
gui - a file that loads the specific gui requested:
webgui - web display code, which consists mostly of calling different
template files.
tkgui - this one holds the equivalent tk commands to get a similar
looking front end.
controlling logic - a seperate file with logic that is independant of
V and M. These are called from the dispatcher.
model - in this case, a direct link to the backend, although it
wouldn't be hard to abstract it out for different backends as I did
with the web and tk interfaces.
The only thing that doesn't quite match the MVC described in my design
patterns book is the fact that the model doesn't have a good way of
pushing changes out to the V layer, because of the way web the web
works. You only get to act when the user asks for it.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web app commands
Posted by "David N. Welton" <da...@dedasys.com>.
Ronnie Brunner <ro...@netcetera.ch> writes:
> Usage right now is ok I think.
Ok.
> Regarding the MVC pattern, it certainly has nothing todo with the V,
> but it does not cleary distinguish between its M anc C components:
> On the one hand it's clearly the M: it controlles the model of what
> commands we have and it reacts to C (the user input). But it's also
> part of the C, because the query parameter and form vars are only
> set up from within web::dispatch. (I.e. now you can only read query
> string params using [web::param] after [web::dispatch] is called,
> because by how you (the developer) call web::dispatch you decide
> what data to use as source for the params and form vars.) Maybe
> these two parts should be separated somehow. From what I know of
> Rivet, you have the input (C) processed separately anyway, so the
> question would just be how to add the dispatch. But the dispatching
> alone is pretty simple: basically its just a switch that evals a
> command specified by a parameter.
> > I would really like to seperate out the M, V, and C components
> > completely, though, something that, at least in the Websh examples
> > I've seen isn't really prevalent.
> See above and: the examples are certainly not great in that
> area. Much of it has not really to do with Websh itself but more
> with how it is used. (Specifically separating the V from the rest.)
The system I threw together differs slightly from websh, but only
superficially.
I think that either one can do MVC without problems - the way I did
things was like so:
web dispatcher - this file receives the dispatches for different V
states.
gui - a file that loads the specific gui requested:
webgui - web display code, which consists mostly of calling different
template files.
tkgui - this one holds the equivalent tk commands to get a similar
looking front end.
controlling logic - a seperate file with logic that is independant of
V and M. These are called from the dispatcher.
model - in this case, a direct link to the backend, although it
wouldn't be hard to abstract it out for different backends as I did
with the web and tk interfaces.
The only thing that doesn't quite match the MVC described in my design
patterns book is the fact that the model doesn't have a good way of
pushing changes out to the V layer, because of the way web the web
works. You only get to act when the user asks for it.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: web app commands
Posted by Ronnie Brunner <ro...@netcetera.ch>.
> I'm looking at implementing something for Rivet that might end up
> looking like what Websh has, for more "web application" style
> programming. I'm curious if you guys have any thoughts, after having
> used it for a while, on how you might do the 'dispatch' part of your
> code better? Anything you're not happy with?
A brief history: in Websh1 and Websh2, the dispatching was
automatic. The script was sourced and after that, an internal command
was called that did the dispatching. The user (developer) had no
control over how a command was dispatched. (The only thing he could do
was to [exit] in the script, so there would not be any dispatching at
all.
In Websh3 we ask the developer to explicitly use that mechanism. This
has the advantage that the design is much celarer and there is no need
for Websh to use any "magic" to do things after a script has been
eval'd. (Before that, we couldn't make it a proper TEA extension
anyway.)
Usage right now is ok I think.
Regarding the MVC pattern, it certainly has nothing todo with the V,
but it does not cleary distinguish between its M anc C components:
On the one hand it's clearly the M: it controlles the model of what
commands we have and it reacts to C (the user input). But it's also
part of the C, because the query parameter and form vars are only set
up from within web::dispatch. (I.e. now you can only read query string
params using [web::param] after [web::dispatch] is called, because by
how you (the developer) call web::dispatch you decide what data to use
as source for the params and form vars.)
Maybe these two parts should be separated somehow. From what I know of
Rivet, you have the input (C) processed separately anyway, so the
question would just be how to add the dispatch. But the dispatching
alone is pretty simple: basically its just a switch that evals a
command specified by a parameter.
> I would really like to seperate out the M, V, and C components
> completely, though, something that, at least in the Websh examples
> I've seen isn't really prevalent.
See above and: the examples are certainly not great in that area. Much
of it has not really to do with Websh itself but more with how it is
used. (Specifically separating the V from the rest.)
> I think I may have something interesting - I rewrote my TclChat app in
> such a way as to completely seperate the display, control and data
> model. More later...
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 fax +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: websh-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: websh-dev-help@tcl.apache.org
Re: web app commands
Posted by Ronnie Brunner <ro...@netcetera.ch>.
> I'm looking at implementing something for Rivet that might end up
> looking like what Websh has, for more "web application" style
> programming. I'm curious if you guys have any thoughts, after having
> used it for a while, on how you might do the 'dispatch' part of your
> code better? Anything you're not happy with?
A brief history: in Websh1 and Websh2, the dispatching was
automatic. The script was sourced and after that, an internal command
was called that did the dispatching. The user (developer) had no
control over how a command was dispatched. (The only thing he could do
was to [exit] in the script, so there would not be any dispatching at
all.
In Websh3 we ask the developer to explicitly use that mechanism. This
has the advantage that the design is much celarer and there is no need
for Websh to use any "magic" to do things after a script has been
eval'd. (Before that, we couldn't make it a proper TEA extension
anyway.)
Usage right now is ok I think.
Regarding the MVC pattern, it certainly has nothing todo with the V,
but it does not cleary distinguish between its M anc C components:
On the one hand it's clearly the M: it controlles the model of what
commands we have and it reacts to C (the user input). But it's also
part of the C, because the query parameter and form vars are only set
up from within web::dispatch. (I.e. now you can only read query string
params using [web::param] after [web::dispatch] is called, because by
how you (the developer) call web::dispatch you decide what data to use
as source for the params and form vars.)
Maybe these two parts should be separated somehow. From what I know of
Rivet, you have the input (C) processed separately anyway, so the
question would just be how to add the dispatch. But the dispatching
alone is pretty simple: basically its just a switch that evals a
command specified by a parameter.
> I would really like to seperate out the M, V, and C components
> completely, though, something that, at least in the Websh examples
> I've seen isn't really prevalent.
See above and: the examples are certainly not great in that area. Much
of it has not really to do with Websh itself but more with how it is
used. (Specifically separating the V from the rest.)
> I think I may have something interesting - I rewrote my TclChat app in
> such a way as to completely seperate the display, control and data
> model. More later...
------------------------------------------------------------------------
Ronnie Brunner ronnie.brunner@netcetera.ch
Netcetera AG, 8040 Zuerich phone +41 1 247 79 79 fax +41 1 247 70 75
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org