April Meeting Topic Feedback

[mattjmorrison]

There are a few of us who have been talking about doing a talk at Pyowa about building modern web applications in Python. This is a very broad topic so I would like to hear some feedback to know if there are areas that people would prefer to see more about than others. 

Here are some topics, please chime in with the things that you would like to hear about:

• Django
• RESTful web services with Django
• Client Side MVC
• CoffeeScript / Less 
• Pre-Compiling CoffeeScript / Less in Django
• Client Side Testing
• Full Stack Testing

Also, if there is something that I haven't listed here please feel free to add anything that you'd like to hear about.

Hope to hear from you soon!

- Matt

[Jim Popken]

Matt,

They all sound good. My preferences (in order high to low) would be CoffeeScript, RESTfull web services and Django.

Thnaks for asking.

Jim

--
You received this message because you are subscribed to the Google Groups "Pyowa" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyowa+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
920 Clark Avenue
Ames, Iowa 50010
515 233-0855 (work)

[Spencer Herzberg]

I would love to see all of these things. I assume with the Django topic, you would talk about South migrations, but if not, maybe there should be a topic about this, because I think that is something that would really get buy in from companies/people on the fence about what framework/language they should choose.

Deployments might be outside the scope of what you are looking for but I went to the "Solid Python Application Deployments For Everybody" (http://pyvideo.org/video/1727/solid-python-application-deployments-for-everybod) at PyCon this year and think it was a fantastic talk about deploying with native packages. I have started to use this a little and would love to learn more about how other people in the area are deploying and would even be willing to talk about the high-level points about doing native package deployments.

-Spencer

[Toran Billups]

Spencer 

I think Matt talked about migrations a bit last year @ 2 different meetings

The October meeting still shows up on pyowa and has a youtube video

http://www.pyowa.org/

The other video was part of the django intro -can't seem to find the link to this one

Matt -did you talk about South at the meeting on django last year? if so what is the perma link to that post on pyowa?

Toran

[Matthew J. Morrison]

I don't think we will talk much about south for this meeting. We will probably want to stay more focused on web technologies. Our October Meeting featured Django... There was some talk about the database and migrations (around minute 18 if you're interested). In January's Meeting we talked about Django's ORM, I don't think migrations were mentioned there.

I do really like the idea of having a meeting totally dedicated to deployment. Spencer, would you like to volunteer to talk about how you handle deployments? We could also do more of a round-table discussion about deployment, that may be a more appropriate format.

--
Matthew J. Morrison

@mattjmorrison

mattjmorrison.com

[matt...@gmail.com]

I've been tutoring Django development and can suggest a topic that seems to be useful to many different skill levels. Sadly, I do not have the time right now to teach it, nor can I likely attend the meeting, so take it with a grain of salt. :-)

The topic suggestion is templating with Django. I don't think many people have problems with the basic concepts of using templates, but there are a lot of interesting related topics that trip people up. For example, where to put them, effectively using inheritance and how to organize static assets such as images and css.

Another topic might be a run-down of add-on modules that can help you not to repeat yourself. For example, just about every app I've made has a login form, which is simple, but then every login form has a "forgot password" link, which is not simple. Other examples are South and maybe a RESTful framework. So maybe the topic would be a list of modules that the Django team should have included.

A topic I've been wrestling with is deciding when or if I should use generic class-based views. A year ago I was very excited about them and used them a lot, but I realized my total LOC went up once I started needing stuff that didn't come in the box, which was true for all but the most trivial situations. This year my thinking is to avoid them, unless 1.5 introduced something that makes this much easier. (the exception being static pages which is about the most trivial situation anyway)

/me goes back to lurking again

On Wed, Mar 27, 2013 at 6:22 PM, Toran Billups <tor...@gmail.com> wrote:

--
Matthew Nuzum
newz2000 on freenode, skype, linkedin and twitter

♫ You're never fully dressed without a smile! ♫

[Matthew J. Morrison]

Django templating is another topic that would be a good main subject for an upcoming meeting. I think Django add-ons would be another good topic. 

Based on my experience in the past few years, I personally use class-based views exclusively. This could, by itself, be yet another meeting topic. Maybe it would be fun to have a function vs. class-based views meeting where we could have some people present their cases in a debate style discussion. 

For me, the reason that I use class-based views exclusively is really due to extensibility. In my older code I have over and over again the same function-based view that looks like this:

# this is all from memory, so don't judge my errors

def myview(request):

  if request.method == 'POST':

    form = MyForm(request.POST)

    if form.is_valid():

        form.save()

        return http.HttpRedirect("/somewhere")

    else:

        return http.HttpResponse("some template", context=RequestContext({'errors': form.errors, 'form': form}))

  else:

    return http.HttpResponse("some template", context=RequestContext({'form': form}))

I see a huge problem with this. It is not extensible at all. I cannot write another view identical to this one in every way except that it uses a different form class, or that passes one additional piece of data to the request context, or that does something special when the form is saved, or redirect to a different url or does something special for an HTTP PUT, PATCH, DELETE etc. A class based view breaks all of this up so you would have something like:

class MyView:

  template_name = "some template"

  form_class = MyForm

  redirect_url = "/somewhere"

  

  def form_valid(self, form):

    "special hook to save the form the way you want"

  def form_invalid(self, form):

    "special hook to do something when the form is not valid"

  def get_context_data(self):

    "special hook to add what you want to the template's context"

  def get(self):

    "this happens for an HTTP GET request"

  def put(self):

    "this happens for an HTTP PUT request"

  def patch(self):

    "this happens for an HTTP PATCH request"

The class based view approach is completely extensible. You can easily re-use views from 3rd party libraries without having to copy and paste a giant nightmarish function-based view's code and tweaking the one line that you want to behave differently.  

Here is a real example from real world code. In the Django admin's login view there is a check in there that calls is_safe_url. Our Django applications use single sign-on, which means that you don't necessarily authenticate on the same domain as the application (we verify everything behind the scenes). That means that this one small line of code makes it impossible to use the Django provided login view at all. If there would have been a way for us to override a method in a subclass to change the behavior of that one line of code, or even some subset of that function we wouldn't have had to re-roll that exact view for our applications. 

While I do agree that class-based views seem to introduce more LOC in examples like this, I found that a majority of our class based views are really no code, just configuration for example:

class MyView:

   template_name = "x"

   form_class = "x"

   model_class = "x"

This really just isn't possible using function based views. Views should be logic-less  right? They should just wire things together and delegate to the appropriate objects that do all of the real work. Class-based views seem like the right tool for the job, to me. 

I would like to have a meeting about Django views and Django templates and Django add-ons, so if you're still reading this massive post, please chime in and let me know if you would be interested in speaking about one (or more) of these topics.

-Matt

Matthew J. Morrison

@mattjmorrison

mattjmorrison.com