On 9/2/13 1:12 AM, Roberto Guerra wrote:
Thank you, that explains it. Will give it a try. The Class Views section in
the Quick Tour could probably mention that the methods can take the same
view_config options as the 'function views'. It was a little unclear from
looking at the example what told pyramid to render the edit form or the
delete form. I literally just learned about request_param. So maybe we can
say in that section that pyramid knows to display either the 'Edit' or
'Delete' view because of request_param. And then have a link to the
request_param documentation.

You're right, when I was writing that view class example, I wanted to emphasize the convenience of @view_defaults allowing one route to lead to multiple views. I will look to make the following changes:

- Add a second route, going to a second method on the view class

- Explain that a method can have everything that a view function can have

- Emphasize the use of request.param (really, it's embarrassing that I didn't feature this more, my apologies)

- Provide the links as you describe

--Paul



On Sunday, September 1, 2013 10:58:15 PM UTC-6, Chris McDonough wrote:

On 09/02/2013 12:40 AM, Roberto Guerra wrote:
Sorry, but I don't think any server-side web framework is MVC. People
that ask about are generally just using buzz terms like SOA, Web
Services, MVC, etc without understanding the concepts. The javascript
front-end frameworks are more MVC than the server-side frameworks.

100% agreed (I put "MVC" in quotes because I agree).

As for the Quick Tour, I'm still a newbie, and found myself overwhelmed
with the documentation when I started a year ago. It is still very
difficult to digest and the only way I've figured things out is by
diving into it head first. For example, class-based views, I still don't
grok it. If you are coming from Rails, for example, you can have
multiple routes inside a 'class view', but in Pyramid it appears that
you can only have one route per class view. At least that is what I've
understood just recently, but it is still unclear from the docs. The
Quick Tour doesn't help in clearing this up. Would be useful if it were
a little more explicit about this.

I wish we could be clearer about it, but I'm not sure how.

Views don't "have" routes, for better or worse.  A route points to one
or more views (usually just one).  View classes are just a convenient
way of grouping view functions together really.  The only difference is
really the way you access the request.  You can use two functions:

@view_config(route_name='route1')
def myview(request):
      ... access to request via request parameter ...

@view_config(route_name='route2')
def myview(request):
      ... access to request via request parameter ...

Or you can use two methods of the same class:

class MyViews(object):
      def __init__(self, request):
          self.request = request

      @view_config(route_name='route1')
      def myview(self):
          ... access to request via self.request ...

      @view_config(route_name='route2')
      def myview(self):
          ... access to request via self.request ...

Or you can use two methods of the same class:

class MyViews(object):
      def __init__(self, request):
          self.request = request

      @view_config(route_name='route1')
      def myview(self):
          ... access to request via self.request ...

Or you can use two different classes:

class MyViews2(object):

      def __init__(self, request):
          self.request = request

      @view_config(route_name='route2')
      def myview(self):
          ... access to request via self.request ...

Suggestions to help make

http://docs.pylonsproject.org/projects/pyramid/en/1.5-branch/narr/viewconfig.html#view-config-placement
clearer would be useful.

- C




On Sunday, September 1, 2013 12:31:24 PM UTC-6, Chris McDonough wrote:

     On 09/01/2013 02:24 PM, Mike Orr wrote:

      > Especially since, doesn't Rails have MVC frameworks now? I know
      > they've been backporting some things from the Python frameworks.
      >

     AFAIK, Rails always "had MVC" and was the tip of the "MVC" spear.
  It
     made the term "MVC" popular in relation to web frameworks (as wrong
as
     the term was).

     - C

--
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] <javascript:>.
To post to this group, send email to [email protected]<javascript:>.

Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/groups/opt_out.




--
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/groups/opt_out.

Reply via email to