Thank you Paul.
That sorts it out for me.
I am actually going to write a RESTful service using perhaps cornice
with Pyramid.
You are right in saying that CRUD kind of system fits in nicely with
this approach.
I will try some code and see how it feels.
Thanks a million.
Happy hacking.
Krishnakant.
Ps:
I did a top posting a couple of times and I am sorry for that.
Basically I am totally blind and some times my screen reader reads out
things in an odd way after a few mails are written in-line as replies to
replies.
On Thursday 12 November 2015 01:06 AM, Paul Everitt wrote:
On Nov 11, 2015, at 2:20 PM, kk <[email protected]
<mailto:[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
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]
<mailto:[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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[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 a topic in the
Google Groups "pylons-discuss" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/pylons-discuss/wL2P3BBdI6Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
[email protected]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[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.
