> On Nov 11, 2015, at 2:20 PM, kk <[email protected]> wrote: > > > Thanks Paul and jon. > Now I understand the beauty of it. > In an oop terminology, this approach means that the root name can become > polimorfic. > So that same name can be registed with various view functions and and the > right one will be called depending on the request type or difference in > parameters. > Is that correct?
Well said! And yes, that’s correct. The framework chooses the matching route definition, then chooses the best-match view. I little like CSS rules. > If so then my question is how will the same root name help in making code > simple, except readability? Look at the view class in bullet point 3 at: http://docs.pylonsproject.org/projects/pyramid/en/latest/quick_tutorial/more_view_classes.html <http://docs.pylonsproject.org/projects/pyramid/en/latest/quick_tutorial/more_view_classes.html> It uses one route_name (applied on the entire view class) with all the views related to it: - def hello is used on GET - def edit is used on POST - def delete is used when POST was done with a certain button - def home is the special case on the view, uses a different route name In a REST-style ToDo application, you could have one route: /todo/{id} …that handled views for: - View the todo (GET) - Edit the todo (PUT) - Delete the todo (DELETE) Or in a non-REST, you could use (like the URL above) presence of which button was clicked. > I mean, I may as well have different root names with different patterns to > make things more explicit. If you never have any variations, meaning a very simple application, than that is indeed simple. What happens, though, is people wind up with branches in their views to try and decide which subview they are in: if request.method == ‘GET’: # return a form elif request.method == ‘POST’ and request.params.get(‘button.submit’): # process the submit elif request.method == ‘POST’ and requet.params.get(‘button.cancel’: # clear the session and go to another URL elif request.xhr: # Oh, we’re a REST request, we should do JSON Not only is that ugly on the face of it, test writing becomes a fiasco. Whenever you see something in Pyramid that looks like extra work, many times it is to make test writing easier. :) > As it is some difference is going to be there in the url pattern when a > request reaches some view function, then how will the same name help? > Happy hacking. It isn’t only in the URL pattern. It’s in the HTTP method (GET, POST, PUT, DELETE, and nowadays PATCH). It’s in the form data that was submitted, to see which button was clicked. It’s in forms vs. Ajax/REST (thus an HTTP header.) I believe you badly want to believe one URL == one route == one view. I suggest you go that direction, as it makes the most sense. Later, when you start to feel like your views have grown 9 arms, step back and think: should I have different views for different flavors of request? —Paul > Krishnakant. > > > On Thursday 12 November 2015 12:39 AM, Paul Everitt wrote: >>> On Nov 11, 2015, at 2:01 PM, kk <[email protected]> wrote: >>> >>> >>> Thanks, >>> >>> >>> On Thursday 12 November 2015 12:28 AM, Jonathan Vanasco wrote: >>>> @view_config is a decorator that registers the view callable function ( >>>> http://docs.pylonsproject.org/projects/pyramid/en/latest/narr/viewconfig.html#adding-view-configuration-using-the-view-config-decorator >>>> ) >>>> >>>> The various arguments trigger the view. >>> But I read that this is a slow way specially during the startup of the web >>> app? Is that correct? >> The speed hit on startup comes from the other side, the part doing the >> config.scan(). It’s a very small hit only when you have a huge code base >> (lots of files to scan). Easily fixed as well. So don’t be afraid of >> @view_config. :) >> >>>> There are other ways to register a view (such as `config.add_view`), but >>>> `@view_config` is very popular. >>>> -- >>> So when using add_view, the rooting happens in the same line of code or is >>> it still done at a different place? >> There are two parts to the dance: >> >> - Routing looks at the URL and selects a route name based on the URL pattern >> and the order the routes were registered. Your config.add_route statements >> register those route names. >> >> - Once you have a route name, you then need a view from the list of views >> registered for that route name. Your config.add_view (or @view_config) >> statements register views for a route name. >> >> Jonathan, I liked your explanation of “a route is a way to make an >> identifier on a URL pattern”. >> >> —Paul >> > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/pylons-discuss. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
