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 On Sun, Jan 4, 2009 at 5:31 PM, Speedbird <[email protected]> wrote: > > 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 > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
