Re: Difference between controllers and views?
On 12 juin, 04:12, Shannon -jj Behrens [EMAIL PROTECTED] wrote: (snip) I agree with Ben. Having classes with methods has all sorts of OO benefits. Consider, you can implement __getattr__ and do all sorts of cool tricks. It's also nice to share a bunch of code and data via self. If you don't use classes, you're forced to do everything with function decorators. Nothing prevents you from using any callable object as a Django view. And I don't get your point wrt/ decorators. Not to say that I prefer the Django's way here... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Difference between controllers and views?
On Fri, Jun 13, 2008 at 6:53 AM, askel [EMAIL PROTECTED] wrote:
-jj,
Isn't that enforced by Routes that controllers must be classes? I
remember some discussion about possibility of using any other
dispatching library/method in Pylons. It was something about new WSGI
environment key wsgiorg.routing_args. I might be completely wrong on
that though.
Cheers
Alexander
Pylons requires controllers to live in a certain directory and have a
certain name. But the controller class can be a WSGI function.
routing.py tells Routes to allow only controllers that exist in a
certain directory:
map = Mapper(directory=config['pylons.paths']['controllers'],
always_scan=config['debug'])
wsgiorg.routing_args contains the routing variables. The wsgiorg spec
(http://www.wsgi.org/wsgi/Specifications/routing_args) mentions only
named routing args, but not any particular names like controller.
You can override pylons.wsgiapp.PylonsApp.find_controller() to look
for controllers elsewhere.
Routes 2 will eliminate the controller constraint because that's not
really Routes' job. There will likely be an option to specify that
certain routing vars must be present and true ('controller' and
'action' for Pylons, 'controller' for TG 2 or generic WSGI
controllers). We're also considering a connect option to dispatch
directly to a WSGI app without a controller.
--
Mike Orr [EMAIL PROTECTED]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---
Re: Difference between controllers and views?
On Thu, Jun 12, 2008 at 8:44 AM, Alberto Valverde [EMAIL PROTECTED] wrote: What's the practical difference between controller based approach and views based one? Eg. Django views, and controllers in Pylons? It doesn't seem that much different, so why not make all controller actions regular functions, instead of class methods? What's the gain in this controller approach, if any? :) You can take a look at a real app's Pylons REST controller that powers beta.toscawidgets.org here [1]. (Not that other apps are unreal.. I mean that it's not a MyFirstBlog tutorial ;) * The __before__ method (which is executed before any method) performs basic authorization and binds the object being exposed, if any, at an attribute in self. This avoids repeating this code in every controller action and is much simpler to implement properly than decorators. What object being exposed do you mean? (The links on the site are giving a Bad Gateway error, so I can't check this myself.) You mean something that's nominally being protected by the authorization? I use a ._process_id(id) method to validate the ID and attach it and the ORM object to self, and a separate ._REQUIRE_PERM(permname) method for authorization. Also, because some actions have an id and others don't, or because you need a parent's ID to create a child object or index of children, sometimes I'm calling ._process_id_for_parent() and sometimes ._process_id_for_child() in the same controller, which is too fine-grained for .__before__. -- Mike Orr [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Difference between controllers and views?
I saw a Java MVC that's totally different. The view knows about the model and actively puts things into it and takes things out of it. The controller does not know much about the model (if I remember right). The database is also distinct from the model; the view talks to the database (!). Then there's a separate scratchpad (akin to session variables or 'c' variables). To me this is totally wrong. But then I saw a wxPython application that also has the view using the model, and the speaker recommended this pattern, so it seems to be widespread. FWIW in Robin's book he recommends an abstract model with a registry of listener functions that callback on data updates to update the views. AFAIK this makes it more MVC as we know it ( and I believe even more like the original smalltalk mvc as it was explained to me for audio coding ). So the above sounds fishy to me from my wxPython experience, but that is rather limited! ;-) Iain --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Difference between controllers and views?
For me, there are not much differences between view based approach and the controller based approach. Of course, functions are first class objects in Python. MVC is an abstract concept, a pattern for classifying the data, actions and presentation/view. Languages and frameworks(framework developer) gives different shape for implementation of MVC concept. Your question seems like comparison between Object Oriented vs Functional approach. We have to see, how best we can add hacks/hooks into the framework to solve our own problem (not the framework's problems :-) ) We tried both Django and Struts, none of them solved my problems on my own way. With pylons, I have solved my own problem with my own way. This is what I need from a framework. (We have developed internal portal for test case management for HART protocol. First we tried with Struts 2 and later moved to Django then finally we implemented in Pylons). On Jun 14, 1:17 am, Shannon -jj Behrens [EMAIL PROTECTED] wrote: Yes. You could hack around that, but it'd probably be painful. What I'm saying is that: a) Using classes is a good idea. b) Pylons doesn't force you to code a certain way within those classes. You can move as much or as little as you want into the models or other libraries. Best Regards, -jj On Fri, Jun 13, 2008 at 6:53 AM, askel [EMAIL PROTECTED] wrote: -jj, Isn't that enforced by Routes that controllers must be classes? I remember some discussion about possibility of using any other dispatching library/method in Pylons. It was something about new WSGI environment key wsgiorg.routing_args. I might be completely wrong on that though. Cheers Alexander On Jun 12, 9:59 pm, Shannon -jj Behrens [EMAIL PROTECTED] wrote: On Thu, Jun 12, 2008 at 10:05 AM, rcs_comp [EMAIL PROTECTED] wrote: On Jun 11, 4:10 pm, Karlo Lozovina [EMAIL PROTECTED] wrote: What's the practical difference between controller based approach and views based one? Eg. Django views, and controllers in Pylons? It doesn't seem that much different, so why not make all controller actions regular functions, instead of class methods? What's the gain in this controller approach, if any? :) Thanks... I differ a bit from the opinions above. I like to think of a web request as asking show me something. Therefore, IMO, it makes sense to map a web request to a view. The view (a Python class) then knows how to use actions (a Python class) to do something, the actions know how to use the model to get work done. The view then renders a response in an appropriate format (HTML, JSON, etc.) using any helpers necessary (i.e. templates). The view does not have to render using a template though. I had a diagram of this at one point, but can't get the darn thing to open right now. If anyone is interested in seeing a diagram let me know and I will try to get it working and post one. What you are describing is closer to the Rails philosophy. They're big on pushing stuff into models, even validation. I've done it that way, and that works too. I think of it like a pie. You can slice the pie in many ways. Slice it however you like. That's one thing I like about Pylons. It does make you use a class with methods, but it doesn't force you too much beyond that. If you want to do something strange like put all your logic in models and then use string interpolation within your controllers you can. Whatever floats your boat ;) Happy Hacking! -jj -- I, for one, welcome our new Facebook overlords!http://jjinux.blogspot.com/- -- I, for one, welcome our new Facebook overlords!http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Difference between controllers and views?
Yes. You could hack around that, but it'd probably be painful. What I'm saying is that: a) Using classes is a good idea. b) Pylons doesn't force you to code a certain way within those classes. You can move as much or as little as you want into the models or other libraries. Best Regards, -jj On Fri, Jun 13, 2008 at 6:53 AM, askel [EMAIL PROTECTED] wrote: -jj, Isn't that enforced by Routes that controllers must be classes? I remember some discussion about possibility of using any other dispatching library/method in Pylons. It was something about new WSGI environment key wsgiorg.routing_args. I might be completely wrong on that though. Cheers Alexander On Jun 12, 9:59 pm, Shannon -jj Behrens [EMAIL PROTECTED] wrote: On Thu, Jun 12, 2008 at 10:05 AM, rcs_comp [EMAIL PROTECTED] wrote: On Jun 11, 4:10 pm, Karlo Lozovina [EMAIL PROTECTED] wrote: What's the practical difference between controller based approach and views based one? Eg. Django views, and controllers in Pylons? It doesn't seem that much different, so why not make all controller actions regular functions, instead of class methods? What's the gain in this controller approach, if any? :) Thanks... I differ a bit from the opinions above. I like to think of a web request as asking show me something. Therefore, IMO, it makes sense to map a web request to a view. The view (a Python class) then knows how to use actions (a Python class) to do something, the actions know how to use the model to get work done. The view then renders a response in an appropriate format (HTML, JSON, etc.) using any helpers necessary (i.e. templates). The view does not have to render using a template though. I had a diagram of this at one point, but can't get the darn thing to open right now. If anyone is interested in seeing a diagram let me know and I will try to get it working and post one. What you are describing is closer to the Rails philosophy. They're big on pushing stuff into models, even validation. I've done it that way, and that works too. I think of it like a pie. You can slice the pie in many ways. Slice it however you like. That's one thing I like about Pylons. It does make you use a class with methods, but it doesn't force you too much beyond that. If you want to do something strange like put all your logic in models and then use string interpolation within your controllers you can. Whatever floats your boat ;) Happy Hacking! -jj -- I, for one, welcome our new Facebook overlords!http://jjinux.blogspot.com/- -- I, for one, welcome our new Facebook overlords! http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Difference between controllers and views?
On Wed, Jun 11, 2008 at 3:14 PM, Ben Bangert [EMAIL PROTECTED] wrote: On Jun 11, 2008, at 1:10 PM, Karlo Lozovina wrote: What's the practical difference between controller based approach and views based one? Eg. Django views, and controllers in Pylons? It doesn't seem that much different, so why not make all controller actions regular functions, instead of class methods? What's the gain in this controller approach, if any? :) Terminology really. Note that webapps in general are only vaguely mapped to the entire MVC concept in that you have a model representing domain logic (generally with a database), a controller that gets the request and decides how to respond, and a view (template) which the controller uses to create the response with the data (Model). So Django is more-or-less MVC, they just call it MTV (Model-Template-View), and their 'View' is doing the logic with the request, fetching data from the Model, and using a template (aka, view), to return a response. By any definition of MVC I've seen, Django is without a doubt MVC as well: http://en.wikipedia.org/wiki/Model-view-controller They've provided a reason for why they choose to call it MTV on their FAQ page, which differs from every other web frameworks rather unanimous interpretation of it, and so far has led to more than a little confusion when I've seen Django users using other MVC frameworks and frequently asking about 'views' when people understand that to be 'controllers'. Regarding the use of a class vs a function for the controller, there are some advantages with the class. You can easily have stuff done before any of the methods are called for example, and you can set things on the class object and have helper function utilized that have access to them on 'self' as well. Also, you can develop mix-in style classes, to easily add generic methods to various controllers merely by changing the inheritance. MVC is a cargo cult ;) http://jjinux.blogspot.com/2005/04/mvc-cargo-cult.html I agree with Ben. Having classes with methods has all sorts of OO benefits. Consider, you can implement __getattr__ and do all sorts of cool tricks. It's also nice to share a bunch of code and data via self. If you don't use classes, you're forced to do everything with function decorators. -jj -- I, for one, welcome our new Facebook overlords! http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Difference between controllers and views?
On Jun 11, 2008, at 7:12 PM, Shannon -jj Behrens wrote: MVC is a cargo cult ;) http://jjinux.blogspot.com/2005/04/mvc-cargo-cult.html Regardless of the original meaning in the context of Smalltalk, the terminology does have a fairly easy to understand and very common interpretation (most everyone I've met who describes MVC is describing the concept as the wikipedia article does). I wouldn't consider it a cargo cult, as it doesn't seem much like a movement, as finding a description that seems to fit what everyone is doing. Of course, it can get a little religious as soon as you start arguing with a MVC purist about whether its ok to occasionally put some logic in a template. Cheers, Ben smime.p7s Description: S/MIME cryptographic signature
