View/Controller or should it be Presentation/Logic mix-up

[Speedbird]

First of all, thanks to Massimo and the community for providing an
impressive framework to work with.

Being a Zope developer (and back-end python programmer) for the past
10 years (and soon to web2py convert) , I'd like to share one of the
issues that I have struggled since the early days of DTML.

Please, please do not mix presentation and logic in the controller,
things such a THEAD(TR(TD('<hello>')),_class='myclass',_id=0) from
"controller.py" tends to be very attractive to the novice programmer,
but other than for debugging or testing purposes, IMHO should be
avoided, nailed its practice into an iron coffin and throw it in the
deepest sea.

On the other side of the spectrum, adding python logic into the view
(again IMHO should also be avoided like the plague) Consider the
following:

From myview.html:

{{def foobaz():}}
<h1>This is the baz</h1>
{{return}}

Let me tell you why, at least in the "enterprise" realm this would
become a big problem: You will eventually have to work with a team
(yes, a team of programmers, business analysts, database designers and
user interface monkeys), you want to give the UI guys the "cleanest"
html code for the to play with and mock-up, you know, to keep the
"biz" side happy, etc, what's the point in giving the UI guy (which
may not know python at all) a hello.html with only a {{=respone.glob}}
statement on it?, or on the other hand, you have the purist "python
guy" in the IT dungeon lair and all of the sudden you provide him with
pseudo-html embedded in functions in which he was expecting take care
of logic issues in the code.. see my point?

Please do not get me wrong, I honestly like web2py *a lot*, I just
don't want to see it becoming a nuisance programming-wise instead of a
solid framework tool to introduce in my company. Thanks you all and
keep up the excellent work.

[mdipierro]

Hi Speedbird,

actually I agree with you on almost everything.

But I am sure we can agree there are exceptions. There are times when
you need to generate HTML programmatically. Think of serializing in a
tree recursively. The web2py helper system provides a way to avoid
using raw html.

I also agree about minimizing the use of code in views but your
example may be misleading. The main purpose of {{def ...:}}...
{{return}} in views is not that of defining Python functions (although
you can) but HTML functions (pieces of HTML that you want to reuse).
That is the web2py equivalent of Django blocks. You do exactly for the
purpose of generating html in controllers.

Massimo

[Speedbird]

Fair enough Massimo,

I do agree that setting specific examples sometimes can lead to
misinterpretations (sometimes even being plain wrong), as an example,
I have many process currently written in python, which do not provide
any UI, these processes send many emails to different areas of my
company, I have to create these emails in HTML format and add the
appropriate headers to the email and finally send them, this approach
would be ideal, and as you mentioned, I'd be using this in very
specific circumstances.

As for the code in html, I totally agree that python would be great
for defining blocks, or "macros" how we call it in the zope realm (in
ZPT), in ZPT for example, we do not use python, but rather an XML-ized
METAL command, I am still grasping web2py's way of dealing with macros/
blocks/reusable_html, consider the following in zope:

<div metal:use-macro="here/header/macros/standard_header.html" />
All HTML content goes here
<div metal:use-macro="here/header/macros/standard_footer.html" />

In the very simplistic example above, all of our pages share the same
header and footer, every one of our "views" is a simple template with
the header and footer definitions, in web2py, apparently is the
{{extend 'foo.html'}} and {{include 'bar.html'}} directives, pretty
clever, but I must confess that I still need to get a grasp on its
usage.

In any case, thanks for the quick response, I look forward to
converting my two pet projects (zforum.org) and (ztracker.org) to
web2py (and of course share it with the community) as soon as I can.
Thanks!

-- sb

[Yarko Tymciurak]

First, let me say there are pragmatically pertinent aspects of your arguments (e.g. others "don't know how to use this" - but they are all going to have a heck of a time w/ RIA / Flex interfaces, aren't they?).

Ultimately, any admonition against "code" in some layer is useless (html is, strictly speaking, code; as is xml;  gosh - consider build instructions in Ant!).

The proper focus is this: layers should only interact with adjacent layers, and layers should limit their focus of concern, and any "code" (by whatever descriptor you want to state it) should limit to that concern - that is, be bounded.

For example, to say "view / presentation" should have no code would prevent players (video) in clients, make generation of PDF or even printing  ... well, impossible (and technically speaking, make it impossible to write a browser too).

The important distinction is:

view code should be concerned with view-level details (not business logic; not data model logic);  and so on.

To illustrate, here's a silly example:

code in the model should be concerned (for example) with constraints dealing with data integrity (e.g. date field);

code in the model should be concerned w/ business logic (e.g. yes, that's a date - but it's not a valid one for our application!);

code in the view should be concerned w/ presentation layer decisions (e.g. - here's how we format the date in this region, or ... hmmm, lets display the date on a calendar)

Code everywhere touches the "data" - the important thing is to control what aspect of action is being taken, what concern (perspective) is addressed.

To say "you shouldn't have 'code' here" (at any layer) is clearly silly.

To say "submit saves the data" is (in the scheme of things) just as silly - for it breaks separation of concerns, and disallows layered development (and therefor complicates future modifications).  Except where it is a convenience / utility (but definitely not the only way available - that would be icky).

View <==> Controller <==> Model

Cheers,

Yarko

[Speedbird]

I guess I failed to deliver the hidden irony of my comments, and hope
you don't actually think that I'd *really* throw one of my devs to the
ocean nailed on a coffin. Of course there are exceptions, and I would
be the first to raise my hand if someone asks if anyone had mixed
logic and presentation at one point in their coding.

My point is, (and I am trying to be as sincere as I can be), one
should try to think as if your code will be used and maintained by
others, from different aspects of the web development realm, I
personally work with very talented web developers/designers that I
know they'd appreciate it if I supply them with nice HTML code for
them to add their magic, of course if-statements, for-loops, and other
control structures sometimes *must* appear in your view.

You want to know something I really have a hard time digesting? - the
so-called Helpers in web2py, look at page 50 of the manual (most
likely I cannot copy/paste parts of it here), a form object is
instantiated along with several form elements, as I said before, very
easy for the python coder (that knows html) to include all in the
controller, and in the view, just render the container variable
{{=myform}}, now think about a large application, not a blog, not a
message board, but a large company Intranet containing complex blocks
many of them containing business logic that must be applied in
different sections of the same page, your web designers will really
have a hard time mocking that up don't you think?, even if they mock-
up all forms, etc, they would end up removed from there because we
want to *pythonize* them, in this case, a change in the PRESENTATION
ordered by the business will have to be turned over to the LOGIC
programmers, the UI guy cannot do much there can he?.

Please don't think that I am against it, not at all, in fact for
prototyping I think is incredible helpful, I am just a little
surprised that its use is so frequent in Massimo's book and many of
the "newbies" (in MVC, Web framework, etc) might think of that as a
"best practice" which IMHO it is not..

I am maybe 70% writing one of my former Zope apps in web2py
(incredible fast web framework and loving it), I am avoiding the HTML
and FORM helpers *like the plague*, all my forms are self-submitting
and I don't think I've written much more code than if I had created
the views within the controllers.

What I miss is the equivalent of "has_permission(permission_name,
view_or_controller)" and/or "user.has_role(custom_role)" methods in
Zope, can anyone point me to any examples that deal with
authentication AND permissions or roles (I need to allow users to
create accounts and log in into my blog, but only to respond to
posts), can this be done using CAS??

Take care all

-- speedbird

[mdipierro]

> What I miss is the equivalent of "has_permission(permission_name,
> view_or_controller)" and/or "user.has_role(custom_role)" methods in
> Zope, can anyone point me to any examples that deal with
> authentication AND permissions or roles (I need to allow users to
> create accounts and log in into my blog, but only to respond to
> posts), can this be done using CAS?

The are defined in T2.
http://mdp.cti.depaul.edu/examples/static/t2.pdf
you just need to install the plugin or copy the t2.py in your modules
folder.

Massimo

[Speedbird]

This is awesome Massimo, thank you for pointing this out.

[achipa]

There has been a lot of discussion on HTML helpers. I think their main
shortcoming is actually that for novice web2py users it's hard to find
'the right amount' of them. Some tend to avoid them like yourself and
deprive themselves of some rapid prototyping/design options, while
some people overuse them to the point that it looks more like python
with embedded HTML rather than code. HTML helpers (as I see them, not
sure if that was Massimo's original intent) are basically 'smart
containers'. So, instead of just pushing lists/dicts to the views,
you're pushing an object that can *also* render itself. Note that this
does not prevent the designer from using the *contents* of the helpers
as regular data objects/lists and creating whatever he wants (although
it's still a bit more awkward than I'd like it to be). It just makes
it easier for the coder to make some default output without bothering
the design guy. If a design guy encounters a cryptic {{=bigbundle}} he
can always dump (instead of render) the bigbundle object to see what
goodies he has in there. Note that SOME level of cooperation is of
course needed, the goal is to make things easier, not to make
designers use xslt tables or other complex tech to get to the data in
the format they need it in. You can even have a development view which
you include everywhere which embeds into html the recursive dump of
the response dict so the designer is just a 'view source' away from
seeing how to address the data directly. Also, having the data served
in a prearranged form (think list comprehension) can greatly simplify
the presentation logic that needs to be in the view.