Re: Added Python, WSGI to XAMPP
On 12/17/2010 02:36 PM, Daniel Fetchinson wrote: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 Maybe, if there's no Zope. Or we'll run away screaming... That is rather pathetically true... Ah well, each to their own... Chris What I really don't like right off is that Pyramid is contorting the MVC model just as Django did with their MTV model. They are both making the controller be the view and this confuses the hell out of people who come from true MVC based projects. The VIEW is the bits that stream out of the webserver back to the users browser. The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. In turbogears that is exactly what happens. Cheers, Daniel How-To: Add VirtualEnv and TurboGears2 (WSGI frmwk) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=43207 -Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 Maybe, if there's no Zope. Or we'll run away screaming... That is rather pathetically true... Ah well, each to their own... Chris What I really don't like right off is that Pyramid is contorting the MVC model just as Django did with their MTV model. They are both making the controller be the view and this confuses the hell out of people who come from true MVC based projects. The VIEW is the bits that stream out of the webserver back to the users browser. The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. In turbogears that is exactly what happens. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
From: Ian Kelly ian.g.ke...@gmail.com On Mon, Dec 13, 2010 at 5:58 PM, Gerry Reno gr...@verizon.net wrote: The VIEW is the bits that stream out of the webserver back to the users browser. Why only to the user's browser? A web app could also offer the results in formats that can be accessed with something else than a browser. The view just offer the results, no matter what way. The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. In traditional MVC, the controller is the part that receives the user input, decides how to react to it, and instructs the model to update itself accordingly. It is not supposed to be some sort of intermediary between the model and the view, as many people seem to make it; the view is supposed to gather the data it needs to render itself directly from the model. How can the view know what data it should render if the controller doesn't inform it about it? It is less important if the view uses a smart templating system that doesn't need to ask the controller for data but can access the model directly, but the view or that templating system need to be informed by the controller what data need to ask from the model, so we can say that the intermediary is still the controller. And accessing the model directly from the view/templating system is not a good idea, because MVC is also prefered because it decouples the programming code and the web design, and in some cases it can be a security issue if the web designer that might not know programming would be able to change by mistake or with intention the code from the view/templating system that access the model. In that light, I think that this quote from the Django FAQ is defensible: In our interpretation of MVC, the “view” describes the data that gets presented to the user. It’s not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It’s a subtle distinction. But if the view doesn't decide how the data looks, who decide it? :-) Traditionally, the view would describe both of these things, but since how you see it is ultimately decided by the user's browser, they are fundamentally separated in the context of the web. The Django template-view split is in recognition of this fact. The same data can have any format that's not decided by the user browser. For example it can be displayed in .csv format, or .xls, or .xlsx, or .pdf, or .html, or it can be submitted by email, or sent to Twitter or another web site... As for where the controller went, there are basically two decisions that need to be made when input is received: how to update the model as a result, and what data should be displayed next. The former decision belongs to the controller, the latter to the view. The update of the model depends on the model and the display of results depends on the view. But the decision is controlled by the... controller. That's why it has that name, because it controls these things. Of course, the frontiers between the M and V and C might be subtle in some cases, but it is a good idea to push as much logic to the base. It is not a good idea to make the controller do the job of the model and imply in the business logic or make the view do the job of the controller and do something else than just present the data it receives. But in a web app, these two things tend to be highly correlated, and there seems to be little reason to separate them out into distinct components. This part then is both controller and view, and which word we use for it is not terribly important. Yes, but in that case such a program wouldn't use the MVC model. And as I exemplified above, there are reasons why the view should only present the data it receives and don't access the model directly. Some web developers aren't even alowed to offer the ORM objects to the templates, although the coding would be much easier that way, but need to generate other objects in the controller that don't allow the web designers to change some things in the templates and access more data from the database than it is needed. For these reasons, I find that in practice traditional MVC does not lend itself well to the HTTP request/response cycle, where the view as you define it has no access to the model and lacks any continuity whatsoever from one request to the next; but the Django MTV approach works just fine once you're willing to accept that it's not the same thing. Cheers, Ian There is no traditional MVC. There is just MVC or not MVC. The view shouldn't have any kind of continuity. The view should just present the data. HTTP is a stateless protocol and the controller that handles the requests,
Re: Added Python, WSGI to XAMPP
On 12/16/2010 04:36 AM, Octavian Rasnita wrote: From: Ian Kelly ian.g.ke...@gmail.com On Mon, Dec 13, 2010 at 5:58 PM, Gerry Reno gr...@verizon.net wrote: The VIEW is the bits that stream out of the webserver back to the users browser. Why only to the user's browser? A web app could also offer the results in formats that can be accessed with something else than a browser. The view just offer the results, no matter what way. The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. In traditional MVC, the controller is the part that receives the user input, decides how to react to it, and instructs the model to update itself accordingly. It is not supposed to be some sort of intermediary between the model and the view, as many people seem to make it; the view is supposed to gather the data it needs to render itself directly from the model. How can the view know what data it should render if the controller doesn't inform it about it? It is less important if the view uses a smart templating system that doesn't need to ask the controller for data but can access the model directly, but the view or that templating system need to be informed by the controller what data need to ask from the model, so we can say that the intermediary is still the controller. And accessing the model directly from the view/templating system is not a good idea, because MVC is also prefered because it decouples the programming code and the web design, and in some cases it can be a security issue if the web designer that might not know programming would be able to change by mistake or with intention the code from the view/templating system that access the model. In that light, I think that this quote from the Django FAQ is defensible: In our interpretation of MVC, the “view” describes the data that gets presented to the user. It’s not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It’s a subtle distinction. But if the view doesn't decide how the data looks, who decide it? :-) Traditionally, the view would describe both of these things, but since how you see it is ultimately decided by the user's browser, they are fundamentally separated in the context of the web. The Django template-view split is in recognition of this fact. The same data can have any format that's not decided by the user browser. For example it can be displayed in .csv format, or .xls, or .xlsx, or .pdf, or .html, or it can be submitted by email, or sent to Twitter or another web site... As for where the controller went, there are basically two decisions that need to be made when input is received: how to update the model as a result, and what data should be displayed next. The former decision belongs to the controller, the latter to the view. The update of the model depends on the model and the display of results depends on the view. But the decision is controlled by the... controller. That's why it has that name, because it controls these things. Of course, the frontiers between the M and V and C might be subtle in some cases, but it is a good idea to push as much logic to the base. It is not a good idea to make the controller do the job of the model and imply in the business logic or make the view do the job of the controller and do something else than just present the data it receives. But in a web app, these two things tend to be highly correlated, and there seems to be little reason to separate them out into distinct components. This part then is both controller and view, and which word we use for it is not terribly important. Yes, but in that case such a program wouldn't use the MVC model. And as I exemplified above, there are reasons why the view should only present the data it receives and don't access the model directly. Some web developers aren't even alowed to offer the ORM objects to the templates, although the coding would be much easier that way, but need to generate other objects in the controller that don't allow the web designers to change some things in the templates and access more data from the database than it is needed. For these reasons, I find that in practice traditional MVC does not lend itself well to the HTTP request/response cycle, where the view as you define it has no access to the model and lacks any continuity whatsoever from one request to the next; but the Django MTV approach works just fine once you're willing to accept that it's not the same thing. Cheers, Ian There is no traditional MVC. There is just MVC or not
Re: Added Python, WSGI to XAMPP
On 14/12/2010 00:58, Gerry Reno wrote: What I really don't like right off is that Pyramid is contorting the MVC model That specific pattern, I'm afraid, is a little antiquated nowadays, particularly when it comes to web apps... The VIEW is the bits that stream out of the webserver back to the users browser. Yep, and in Pyramid I guess this would be the template renderer, which is usually a decorator on the view function or class. The view's job is to process a request and turn it into a response dictionary. That sounds a lot like your controller to me ;-) The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code Slightly scared as to what constructed the python code might mean :-S that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. Well, for me, the MVC isn't really what happens anymore, here's my take: - the model nowadays has all the business logic in it, rather than just the data. The model is now a collection of objects that can be interacted on through many/any UIs needed, some of which may be web apps. - web apps are *always* a collection of request/response transactions. As such, the control layer does just become a view that does that. - singleton objects and other stuff that used to live in a control are now factored out into utilities and services (of which zope.component provides a pretty good abstraction, and doesn't really have anything to do with Zope, other than the fact that Zope makes use of it). Welcome to the 2nd decade in the new millenium ;-) Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Pyramid and MVC (split from: Re: Added Python, WSGI to XAMPP)
On 12/15/2010 05:03 PM, Chris Withers wrote: On 14/12/2010 00:58, Gerry Reno wrote: What I really don't like right off is that Pyramid is contorting the MVC model That specific pattern, I'm afraid, is a little antiquated nowadays, particularly when it comes to web apps... The VIEW is the bits that stream out of the webserver back to the users browser. Yep, and in Pyramid I guess this would be the template renderer, which is usually a decorator on the view function or class. The view's job is to process a request and turn it into a response dictionary. That sounds a lot like your controller to me ;-) The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code Slightly scared as to what constructed the python code might mean :-S that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. Well, for me, the MVC isn't really what happens anymore, here's my take: - the model nowadays has all the business logic in it, rather than just the data. The model is now a collection of objects that can be interacted on through many/any UIs needed, some of which may be web apps. - web apps are *always* a collection of request/response transactions. As such, the control layer does just become a view that does that. - singleton objects and other stuff that used to live in a control are now factored out into utilities and services (of which zope.component provides a pretty good abstraction, and doesn't really have anything to do with Zope, other than the fact that Zope makes use of it). Welcome to the 2nd decade in the new millenium ;-) Chris It doesn't matter whether you are building a desktop app or a webapp. MVC still applies. And that includes when things like Ajax are added to the mix because Ajax just performs a mini-MVC transaction. The problems arise when people start rigidly thinking that M only meant database. M means model, model means any source that emits data. A database, another webapp, whatever, that is M. The view as I said before is just the bits streaming out of the webserver back to the client device. There should be NOTHING on the server call view-anything. The view only exists on the clients. The view is the result of what the controllers(servers) in conjunction with renderers emit as their work product. -Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On Mon, Dec 13, 2010 at 5:58 PM, Gerry Reno gr...@verizon.net wrote: The VIEW is the bits that stream out of the webserver back to the users browser. The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. In traditional MVC, the controller is the part that receives the user input, decides how to react to it, and instructs the model to update itself accordingly. It is not supposed to be some sort of intermediary between the model and the view, as many people seem to make it; the view is supposed to gather the data it needs to render itself directly from the model. In that light, I think that this quote from the Django FAQ is defensible: In our interpretation of MVC, the “view” describes the data that gets presented to the user. It’s not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It’s a subtle distinction. Traditionally, the view would describe both of these things, but since how you see it is ultimately decided by the user's browser, they are fundamentally separated in the context of the web. The Django template-view split is in recognition of this fact. As for where the controller went, there are basically two decisions that need to be made when input is received: how to update the model as a result, and what data should be displayed next. The former decision belongs to the controller, the latter to the view. But in a web app, these two things tend to be highly correlated, and there seems to be little reason to separate them out into distinct components. This part then is both controller and view, and which word we use for it is not terribly important. I suppose that view tends to prevail since there are other components, such as URL dispatch, that are controllerish in nature. For these reasons, I find that in practice traditional MVC does not lend itself well to the HTTP request/response cycle, where the view as you define it has no access to the model and lacks any continuity whatsoever from one request to the next; but the Django MTV approach works just fine once you're willing to accept that it's not the same thing. Cheers, Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On 12/15/2010 07:36 PM, Ian Kelly wrote: On Mon, Dec 13, 2010 at 5:58 PM, Gerry Reno gr...@verizon.net wrote: The VIEW is the bits that stream out of the webserver back to the users browser. The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. In traditional MVC, the controller is the part that receives the user input, decides how to react to it, and instructs the model to update itself accordingly. It is not supposed to be some sort of intermediary between the model and the view, as many people seem to make it; the view is supposed to gather the data it needs to render itself directly from the model. In that light, I think that this quote from the Django FAQ is defensible: In our interpretation of MVC, the “view” describes the data that gets presented to the user. It’s not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It’s a subtle distinction. Traditionally, the view would describe both of these things, but since how you see it is ultimately decided by the user's browser, they are fundamentally separated in the context of the web. The Django template-view split is in recognition of this fact. As for where the controller went, there are basically two decisions that need to be made when input is received: how to update the model as a result, and what data should be displayed next. The former decision belongs to the controller, the latter to the view. But in a web app, these two things tend to be highly correlated, and there seems to be little reason to separate them out into distinct components. This part then is both controller and view, and which word we use for it is not terribly important. I suppose that view tends to prevail since there are other components, such as URL dispatch, that are controllerish in nature. For these reasons, I find that in practice traditional MVC does not lend itself well to the HTTP request/response cycle, where the view as you define it has no access to the model and lacks any continuity whatsoever from one request to the next; but the Django MTV approach works just fine once you're willing to accept that it's not the same thing. Cheers, Ian Django can use whatever approach they like. But don't call it an MVC framework and that is what they did initially at least. MTV is a contorted MVC. And it does not correlate very well with other MVC documentation which is very confusing to people. No doubt, the web is constraining. Request/response makes it difficult to have the Model independently notify the View that it needs to update itself because some state in the model has changed. That is why many of the diagrams about MVC on the web show the Controller interceding between the View and the Model. That doesn't mean MVC does not work on the web. It just means that there is a constraint imposed by the nature of the request/response stateless architecture. Maybe it's splitting hairs, but having things named 'View' on the server implies especially to newbies that the View exists on the server. The View exists on the client. And then later they discover that it's not really View but Controller and that Templates are View. I guess if we were screen-scraping we could actually have a server-side View. But normal MVC has the View on the client, and the Model and Controller in server capacities. And I don't see the value in naming things View on the server when for the most part the View (or view parts in the case of Ajax) are merely the output of render processes. -Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On 09/12/2010 21:29, Gerry Reno wrote: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 You mean Pyramid, right? ;-) Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On 14/12/2010 00:14, Gerry Reno wrote: On 12/13/2010 06:34 PM, Chris Withers wrote: On 09/12/2010 21:29, Gerry Reno wrote: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 Maybe, if there's no Zope. Or we'll run away screaming... That is rather pathetically true... Ah well, each to their own... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On 12/13/2010 06:34 PM, Chris Withers wrote: On 09/12/2010 21:29, Gerry Reno wrote: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 You mean Pyramid, right? ;-) Chris Maybe, if there's no Zope. Or we'll run away screaming... Anyway, Pyramid is still only alpha. But if it is a true WSGI framework then as my technique shows it can certainly be made to work with XAMPP. -Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On 12/13/2010 07:12 PM, Chris Withers wrote: On 14/12/2010 00:14, Gerry Reno wrote: On 12/13/2010 06:34 PM, Chris Withers wrote: On 09/12/2010 21:29, Gerry Reno wrote: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 Maybe, if there's no Zope. Or we'll run away screaming... That is rather pathetically true... Ah well, each to their own... Chris What I really don't like right off is that Pyramid is contorting the MVC model just as Django did with their MTV model. They are both making the controller be the view and this confuses the hell out of people who come from true MVC based projects. The VIEW is the bits that stream out of the webserver back to the users browser. The CONTROLLER is the code that gathers all the pieces from the model and constructs the python code that is then fed to the engine that then creates the view. And just because the controller navigates the logic to dynamically contruct/render a view, that does not make 'it' the view. -Gerry -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On Dec 10, 2:29 am, Gerry Reno gr...@verizon.net wrote: If you have any need of a portable LAMP stack, I just finished writing some How-To's for getting Python, VirtualEnv and WSGI frameworks running with XAMPP: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 How-To: Add VirtualEnv and Django (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42992 How-To: Add Python and mod_wsgi to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42975 -Gerry What does XAMPP give (on linux) that the distro apache,mysql dont? -- http://mail.python.org/mailman/listinfo/python-list
Re: Added Python, WSGI to XAMPP
On 12/13/2010 11:13 PM, rusi wrote: On Dec 10, 2:29 am, Gerry Reno gr...@verizon.net wrote: If you have any need of a portable LAMP stack, I just finished writing some How-To's for getting Python, VirtualEnv and WSGI frameworks running with XAMPP: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 How-To: Add VirtualEnv and Django (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42992 How-To: Add Python and mod_wsgi to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42975 -Gerry What does XAMPP give (on linux) that the distro apache,mysql dont? It is a portable LAMP stack that is basically independent of your distro. If you want to upgrade PHP or Apache or whatever without disturbing your distro PHP or Apache you can do this. If you want to try out cutting edge releases of things you can do this on XAMPP without bothering your distro. It's an environment and what you can do with it is only limited by your imagination. -Gerry -- http://mail.python.org/mailman/listinfo/python-list
Added Python, WSGI to XAMPP
If you have any need of a portable LAMP stack, I just finished writing some How-To's for getting Python, VirtualEnv and WSGI frameworks running with XAMPP: How-To: Add VirtualEnv and Pylons (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42981 How-To: Add VirtualEnv and Django (WSGI framework) to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42992 How-To: Add Python and mod_wsgi to XAMPP http://www.apachefriends.org/f/viewtopic.php?f=17t=42975 -Gerry -- http://mail.python.org/mailman/listinfo/python-list
