librelist archives

« back to archive

Flask-Classy 0.5

Flask-Classy 0.5

From:
Freedom Dumlao
Date:
2012-11-19 @ 14:03
After receiving tons of feedback on the initial API and functionality, and
implementing almost all of it, I've finally released version 0.5. I feel
the API is really starting to mature and would love any of you didn't think
it was quite right before to give it another look and tell me what you
think now.

0.5 introduced some breaking changes, for anyone who has been using it so
far but they are fairly simple and honestly I think they make a lot of
sense. Take a look at the changelog for more information or feel free to
ask me directly.

Also in there since the initial release is a new feature to wrap views with
custom before and after methods. That was the first step before providing a
central context for view specific template management, but it's also
extremely useful for all the other things response-wrapping is good for.

Thanks Flaskers for all the feedback so far. You've made working on this
project more rewarding than it would have been going it alone.

Check it out here: http://packages.python.org/Flask-Classy/
And the github repo: https://github.com/apiguy/flask-classy

- Freedom

Re: [flask] Flask-Classy 0.5

From:
Imran Khawaja
Date:
2012-11-19 @ 14:47
This is awesome. I'm just getting started with Flask coming from a Java
world and was wondering how I can organize things better. This gets me
started in the right direction.


On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> After receiving tons of feedback on the initial API and functionality, and
> implementing almost all of it, I've finally released version 0.5. I feel
> the API is really starting to mature and would love any of you didn't think
> it was quite right before to give it another look and tell me what you
> think now.
>
> 0.5 introduced some breaking changes, for anyone who has been using it so
> far but they are fairly simple and honestly I think they make a lot of
> sense. Take a look at the changelog for more information or feel free to
> ask me directly.
>
> Also in there since the initial release is a new feature to wrap views
> with custom before and after methods. That was the first step before
> providing a central context for view specific template management, but it's
> also extremely useful for all the other things response-wrapping is good
> for.
>
> Thanks Flaskers for all the feedback so far. You've made working on this
> project more rewarding than it would have been going it alone.
>
> Check it out here: http://packages.python.org/Flask-Classy/
> And the github repo: https://github.com/apiguy/flask-classy
>
> - Freedom
>



-- 
Imran

Re: [flask] Flask-Classy 0.5

From:
Mark Grey
Date:
2012-11-19 @ 17:00
Hey Freedom,

Wanted to run this by you before I filed a github issue.

I have some FlaskViews that get registered at two different subdomains.
 Both views use the @route decorator to add some extra custom methods.

I appears that method routes declared with the decorator dont honor the
subdomain passed to the register function.  I can provide a test case if
needed.

~Mark

On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com> wrote:

> This is awesome. I'm just getting started with Flask coming from a Java
> world and was wondering how I can organize things better. This gets me
> started in the right direction.
>
>
> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>
>> After receiving tons of feedback on the initial API and functionality,
>> and implementing almost all of it, I've finally released version 0.5. I
>> feel the API is really starting to mature and would love any of you didn't
>> think it was quite right before to give it another look and tell me what
>> you think now.
>>
>> 0.5 introduced some breaking changes, for anyone who has been using it so
>> far but they are fairly simple and honestly I think they make a lot of
>> sense. Take a look at the changelog for more information or feel free to
>> ask me directly.
>>
>> Also in there since the initial release is a new feature to wrap views
>> with custom before and after methods. That was the first step before
>> providing a central context for view specific template management, but it's
>> also extremely useful for all the other things response-wrapping is good
>> for.
>>
>> Thanks Flaskers for all the feedback so far. You've made working on this
>> project more rewarding than it would have been going it alone.
>>
>> Check it out here: http://packages.python.org/Flask-Classy/
>> And the github repo: https://github.com/apiguy/flask-classy
>>
>> - Freedom
>>
>
>
>
> --
> Imran
>

Re: [flask] Flask-Classy 0.5

From:
Mark Grey
Date:
2012-11-19 @ 17:01
Updated to 0.5 for that issue as well btw.


On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com> wrote:

> Hey Freedom,
>
> Wanted to run this by you before I filed a github issue.
>
> I have some FlaskViews that get registered at two different subdomains.
>  Both views use the @route decorator to add some extra custom methods.
>
> I appears that method routes declared with the decorator dont honor the
> subdomain passed to the register function.  I can provide a test case if
> needed.
>
> ~Mark
>
>
> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com> wrote:
>
>> This is awesome. I'm just getting started with Flask coming from a Java
>> world and was wondering how I can organize things better. This gets me
>> started in the right direction.
>>
>>
>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>>
>>> After receiving tons of feedback on the initial API and functionality,
>>> and implementing almost all of it, I've finally released version 0.5. I
>>> feel the API is really starting to mature and would love any of you didn't
>>> think it was quite right before to give it another look and tell me what
>>> you think now.
>>>
>>> 0.5 introduced some breaking changes, for anyone who has been using it
>>> so far but they are fairly simple and honestly I think they make a lot of
>>> sense. Take a look at the changelog for more information or feel free to
>>> ask me directly.
>>>
>>> Also in there since the initial release is a new feature to wrap views
>>> with custom before and after methods. That was the first step before
>>> providing a central context for view specific template management, but it's
>>> also extremely useful for all the other things response-wrapping is good
>>> for.
>>>
>>> Thanks Flaskers for all the feedback so far. You've made working on this
>>> project more rewarding than it would have been going it alone.
>>>
>>> Check it out here: http://packages.python.org/Flask-Classy/
>>> And the github repo: https://github.com/apiguy/flask-classy
>>>
>>> - Freedom
>>>
>>
>>
>>
>> --
>> Imran
>>
>
>

Re: [flask] Flask-Classy 0.5

From:
Freedom Dumlao
Date:
2012-11-19 @ 17:13
Thanks Mark.

Please go ahead and file an issue on github, and if you've got a test case
I'll gladly accept it. Was this working before 0.5 release?

- Freedom


On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com> wrote:

> Hey Freedom,
>
> Wanted to run this by you before I filed a github issue.
>
> I have some FlaskViews that get registered at two different subdomains.
>  Both views use the @route decorator to add some extra custom methods.
>
> I appears that method routes declared with the decorator dont honor the
> subdomain passed to the register function.  I can provide a test case if
> needed.
>
> ~Mark
>
>
> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com> wrote:
>
>> This is awesome. I'm just getting started with Flask coming from a Java
>> world and was wondering how I can organize things better. This gets me
>> started in the right direction.
>>
>>
>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>>
>>> After receiving tons of feedback on the initial API and functionality,
>>> and implementing almost all of it, I've finally released version 0.5. I
>>> feel the API is really starting to mature and would love any of you didn't
>>> think it was quite right before to give it another look and tell me what
>>> you think now.
>>>
>>> 0.5 introduced some breaking changes, for anyone who has been using it
>>> so far but they are fairly simple and honestly I think they make a lot of
>>> sense. Take a look at the changelog for more information or feel free to
>>> ask me directly.
>>>
>>> Also in there since the initial release is a new feature to wrap views
>>> with custom before and after methods. That was the first step before
>>> providing a central context for view specific template management, but it's
>>> also extremely useful for all the other things response-wrapping is good
>>> for.
>>>
>>> Thanks Flaskers for all the feedback so far. You've made working on this
>>> project more rewarding than it would have been going it alone.
>>>
>>> Check it out here: http://packages.python.org/Flask-Classy/
>>> And the github repo: https://github.com/apiguy/flask-classy
>>>
>>> - Freedom
>>>
>>
>>
>>
>> --
>> Imran
>>
>
>

Re: [flask] Flask-Classy 0.5

From:
Mark Grey
Date:
2012-11-19 @ 17:19
Didn't have the chance to test it prior, though I suppose I could spin up a
virtualenv with an older version to see.

On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> Thanks Mark.
>
> Please go ahead and file an issue on github, and if you've got a test case
> I'll gladly accept it. Was this working before 0.5 release?
>
> - Freedom
>
>
> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>
>> Hey Freedom,
>>
>> Wanted to run this by you before I filed a github issue.
>>
>> I have some FlaskViews that get registered at two different subdomains.
>>  Both views use the @route decorator to add some extra custom methods.
>>
>> I appears that method routes declared with the decorator dont honor the
>> subdomain passed to the register function.  I can provide a test case if
>> needed.
>>
>> ~Mark
>>
>>
>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com> wrote:
>>
>>> This is awesome. I'm just getting started with Flask coming from a Java
>>> world and was wondering how I can organize things better. This gets me
>>> started in the right direction.
>>>
>>>
>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <freedomdumlao@gmail.com
>>> > wrote:
>>>
>>>> After receiving tons of feedback on the initial API and functionality,
>>>> and implementing almost all of it, I've finally released version 0.5. I
>>>> feel the API is really starting to mature and would love any of you didn't
>>>> think it was quite right before to give it another look and tell me what
>>>> you think now.
>>>>
>>>> 0.5 introduced some breaking changes, for anyone who has been using it
>>>> so far but they are fairly simple and honestly I think they make a lot of
>>>> sense. Take a look at the changelog for more information or feel free to
>>>> ask me directly.
>>>>
>>>> Also in there since the initial release is a new feature to wrap views
>>>> with custom before and after methods. That was the first step before
>>>> providing a central context for view specific template management, but it's
>>>> also extremely useful for all the other things response-wrapping is good
>>>> for.
>>>>
>>>> Thanks Flaskers for all the feedback so far. You've made working on
>>>> this project more rewarding than it would have been going it alone.
>>>>
>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>
>>>> - Freedom
>>>>
>>>
>>>
>>>
>>> --
>>> Imran
>>>
>>
>>
>

Re: [flask] Flask-Classy 0.5

From:
Freedom Dumlao
Date:
2012-11-20 @ 06:31
Mark,

I've got a fix for that issue as well as extending the tests to cover that
case. It's in version 0.5.1.

Thanks for the excellent write upon the issue, it made it much easier to
track down than it would have been otherwise.

- Freedom


On Mon, Nov 19, 2012 at 12:19 PM, Mark Grey <mark.asperia@gmail.com> wrote:

> Didn't have the chance to test it prior, though I suppose I could spin up
> a virtualenv with an older version to see.
>
>
> On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>
>> Thanks Mark.
>>
>> Please go ahead and file an issue on github, and if you've got a test
>> case I'll gladly accept it. Was this working before 0.5 release?
>>
>> - Freedom
>>
>>
>> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>
>>> Hey Freedom,
>>>
>>> Wanted to run this by you before I filed a github issue.
>>>
>>> I have some FlaskViews that get registered at two different subdomains.
>>>  Both views use the @route decorator to add some extra custom methods.
>>>
>>> I appears that method routes declared with the decorator dont honor the
>>> subdomain passed to the register function.  I can provide a test case if
>>> needed.
>>>
>>> ~Mark
>>>
>>>
>>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com>wrote:
>>>
>>>> This is awesome. I'm just getting started with Flask coming from a Java
>>>> world and was wondering how I can organize things better. This gets me
>>>> started in the right direction.
>>>>
>>>>
>>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <
>>>> freedomdumlao@gmail.com> wrote:
>>>>
>>>>> After receiving tons of feedback on the initial API and functionality,
>>>>> and implementing almost all of it, I've finally released version 0.5. I
>>>>> feel the API is really starting to mature and would love any of you didn't
>>>>> think it was quite right before to give it another look and tell me what
>>>>> you think now.
>>>>>
>>>>> 0.5 introduced some breaking changes, for anyone who has been using it
>>>>> so far but they are fairly simple and honestly I think they make a lot of
>>>>> sense. Take a look at the changelog for more information or feel free to
>>>>> ask me directly.
>>>>>
>>>>> Also in there since the initial release is a new feature to wrap views
>>>>> with custom before and after methods. That was the first step before
>>>>> providing a central context for view specific template management, but it's
>>>>> also extremely useful for all the other things response-wrapping is good
>>>>> for.
>>>>>
>>>>> Thanks Flaskers for all the feedback so far. You've made working on
>>>>> this project more rewarding than it would have been going it alone.
>>>>>
>>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>>
>>>>> - Freedom
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Imran
>>>>
>>>
>>>
>>
>

Re: [flask] Flask-Classy 0.5

From:
Mark Grey
Date:
2012-11-20 @ 15:52
No problem man.  I'm really liking this approach moreso than what I had
before with methodviews (esp since the register methodology for the
methodviews is about 5 lines in a dedicated function at the official docs,
a bit less sexy than a one line decorator)

That was the last issue I could find refactoring our url structure to use
classy, so I feel more or less comfortable adopting this inside our app.
 It feel so much more elegant to have the views defined via their
corresponding program models (REST ftw) rather than wording them more
centered around the structure or confines of the HTTP protocol itself.
 After, HTTP is but one interface we may be exposing our services over.

Pending approval from the bosses we'll actually be rolling this out as-is
in deployment.

On Tue, Nov 20, 2012 at 1:31 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> Mark,
>
> I've got a fix for that issue as well as extending the tests to cover that
> case. It's in version 0.5.1.
>
> Thanks for the excellent write upon the issue, it made it much easier to
> track down than it would have been otherwise.
>
> - Freedom
>
>
> On Mon, Nov 19, 2012 at 12:19 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>
>> Didn't have the chance to test it prior, though I suppose I could spin up
>> a virtualenv with an older version to see.
>>
>>
>> On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <freedomdumlao@gmail.com
>> > wrote:
>>
>>> Thanks Mark.
>>>
>>> Please go ahead and file an issue on github, and if you've got a test
>>> case I'll gladly accept it. Was this working before 0.5 release?
>>>
>>> - Freedom
>>>
>>>
>>> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>
>>>> Hey Freedom,
>>>>
>>>> Wanted to run this by you before I filed a github issue.
>>>>
>>>> I have some FlaskViews that get registered at two different subdomains.
>>>>  Both views use the @route decorator to add some extra custom methods.
>>>>
>>>> I appears that method routes declared with the decorator dont honor the
>>>> subdomain passed to the register function.  I can provide a test case if
>>>> needed.
>>>>
>>>> ~Mark
>>>>
>>>>
>>>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com>wrote:
>>>>
>>>>> This is awesome. I'm just getting started with Flask coming from a
>>>>> Java world and was wondering how I can organize things better. This gets me
>>>>> started in the right direction.
>>>>>
>>>>>
>>>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <
>>>>> freedomdumlao@gmail.com> wrote:
>>>>>
>>>>>> After receiving tons of feedback on the initial API and
>>>>>> functionality, and implementing almost all of it, I've finally released
>>>>>> version 0.5. I feel the API is really starting to mature and would love any
>>>>>> of you didn't think it was quite right before to give it another look and
>>>>>> tell me what you think now.
>>>>>>
>>>>>> 0.5 introduced some breaking changes, for anyone who has been using
>>>>>> it so far but they are fairly simple and honestly I think they make a lot
>>>>>> of sense. Take a look at the changelog for more information or feel free to
>>>>>> ask me directly.
>>>>>>
>>>>>> Also in there since the initial release is a new feature to wrap
>>>>>> views with custom before and after methods. That was the first step before
>>>>>> providing a central context for view specific template management, but it's
>>>>>> also extremely useful for all the other things response-wrapping is good
>>>>>> for.
>>>>>>
>>>>>> Thanks Flaskers for all the feedback so far. You've made working on
>>>>>> this project more rewarding than it would have been going it alone.
>>>>>>
>>>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>>>
>>>>>> - Freedom
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Imran
>>>>>
>>>>
>>>>
>>>
>>
>

Re: [flask] Flask-Classy 0.5

From:
Freedom Dumlao
Date:
2012-11-20 @ 16:23
Awesome Mark. I'd love to hear about your experiences. We're working on
backporting it into the codebase it was inspired from at work now as well.
I'm almost done with the template related features, hopefully I'll get
those out this weekend.


On Tue, Nov 20, 2012 at 10:52 AM, Mark Grey <mark.asperia@gmail.com> wrote:

> No problem man.  I'm really liking this approach moreso than what I had
> before with methodviews (esp since the register methodology for the
> methodviews is about 5 lines in a dedicated function at the official docs,
> a bit less sexy than a one line decorator)
>
> That was the last issue I could find refactoring our url structure to use
> classy, so I feel more or less comfortable adopting this inside our app.
>  It feel so much more elegant to have the views defined via their
> corresponding program models (REST ftw) rather than wording them more
> centered around the structure or confines of the HTTP protocol itself.
>  After, HTTP is but one interface we may be exposing our services over.
>
> Pending approval from the bosses we'll actually be rolling this out as-is
> in deployment.
>
>
> On Tue, Nov 20, 2012 at 1:31 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>
>> Mark,
>>
>> I've got a fix for that issue as well as extending the tests to cover
>> that case. It's in version 0.5.1.
>>
>> Thanks for the excellent write upon the issue, it made it much easier to
>> track down than it would have been otherwise.
>>
>> - Freedom
>>
>>
>> On Mon, Nov 19, 2012 at 12:19 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>
>>> Didn't have the chance to test it prior, though I suppose I could spin
>>> up a virtualenv with an older version to see.
>>>
>>>
>>> On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <
>>> freedomdumlao@gmail.com> wrote:
>>>
>>>> Thanks Mark.
>>>>
>>>> Please go ahead and file an issue on github, and if you've got a test
>>>> case I'll gladly accept it. Was this working before 0.5 release?
>>>>
>>>> - Freedom
>>>>
>>>>
>>>> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>
>>>>> Hey Freedom,
>>>>>
>>>>> Wanted to run this by you before I filed a github issue.
>>>>>
>>>>> I have some FlaskViews that get registered at two different
>>>>> subdomains.  Both views use the @route decorator to add some extra custom
>>>>> methods.
>>>>>
>>>>> I appears that method routes declared with the decorator dont honor
>>>>> the subdomain passed to the register function.  I can provide a test case
>>>>> if needed.
>>>>>
>>>>> ~Mark
>>>>>
>>>>>
>>>>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com>wrote:
>>>>>
>>>>>> This is awesome. I'm just getting started with Flask coming from a
>>>>>> Java world and was wondering how I can organize things better. This gets me
>>>>>> started in the right direction.
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <
>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>
>>>>>>> After receiving tons of feedback on the initial API and
>>>>>>> functionality, and implementing almost all of it, I've finally released
>>>>>>> version 0.5. I feel the API is really starting to mature and would
love any
>>>>>>> of you didn't think it was quite right before to give it another look and
>>>>>>> tell me what you think now.
>>>>>>>
>>>>>>> 0.5 introduced some breaking changes, for anyone who has been using
>>>>>>> it so far but they are fairly simple and honestly I think they make a lot
>>>>>>> of sense. Take a look at the changelog for more information or 
feel free to
>>>>>>> ask me directly.
>>>>>>>
>>>>>>> Also in there since the initial release is a new feature to wrap
>>>>>>> views with custom before and after methods. That was the first step before
>>>>>>> providing a central context for view specific template management,
but it's
>>>>>>> also extremely useful for all the other things response-wrapping is good
>>>>>>> for.
>>>>>>>
>>>>>>> Thanks Flaskers for all the feedback so far. You've made working on
>>>>>>> this project more rewarding than it would have been going it alone.
>>>>>>>
>>>>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>>>>
>>>>>>> - Freedom
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Imran
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] Flask-Classy 0.5

From:
Sina K
Date:
2012-11-20 @ 17:54
minor typo in docs in Wrapping Views
  @app.before_reqeust <-- request is misspelled
> Freedom Dumlao <mailto:freedomdumlao@gmail.com>
> November 20, 2012 5:23 PM
> Awesome Mark. I'd love to hear about your experiences. We're working 
> on backporting it into the codebase it was inspired from at work now 
> as well. I'm almost done with the template related features, hopefully 
> I'll get those out this weekend.
>
>
>
> Mark Grey <mailto:mark.asperia@gmail.com>
> November 20, 2012 4:52 PM
> No problem man.  I'm really liking this approach moreso than what I 
> had before with methodviews (esp since the register methodology for 
> the methodviews is about 5 lines in a dedicated function at the 
> official docs, a bit less sexy than a one line decorator)
>
> That was the last issue I could find refactoring our url structure to 
> use classy, so I feel more or less comfortable adopting this inside 
> our app.  It feel so much more elegant to have the views defined via 
> their corresponding program models (REST ftw) rather than wording them 
> more centered around the structure or confines of the HTTP protocol 
> itself.  After, HTTP is but one interface we may be exposing our 
> services over.
>
> Pending approval from the bosses we'll actually be rolling this out 
> as-is in deployment.
>
>
> Freedom Dumlao <mailto:freedomdumlao@gmail.com>
> November 20, 2012 7:31 AM
> Mark,
>
> I've got a fix for that issue as well as extending the tests to cover 
> that case. It's in version 0.5.1.
>
> Thanks for the excellent write upon the issue, it made it much easier 
> to track down than it would have been otherwise.
>
> - Freedom
>
>
>
> Mark Grey <mailto:mark.asperia@gmail.com>
> November 19, 2012 6:19 PM
> Didn't have the chance to test it prior, though I suppose I could spin 
> up a virtualenv with an older version to see.
>
>
> Freedom Dumlao <mailto:freedomdumlao@gmail.com>
> November 19, 2012 6:13 PM
> Thanks Mark.
>
> Please go ahead and file an issue on github, and if you've got a test 
> case I'll gladly accept it. Was this working before 0.5 release?
>
> - Freedom
>
>
>

Re: [flask] Flask-Classy 0.5

From:
Joe Esposito
Date:
2012-11-20 @ 17:30
Finally had a chance to take a closer look. This looks great!
Most of the initial negative reactions when I introduce Flask are the lack
of class-based views. I'll now include this extension to ease the doubts =)

Some thoughts, if it's not too late:

   - The Github repo should have a link at the top to
   http://packages.python.org/Flask-Classy/
   - Consider using a Fork me on Github
ribbon<https://github.com/blog/273-github-ribbons>on that site. Should
be as easy as possible to find the source code from
   the docs, and vice versa.
   - Speaking of the docs, I really enjoyed reading them!
   - Being an advocate of minimalism, is there a reason you didn't name the
   view class "View" instead of "FlaskView"?
   Is it that too many people would have name collisions? I think "View" is
   a less verbose default, and doing from flask.ext.classy import View as
   FlaskView as needed

I also wonder if this will help with composability. I'd love to see a large
example site using class-based views with diverging functionality.
I'll try this out with my next Flask project and write about it if there's
anything worth adding.

Good work!

On Tue, Nov 20, 2012 at 11:23 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> Awesome Mark. I'd love to hear about your experiences. We're working on
> backporting it into the codebase it was inspired from at work now as well.
> I'm almost done with the template related features, hopefully I'll get
> those out this weekend.
>
>
> On Tue, Nov 20, 2012 at 10:52 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>
>> No problem man.  I'm really liking this approach moreso than what I had
>> before with methodviews (esp since the register methodology for the
>> methodviews is about 5 lines in a dedicated function at the official docs,
>> a bit less sexy than a one line decorator)
>>
>> That was the last issue I could find refactoring our url structure to use
>> classy, so I feel more or less comfortable adopting this inside our app.
>>  It feel so much more elegant to have the views defined via their
>> corresponding program models (REST ftw) rather than wording them more
>> centered around the structure or confines of the HTTP protocol itself.
>>  After, HTTP is but one interface we may be exposing our services over.
>>
>> Pending approval from the bosses we'll actually be rolling this out as-is
>> in deployment.
>>
>>
>> On Tue, Nov 20, 2012 at 1:31 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>>
>>> Mark,
>>>
>>> I've got a fix for that issue as well as extending the tests to cover
>>> that case. It's in version 0.5.1.
>>>
>>> Thanks for the excellent write upon the issue, it made it much easier to
>>> track down than it would have been otherwise.
>>>
>>> - Freedom
>>>
>>>
>>> On Mon, Nov 19, 2012 at 12:19 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>
>>>> Didn't have the chance to test it prior, though I suppose I could spin
>>>> up a virtualenv with an older version to see.
>>>>
>>>>
>>>> On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <
>>>> freedomdumlao@gmail.com> wrote:
>>>>
>>>>> Thanks Mark.
>>>>>
>>>>> Please go ahead and file an issue on github, and if you've got a test
>>>>> case I'll gladly accept it. Was this working before 0.5 release?
>>>>>
>>>>> - Freedom
>>>>>
>>>>>
>>>>> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>
>>>>>> Hey Freedom,
>>>>>>
>>>>>> Wanted to run this by you before I filed a github issue.
>>>>>>
>>>>>> I have some FlaskViews that get registered at two different
>>>>>> subdomains.  Both views use the @route decorator to add some extra custom
>>>>>> methods.
>>>>>>
>>>>>> I appears that method routes declared with the decorator dont honor
>>>>>> the subdomain passed to the register function.  I can provide a test case
>>>>>> if needed.
>>>>>>
>>>>>> ~Mark
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com>wrote:
>>>>>>
>>>>>>> This is awesome. I'm just getting started with Flask coming from a
>>>>>>> Java world and was wondering how I can organize things better. 
This gets me
>>>>>>> started in the right direction.
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <
>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>
>>>>>>>> After receiving tons of feedback on the initial API and
>>>>>>>> functionality, and implementing almost all of it, I've finally released
>>>>>>>> version 0.5. I feel the API is really starting to mature and 
would love any
>>>>>>>> of you didn't think it was quite right before to give it another look and
>>>>>>>> tell me what you think now.
>>>>>>>>
>>>>>>>> 0.5 introduced some breaking changes, for anyone who has been using
>>>>>>>> it so far but they are fairly simple and honestly I think they make a lot
>>>>>>>> of sense. Take a look at the changelog for more information or 
feel free to
>>>>>>>> ask me directly.
>>>>>>>>
>>>>>>>> Also in there since the initial release is a new feature to wrap
>>>>>>>> views with custom before and after methods. That was the first 
step before
>>>>>>>> providing a central context for view specific template 
management, but it's
>>>>>>>> also extremely useful for all the other things response-wrapping is good
>>>>>>>> for.
>>>>>>>>
>>>>>>>> Thanks Flaskers for all the feedback so far. You've made working on
>>>>>>>> this project more rewarding than it would have been going it alone.
>>>>>>>>
>>>>>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>>>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>>>>>
>>>>>>>> - Freedom
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Imran
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] Flask-Classy 0.5

From:
Freedom Dumlao
Date:
2012-11-20 @ 18:29
Thanks Joe,

I added the link to the github repo, should have done that a while ago! I
used to have the 'fork me' banner but I must have left it out when I
updated to using the table of contents, I'll be sure and get that fixed
asap.

I'm glad you liked the docs my writing style isn't for everyone, but
honestly I hate writing documentation, so I figured I'd do it in a way that
I could entertain myself a bit as I wrote and that got the job done :)

I selected 'FlaskView' over just 'View' because in the application that
inspired the Flask-Classy extension the concept of a 'View' is quite
ambiguous. The Flask front end is only one part of a large application and
it helped to distinguish that this was a 'View Class for Flask' as opposed
to View classes that represent pre-computed database datasets or View
classes that exist for supporting legacy integrations. I did consider other
names for it, but I hate naming things and if I had kept it up we very well
might have had it be called BaseFlaskClassyViewClassClass or something much
worse. Luckily I stopped before things got out of hand.

All that being said, if there were strong community support for a specific
name, I certainly wouldn't be opposed.

After I get the Template features in this weekend (I hope), I plan on
trying to get a sample application written and documented, and then let the
dust settle on the API for a bit to see how it feels for everyone
(including those of us using it where I work.) Hopefully that will help to
inspire those users that require some "see it in action" type of
inspiration.

I really appreciate your feedback and I'm looking forward to hearing about
your experiences when you start trying it out on your next project.

- Freedom


On Tue, Nov 20, 2012 at 12:30 PM, Joe Esposito <espo58@gmail.com> wrote:

> Finally had a chance to take a closer look. This looks great!
> Most of the initial negative reactions when I introduce Flask are the lack
> of class-based views. I'll now include this extension to ease the doubts =)
>
> Some thoughts, if it's not too late:
>
>    - The Github repo should have a link at the top to
>    http://packages.python.org/Flask-Classy/
>    - Consider using a Fork me on Github 
ribbon<https://github.com/blog/273-github-ribbons>on that site. Should be 
as easy as possible to find the source code from
>    the docs, and vice versa.
>    - Speaking of the docs, I really enjoyed reading them!
>    - Being an advocate of minimalism, is there a reason you didn't name
>    the view class "View" instead of "FlaskView"?
>    Is it that too many people would have name collisions? I think "View"
>    is a less verbose default, and doing from flask.ext.classy import View
>    as FlaskView as needed
>
> I also wonder if this will help with composability. I'd love to see a
> large example site using class-based views with diverging functionality.
> I'll try this out with my next Flask project and write about it if there's
> anything worth adding.
>
> Good work!
>
> On Tue, Nov 20, 2012 at 11:23 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>
>> Awesome Mark. I'd love to hear about your experiences. We're working on
>> backporting it into the codebase it was inspired from at work now as well.
>> I'm almost done with the template related features, hopefully I'll get
>> those out this weekend.
>>
>>
>> On Tue, Nov 20, 2012 at 10:52 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>
>>> No problem man.  I'm really liking this approach moreso than what I had
>>> before with methodviews (esp since the register methodology for the
>>> methodviews is about 5 lines in a dedicated function at the official docs,
>>> a bit less sexy than a one line decorator)
>>>
>>> That was the last issue I could find refactoring our url structure to
>>> use classy, so I feel more or less comfortable adopting this inside our
>>> app.  It feel so much more elegant to have the views defined via their
>>> corresponding program models (REST ftw) rather than wording them more
>>> centered around the structure or confines of the HTTP protocol itself.
>>>  After, HTTP is but one interface we may be exposing our services over.
>>>
>>> Pending approval from the bosses we'll actually be rolling this out
>>> as-is in deployment.
>>>
>>>
>>> On Tue, Nov 20, 2012 at 1:31 AM, Freedom Dumlao <freedomdumlao@gmail.com
>>> > wrote:
>>>
>>>> Mark,
>>>>
>>>> I've got a fix for that issue as well as extending the tests to cover
>>>> that case. It's in version 0.5.1.
>>>>
>>>> Thanks for the excellent write upon the issue, it made it much easier
>>>> to track down than it would have been otherwise.
>>>>
>>>> - Freedom
>>>>
>>>>
>>>> On Mon, Nov 19, 2012 at 12:19 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>
>>>>> Didn't have the chance to test it prior, though I suppose I could spin
>>>>> up a virtualenv with an older version to see.
>>>>>
>>>>>
>>>>> On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <
>>>>> freedomdumlao@gmail.com> wrote:
>>>>>
>>>>>> Thanks Mark.
>>>>>>
>>>>>> Please go ahead and file an issue on github, and if you've got a test
>>>>>> case I'll gladly accept it. Was this working before 0.5 release?
>>>>>>
>>>>>> - Freedom
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>>
>>>>>>> Hey Freedom,
>>>>>>>
>>>>>>> Wanted to run this by you before I filed a github issue.
>>>>>>>
>>>>>>> I have some FlaskViews that get registered at two different
>>>>>>> subdomains.  Both views use the @route decorator to add some extra custom
>>>>>>> methods.
>>>>>>>
>>>>>>> I appears that method routes declared with the decorator dont honor
>>>>>>> the subdomain passed to the register function.  I can provide a test case
>>>>>>> if needed.
>>>>>>>
>>>>>>> ~Mark
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com>wrote:
>>>>>>>
>>>>>>>> This is awesome. I'm just getting started with Flask coming from a
>>>>>>>> Java world and was wondering how I can organize things better. 
This gets me
>>>>>>>> started in the right direction.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <
>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> After receiving tons of feedback on the initial API and
>>>>>>>>> functionality, and implementing almost all of it, I've finally released
>>>>>>>>> version 0.5. I feel the API is really starting to mature and 
would love any
>>>>>>>>> of you didn't think it was quite right before to give it another
look and
>>>>>>>>> tell me what you think now.
>>>>>>>>>
>>>>>>>>> 0.5 introduced some breaking changes, for anyone who has been
>>>>>>>>> using it so far but they are fairly simple and honestly I think 
they make a
>>>>>>>>> lot of sense. Take a look at the changelog for more information or feel
>>>>>>>>> free to ask me directly.
>>>>>>>>>
>>>>>>>>> Also in there since the initial release is a new feature to wrap
>>>>>>>>> views with custom before and after methods. That was the first 
step before
>>>>>>>>> providing a central context for view specific template 
management, but it's
>>>>>>>>> also extremely useful for all the other things response-wrapping is good
>>>>>>>>> for.
>>>>>>>>>
>>>>>>>>> Thanks Flaskers for all the feedback so far. You've made working
>>>>>>>>> on this project more rewarding than it would have been going it alone.
>>>>>>>>>
>>>>>>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>>>>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>>>>>>
>>>>>>>>> - Freedom
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Imran
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] Flask-Classy 0.5

From:
Owein Reese
Date:
2012-11-20 @ 19:19
Freedom,

I like FlaskView. For all the points that you mentioned, it's succinct,
descriptive, and to the point. I hope you can get Flask-Classy in the
approved list as fast as possible. Id like to point some people to it at
work but being in the financial industry it'll have to "approved."

Great library and thanks for your hard work.
On Nov 20, 2012 1:42 PM, "Freedom Dumlao" <freedomdumlao@gmail.com> wrote:

> Thanks Joe,
>
> I added the link to the github repo, should have done that a while ago! I
> used to have the 'fork me' banner but I must have left it out when I
> updated to using the table of contents, I'll be sure and get that fixed
> asap.
>
> I'm glad you liked the docs my writing style isn't for everyone, but
> honestly I hate writing documentation, so I figured I'd do it in a way that
> I could entertain myself a bit as I wrote and that got the job done :)
>
> I selected 'FlaskView' over just 'View' because in the application that
> inspired the Flask-Classy extension the concept of a 'View' is quite
> ambiguous. The Flask front end is only one part of a large application and
> it helped to distinguish that this was a 'View Class for Flask' as opposed
> to View classes that represent pre-computed database datasets or View
> classes that exist for supporting legacy integrations. I did consider other
> names for it, but I hate naming things and if I had kept it up we very well
> might have had it be called BaseFlaskClassyViewClassClass or something much
> worse. Luckily I stopped before things got out of hand.
>
> All that being said, if there were strong community support for a specific
> name, I certainly wouldn't be opposed.
>
> After I get the Template features in this weekend (I hope), I plan on
> trying to get a sample application written and documented, and then let the
> dust settle on the API for a bit to see how it feels for everyone
> (including those of us using it where I work.) Hopefully that will help to
> inspire those users that require some "see it in action" type of
> inspiration.
>
> I really appreciate your feedback and I'm looking forward to hearing about
> your experiences when you start trying it out on your next project.
>
> - Freedom
>
>
> On Tue, Nov 20, 2012 at 12:30 PM, Joe Esposito <espo58@gmail.com> wrote:
>
>> Finally had a chance to take a closer look. This looks great!
>> Most of the initial negative reactions when I introduce Flask are the
>> lack of class-based views. I'll now include this extension to ease the
>> doubts =)
>>
>> Some thoughts, if it's not too late:
>>
>>    - The Github repo should have a link at the top to
>>    http://packages.python.org/Flask-Classy/
>>    - Consider using a Fork me on Github 
ribbon<https://github.com/blog/273-github-ribbons>on that site. Should be 
as easy as possible to find the source code from
>>    the docs, and vice versa.
>>    - Speaking of the docs, I really enjoyed reading them!
>>    - Being an advocate of minimalism, is there a reason you didn't name
>>    the view class "View" instead of "FlaskView"?
>>    Is it that too many people would have name collisions? I think "View"
>>    is a less verbose default, and doing from flask.ext.classy import
>>    View as FlaskView as needed
>>
>> I also wonder if this will help with composability. I'd love to see a
>> large example site using class-based views with diverging functionality.
>> I'll try this out with my next Flask project and write about it if
>> there's anything worth adding.
>>
>> Good work!
>>
>> On Tue, Nov 20, 2012 at 11:23 AM, Freedom Dumlao <freedomdumlao@gmail.com
>> > wrote:
>>
>>> Awesome Mark. I'd love to hear about your experiences. We're working on
>>> backporting it into the codebase it was inspired from at work now as well.
>>> I'm almost done with the template related features, hopefully I'll get
>>> those out this weekend.
>>>
>>>
>>> On Tue, Nov 20, 2012 at 10:52 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>
>>>> No problem man.  I'm really liking this approach moreso than what I had
>>>> before with methodviews (esp since the register methodology for the
>>>> methodviews is about 5 lines in a dedicated function at the official docs,
>>>> a bit less sexy than a one line decorator)
>>>>
>>>> That was the last issue I could find refactoring our url structure to
>>>> use classy, so I feel more or less comfortable adopting this inside our
>>>> app.  It feel so much more elegant to have the views defined via their
>>>> corresponding program models (REST ftw) rather than wording them more
>>>> centered around the structure or confines of the HTTP protocol itself.
>>>>  After, HTTP is but one interface we may be exposing our services over.
>>>>
>>>> Pending approval from the bosses we'll actually be rolling this out
>>>> as-is in deployment.
>>>>
>>>>
>>>> On Tue, Nov 20, 2012 at 1:31 AM, Freedom Dumlao <
>>>> freedomdumlao@gmail.com> wrote:
>>>>
>>>>> Mark,
>>>>>
>>>>> I've got a fix for that issue as well as extending the tests to cover
>>>>> that case. It's in version 0.5.1.
>>>>>
>>>>> Thanks for the excellent write upon the issue, it made it much easier
>>>>> to track down than it would have been otherwise.
>>>>>
>>>>> - Freedom
>>>>>
>>>>>
>>>>> On Mon, Nov 19, 2012 at 12:19 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>
>>>>>> Didn't have the chance to test it prior, though I suppose I could
>>>>>> spin up a virtualenv with an older version to see.
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <
>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>
>>>>>>> Thanks Mark.
>>>>>>>
>>>>>>> Please go ahead and file an issue on github, and if you've got a
>>>>>>> test case I'll gladly accept it. Was this working before 0.5 release?
>>>>>>>
>>>>>>> - Freedom
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>>>
>>>>>>>> Hey Freedom,
>>>>>>>>
>>>>>>>> Wanted to run this by you before I filed a github issue.
>>>>>>>>
>>>>>>>> I have some FlaskViews that get registered at two different
>>>>>>>> subdomains.  Both views use the @route decorator to add some extra custom
>>>>>>>> methods.
>>>>>>>>
>>>>>>>> I appears that method routes declared with the decorator dont honor
>>>>>>>> the subdomain passed to the register function.  I can provide a test case
>>>>>>>> if needed.
>>>>>>>>
>>>>>>>> ~Mark
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> This is awesome. I'm just getting started with Flask coming from a
>>>>>>>>> Java world and was wondering how I can organize things better. 
This gets me
>>>>>>>>> started in the right direction.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <
>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> After receiving tons of feedback on the initial API and
>>>>>>>>>> functionality, and implementing almost all of it, I've finally released
>>>>>>>>>> version 0.5. I feel the API is really starting to mature and 
would love any
>>>>>>>>>> of you didn't think it was quite right before to give it 
another look and
>>>>>>>>>> tell me what you think now.
>>>>>>>>>>
>>>>>>>>>> 0.5 introduced some breaking changes, for anyone who has been
>>>>>>>>>> using it so far but they are fairly simple and honestly I think
they make a
>>>>>>>>>> lot of sense. Take a look at the changelog for more information or feel
>>>>>>>>>> free to ask me directly.
>>>>>>>>>>
>>>>>>>>>> Also in there since the initial release is a new feature to wrap
>>>>>>>>>> views with custom before and after methods. That was the first 
step before
>>>>>>>>>> providing a central context for view specific template 
management, but it's
>>>>>>>>>> also extremely useful for all the other things 
response-wrapping is good
>>>>>>>>>> for.
>>>>>>>>>>
>>>>>>>>>> Thanks Flaskers for all the feedback so far. You've made working
>>>>>>>>>> on this project more rewarding than it would have been going it alone.
>>>>>>>>>>
>>>>>>>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>>>>>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>>>>>>>
>>>>>>>>>> - Freedom
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Imran
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] Flask-Classy 0.5

From:
Freedom Dumlao
Date:
2012-11-20 @ 19:32
Thanks Owein!

I actually have no idea how to get into an approval process for addition to
the approved list. The documentation listed all of the pre-requisites for
consideration (which I believe I have met) but it didn't mention any formal
submission process.

I considered emailing Armin early on, but decided against it out of respect
for the fact that he likely subscribes to this list himself already.

- Freedom


On Tue, Nov 20, 2012 at 2:19 PM, Owein Reese <owreese@gmail.com> wrote:

> Freedom,
>
> I like FlaskView. For all the points that you mentioned, it's succinct,
> descriptive, and to the point. I hope you can get Flask-Classy in the
> approved list as fast as possible. Id like to point some people to it at
> work but being in the financial industry it'll have to "approved."
>
> Great library and thanks for your hard work.
> On Nov 20, 2012 1:42 PM, "Freedom Dumlao" <freedomdumlao@gmail.com> wrote:
>
>> Thanks Joe,
>>
>> I added the link to the github repo, should have done that a while ago! I
>> used to have the 'fork me' banner but I must have left it out when I
>> updated to using the table of contents, I'll be sure and get that fixed
>> asap.
>>
>> I'm glad you liked the docs my writing style isn't for everyone, but
>> honestly I hate writing documentation, so I figured I'd do it in a way that
>> I could entertain myself a bit as I wrote and that got the job done :)
>>
>> I selected 'FlaskView' over just 'View' because in the application that
>> inspired the Flask-Classy extension the concept of a 'View' is quite
>> ambiguous. The Flask front end is only one part of a large application and
>> it helped to distinguish that this was a 'View Class for Flask' as opposed
>> to View classes that represent pre-computed database datasets or View
>> classes that exist for supporting legacy integrations. I did consider other
>> names for it, but I hate naming things and if I had kept it up we very well
>> might have had it be called BaseFlaskClassyViewClassClass or something much
>> worse. Luckily I stopped before things got out of hand.
>>
>> All that being said, if there were strong community support for a
>> specific name, I certainly wouldn't be opposed.
>>
>> After I get the Template features in this weekend (I hope), I plan on
>> trying to get a sample application written and documented, and then let the
>> dust settle on the API for a bit to see how it feels for everyone
>> (including those of us using it where I work.) Hopefully that will help to
>> inspire those users that require some "see it in action" type of
>> inspiration.
>>
>> I really appreciate your feedback and I'm looking forward to hearing
>> about your experiences when you start trying it out on your next project.
>>
>> - Freedom
>>
>>
>> On Tue, Nov 20, 2012 at 12:30 PM, Joe Esposito <espo58@gmail.com> wrote:
>>
>>> Finally had a chance to take a closer look. This looks great!
>>> Most of the initial negative reactions when I introduce Flask are the
>>> lack of class-based views. I'll now include this extension to ease the
>>> doubts =)
>>>
>>> Some thoughts, if it's not too late:
>>>
>>>    - The Github repo should have a link at the top to
>>>    http://packages.python.org/Flask-Classy/
>>>    - Consider using a Fork me on Github 
ribbon<https://github.com/blog/273-github-ribbons>on that site. Should be 
as easy as possible to find the source code from
>>>    the docs, and vice versa.
>>>    - Speaking of the docs, I really enjoyed reading them!
>>>    - Being an advocate of minimalism, is there a reason you didn't name
>>>    the view class "View" instead of "FlaskView"?
>>>    Is it that too many people would have name collisions? I think
>>>    "View" is a less verbose default, and doing from flask.ext.classy
>>>    import View as FlaskView as needed
>>>
>>> I also wonder if this will help with composability. I'd love to see a
>>> large example site using class-based views with diverging functionality.
>>> I'll try this out with my next Flask project and write about it if
>>> there's anything worth adding.
>>>
>>> Good work!
>>>
>>> On Tue, Nov 20, 2012 at 11:23 AM, Freedom Dumlao <
>>> freedomdumlao@gmail.com> wrote:
>>>
>>>> Awesome Mark. I'd love to hear about your experiences. We're working on
>>>> backporting it into the codebase it was inspired from at work now as well.
>>>> I'm almost done with the template related features, hopefully I'll get
>>>> those out this weekend.
>>>>
>>>>
>>>> On Tue, Nov 20, 2012 at 10:52 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>
>>>>> No problem man.  I'm really liking this approach moreso than what I
>>>>> had before with methodviews (esp since the register methodology for the
>>>>> methodviews is about 5 lines in a dedicated function at the official docs,
>>>>> a bit less sexy than a one line decorator)
>>>>>
>>>>> That was the last issue I could find refactoring our url structure to
>>>>> use classy, so I feel more or less comfortable adopting this inside our
>>>>> app.  It feel so much more elegant to have the views defined via their
>>>>> corresponding program models (REST ftw) rather than wording them more
>>>>> centered around the structure or confines of the HTTP protocol itself.
>>>>>  After, HTTP is but one interface we may be exposing our services over.
>>>>>
>>>>> Pending approval from the bosses we'll actually be rolling this out
>>>>> as-is in deployment.
>>>>>
>>>>>
>>>>> On Tue, Nov 20, 2012 at 1:31 AM, Freedom Dumlao <
>>>>> freedomdumlao@gmail.com> wrote:
>>>>>
>>>>>> Mark,
>>>>>>
>>>>>> I've got a fix for that issue as well as extending the tests to cover
>>>>>> that case. It's in version 0.5.1.
>>>>>>
>>>>>> Thanks for the excellent write upon the issue, it made it much easier
>>>>>> to track down than it would have been otherwise.
>>>>>>
>>>>>> - Freedom
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 19, 2012 at 12:19 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>>
>>>>>>> Didn't have the chance to test it prior, though I suppose I could
>>>>>>> spin up a virtualenv with an older version to see.
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <
>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>
>>>>>>>> Thanks Mark.
>>>>>>>>
>>>>>>>> Please go ahead and file an issue on github, and if you've got a
>>>>>>>> test case I'll gladly accept it. Was this working before 0.5 release?
>>>>>>>>
>>>>>>>> - Freedom
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Hey Freedom,
>>>>>>>>>
>>>>>>>>> Wanted to run this by you before I filed a github issue.
>>>>>>>>>
>>>>>>>>> I have some FlaskViews that get registered at two different
>>>>>>>>> subdomains.  Both views use the @route decorator to add some 
extra custom
>>>>>>>>> methods.
>>>>>>>>>
>>>>>>>>> I appears that method routes declared with the decorator dont
>>>>>>>>> honor the subdomain passed to the register function.  I can 
provide a test
>>>>>>>>> case if needed.
>>>>>>>>>
>>>>>>>>> ~Mark
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com>wrote:
>>>>>>>>>
>>>>>>>>>> This is awesome. I'm just getting started with Flask coming from
>>>>>>>>>> a Java world and was wondering how I can organize things 
better. This gets
>>>>>>>>>> me started in the right direction.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <
>>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> After receiving tons of feedback on the initial API and
>>>>>>>>>>> functionality, and implementing almost all of it, I've finally
released
>>>>>>>>>>> version 0.5. I feel the API is really starting to mature and 
would love any
>>>>>>>>>>> of you didn't think it was quite right before to give it 
another look and
>>>>>>>>>>> tell me what you think now.
>>>>>>>>>>>
>>>>>>>>>>> 0.5 introduced some breaking changes, for anyone who has been
>>>>>>>>>>> using it so far but they are fairly simple and honestly I 
think they make a
>>>>>>>>>>> lot of sense. Take a look at the changelog for more 
information or feel
>>>>>>>>>>> free to ask me directly.
>>>>>>>>>>>
>>>>>>>>>>> Also in there since the initial release is a new feature to wrap
>>>>>>>>>>> views with custom before and after methods. That was the first
step before
>>>>>>>>>>> providing a central context for view specific template 
management, but it's
>>>>>>>>>>> also extremely useful for all the other things 
response-wrapping is good
>>>>>>>>>>> for.
>>>>>>>>>>>
>>>>>>>>>>> Thanks Flaskers for all the feedback so far. You've made working
>>>>>>>>>>> on this project more rewarding than it would have been going it alone.
>>>>>>>>>>>
>>>>>>>>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>>>>>>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>>>>>>>>
>>>>>>>>>>> - Freedom
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Imran
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

Re: [flask] Flask-Classy 0.5

From:
Edd Robinson
Date:
2012-11-20 @ 19:48
On 20 Nov 2012, at 19:32, Freedom Dumlao wrote:

> Thanks Owein!
> 
> I actually have no idea how to get into an approval process for addition
to the approved list. The documentation listed all of the pre-requisites 
for consideration (which I believe I have met) but it didn't mention any 
formal submission process.
> 
> I considered emailing Armin early on, but decided against it out of 
respect for the fact that he likely subscribes to this list himself 
already.
> 
> - Freedom

I'm not entirely sure how it works really. I guess it's just as and when 
Armin or whoever get around to it.

For Flask-S3 (http://flask-s3.readthedocs.org/en/latest/) I sent an email 
around, mentioned it on IRC and added an extension request approval to the
issues list, but not heard anything back. I shall wait and see. :-)


Cheers,
Edd

http://eddrobinson.net

Re: [flask] Flask-Classy 0.5

From:
Joe Esposito
Date:
2012-11-21 @ 00:52
> *I added the link to the github repo .. **I'll be sure and get that fixed
asap*
Excellent =)

> *but honestly I hate writing documentation, so I figured I'd do it in a
way that I could entertain myself a bit as I wrote and that got the job
done :)*
Hey, that's what's important. Whatever gets the job done!

> *I selected 'FlaskView' over just 'View' because in the application that
inspired the Flask-Classy extension the concept of a 'View' is quite
ambiguous*

That's what namespaces are for though. The from flask.ext.classy gives you
enough disambiguation without needing to be explicit all over the place.
And if you did need that extra clarity, like when you're using two
different concepts of "view" in the same file, you can still write import
View as FlaskView.

This is similar logic to why Flask exposes a Request class instead of
FlaskRequest, even though there are several meanings of the name "request".
Actually, both Flask and Werkzeug expose their own Request class. Flask even
extends Werkzeug's
class<https://github.com/mitsuhiko/flask/blob/master/flask/wrappers.py#L12>,
distinguishing
its own using like so: import Request as RequestBase.

Namespaces via packages allows both simplicity and clarity.

>  *if there were strong community support for a specific name, I certainly
wouldn't be opposed.*
Agreed. I could be alone on this. I'm just trying to provide some
counter-points =)

> *I really appreciate your feedback and I'm looking forward to hearing
about your experiences when you start trying it out on your next project.*
Thanks! And I'll ping you down the road when I do. Again, awesome work!

On Tue, Nov 20, 2012 at 1:29 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> Thanks Joe,
>
> I added the link to the github repo, should have done that a while ago! I
> used to have the 'fork me' banner but I must have left it out when I
> updated to using the table of contents, I'll be sure and get that fixed
> asap.
>
> I'm glad you liked the docs my writing style isn't for everyone, but
> honestly I hate writing documentation, so I figured I'd do it in a way that
> I could entertain myself a bit as I wrote and that got the job done :)
>
> I selected 'FlaskView' over just 'View' because in the application that
> inspired the Flask-Classy extension the concept of a 'View' is quite
> ambiguous. The Flask front end is only one part of a large application and
> it helped to distinguish that this was a 'View Class for Flask' as opposed
> to View classes that represent pre-computed database datasets or View
> classes that exist for supporting legacy integrations. I did consider other
> names for it, but I hate naming things and if I had kept it up we very well
> might have had it be called BaseFlaskClassyViewClassClass or something much
> worse. Luckily I stopped before things got out of hand.
>
> All that being said, if there were strong community support for a specific
> name, I certainly wouldn't be opposed.
>
> After I get the Template features in this weekend (I hope), I plan on
> trying to get a sample application written and documented, and then let the
> dust settle on the API for a bit to see how it feels for everyone
> (including those of us using it where I work.) Hopefully that will help to
> inspire those users that require some "see it in action" type of
> inspiration.
>
> I really appreciate your feedback and I'm looking forward to hearing about
> your experiences when you start trying it out on your next project.
>
> - Freedom
>
>
> On Tue, Nov 20, 2012 at 12:30 PM, Joe Esposito <espo58@gmail.com> wrote:
>
>> Finally had a chance to take a closer look. This looks great!
>> Most of the initial negative reactions when I introduce Flask are the
>> lack of class-based views. I'll now include this extension to ease the
>> doubts =)
>>
>> Some thoughts, if it's not too late:
>>
>>    - The Github repo should have a link at the top to
>>    http://packages.python.org/Flask-Classy/
>>    - Consider using a Fork me on Github 
ribbon<https://github.com/blog/273-github-ribbons>on that site. Should be 
as easy as possible to find the source code from
>>    the docs, and vice versa.
>>    - Speaking of the docs, I really enjoyed reading them!
>>    - Being an advocate of minimalism, is there a reason you didn't name
>>    the view class "View" instead of "FlaskView"?
>>    Is it that too many people would have name collisions? I think "View"
>>    is a less verbose default, and doing from flask.ext.classy import
>>    View as FlaskView as needed
>>
>> I also wonder if this will help with composability. I'd love to see a
>> large example site using class-based views with diverging functionality.
>> I'll try this out with my next Flask project and write about it if
>> there's anything worth adding.
>>
>> Good work!
>>
>> On Tue, Nov 20, 2012 at 11:23 AM, Freedom Dumlao <freedomdumlao@gmail.com
>> > wrote:
>>
>>> Awesome Mark. I'd love to hear about your experiences. We're working on
>>> backporting it into the codebase it was inspired from at work now as well.
>>> I'm almost done with the template related features, hopefully I'll get
>>> those out this weekend.
>>>
>>>
>>> On Tue, Nov 20, 2012 at 10:52 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>
>>>> No problem man.  I'm really liking this approach moreso than what I had
>>>> before with methodviews (esp since the register methodology for the
>>>> methodviews is about 5 lines in a dedicated function at the official docs,
>>>> a bit less sexy than a one line decorator)
>>>>
>>>> That was the last issue I could find refactoring our url structure to
>>>> use classy, so I feel more or less comfortable adopting this inside our
>>>> app.  It feel so much more elegant to have the views defined via their
>>>> corresponding program models (REST ftw) rather than wording them more
>>>> centered around the structure or confines of the HTTP protocol itself.
>>>>  After, HTTP is but one interface we may be exposing our services over.
>>>>
>>>> Pending approval from the bosses we'll actually be rolling this out
>>>> as-is in deployment.
>>>>
>>>>
>>>> On Tue, Nov 20, 2012 at 1:31 AM, Freedom Dumlao <
>>>> freedomdumlao@gmail.com> wrote:
>>>>
>>>>> Mark,
>>>>>
>>>>> I've got a fix for that issue as well as extending the tests to cover
>>>>> that case. It's in version 0.5.1.
>>>>>
>>>>> Thanks for the excellent write upon the issue, it made it much easier
>>>>> to track down than it would have been otherwise.
>>>>>
>>>>> - Freedom
>>>>>
>>>>>
>>>>> On Mon, Nov 19, 2012 at 12:19 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>
>>>>>> Didn't have the chance to test it prior, though I suppose I could
>>>>>> spin up a virtualenv with an older version to see.
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <
>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>
>>>>>>> Thanks Mark.
>>>>>>>
>>>>>>> Please go ahead and file an issue on github, and if you've got a
>>>>>>> test case I'll gladly accept it. Was this working before 0.5 release?
>>>>>>>
>>>>>>> - Freedom
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>>>
>>>>>>>> Hey Freedom,
>>>>>>>>
>>>>>>>> Wanted to run this by you before I filed a github issue.
>>>>>>>>
>>>>>>>> I have some FlaskViews that get registered at two different
>>>>>>>> subdomains.  Both views use the @route decorator to add some extra custom
>>>>>>>> methods.
>>>>>>>>
>>>>>>>> I appears that method routes declared with the decorator dont honor
>>>>>>>> the subdomain passed to the register function.  I can provide a test case
>>>>>>>> if needed.
>>>>>>>>
>>>>>>>> ~Mark
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> This is awesome. I'm just getting started with Flask coming from a
>>>>>>>>> Java world and was wondering how I can organize things better. 
This gets me
>>>>>>>>> started in the right direction.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <
>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> After receiving tons of feedback on the initial API and
>>>>>>>>>> functionality, and implementing almost all of it, I've finally released
>>>>>>>>>> version 0.5. I feel the API is really starting to mature and 
would love any
>>>>>>>>>> of you didn't think it was quite right before to give it 
another look and
>>>>>>>>>> tell me what you think now.
>>>>>>>>>>
>>>>>>>>>> 0.5 introduced some breaking changes, for anyone who has been
>>>>>>>>>> using it so far but they are fairly simple and honestly I think
they make a
>>>>>>>>>> lot of sense. Take a look at the changelog for more information or feel
>>>>>>>>>> free to ask me directly.
>>>>>>>>>>
>>>>>>>>>> Also in there since the initial release is a new feature to wrap
>>>>>>>>>> views with custom before and after methods. That was the first 
step before
>>>>>>>>>> providing a central context for view specific template 
management, but it's
>>>>>>>>>> also extremely useful for all the other things 
response-wrapping is good
>>>>>>>>>> for.
>>>>>>>>>>
>>>>>>>>>> Thanks Flaskers for all the feedback so far. You've made working
>>>>>>>>>> on this project more rewarding than it would have been going it alone.
>>>>>>>>>>
>>>>>>>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>>>>>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>>>>>>>
>>>>>>>>>> - Freedom
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Imran
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] Flask-Classy 0.5

From:
Freedom Dumlao
Date:
2012-11-21 @ 14:02
Joe I totally agree about namespaces.

I guess it's my own bias that I loathe using 'as' in my imports and I do
avoid it when I can. Where do you personally rate the name FlaskView? Is it
terrible or just kind of annoying?

- Freedom


On Tue, Nov 20, 2012 at 7:52 PM, Joe Esposito <espo58@gmail.com> wrote:

> > *I added the link to the github repo .. **I'll be sure and get that
> fixed asap*
> Excellent =)
>
> > *but honestly I hate writing documentation, so I figured I'd do it in a
> way that I could entertain myself a bit as I wrote and that got the job
> done :)*
> Hey, that's what's important. Whatever gets the job done!
>
> > *I selected 'FlaskView' over just 'View' because in the application
> that inspired the Flask-Classy extension the concept of a 'View' is quite
> ambiguous*
>
> That's what namespaces are for though. The from flask.ext.classy gives
> you enough disambiguation without needing to be explicit all over the
> place. And if you did need that extra clarity, like when you're using two
> different concepts of "view" in the same file, you can still write import
> View as FlaskView.
>
> This is similar logic to why Flask exposes a Request class instead of
> FlaskRequest, even though there are several meanings of the name "request".
> Actually, both Flask and Werkzeug expose their own Request class. Flask even
> extends Werkzeug's 
class<https://github.com/mitsuhiko/flask/blob/master/flask/wrappers.py#L12>,
distinguishing
> its own using like so: import Request as RequestBase.
>
> Namespaces via packages allows both simplicity and clarity.
>
> >  *if there were strong community support for a specific name, I
> certainly wouldn't be opposed.*
> Agreed. I could be alone on this. I'm just trying to provide some
> counter-points =)
>
> > *I really appreciate your feedback and I'm looking forward to hearing
> about your experiences when you start trying it out on your next project.*
> Thanks! And I'll ping you down the road when I do. Again, awesome work!
>
> On Tue, Nov 20, 2012 at 1:29 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>
>> Thanks Joe,
>>
>> I added the link to the github repo, should have done that a while ago! I
>> used to have the 'fork me' banner but I must have left it out when I
>> updated to using the table of contents, I'll be sure and get that fixed
>> asap.
>>
>> I'm glad you liked the docs my writing style isn't for everyone, but
>> honestly I hate writing documentation, so I figured I'd do it in a way that
>> I could entertain myself a bit as I wrote and that got the job done :)
>>
>> I selected 'FlaskView' over just 'View' because in the application that
>> inspired the Flask-Classy extension the concept of a 'View' is quite
>> ambiguous. The Flask front end is only one part of a large application and
>> it helped to distinguish that this was a 'View Class for Flask' as opposed
>> to View classes that represent pre-computed database datasets or View
>> classes that exist for supporting legacy integrations. I did consider other
>> names for it, but I hate naming things and if I had kept it up we very well
>> might have had it be called BaseFlaskClassyViewClassClass or something much
>> worse. Luckily I stopped before things got out of hand.
>>
>> All that being said, if there were strong community support for a
>> specific name, I certainly wouldn't be opposed.
>>
>> After I get the Template features in this weekend (I hope), I plan on
>> trying to get a sample application written and documented, and then let the
>> dust settle on the API for a bit to see how it feels for everyone
>> (including those of us using it where I work.) Hopefully that will help to
>> inspire those users that require some "see it in action" type of
>> inspiration.
>>
>> I really appreciate your feedback and I'm looking forward to hearing
>> about your experiences when you start trying it out on your next project.
>>
>> - Freedom
>>
>>
>> On Tue, Nov 20, 2012 at 12:30 PM, Joe Esposito <espo58@gmail.com> wrote:
>>
>>> Finally had a chance to take a closer look. This looks great!
>>> Most of the initial negative reactions when I introduce Flask are the
>>> lack of class-based views. I'll now include this extension to ease the
>>> doubts =)
>>>
>>> Some thoughts, if it's not too late:
>>>
>>>    - The Github repo should have a link at the top to
>>>    http://packages.python.org/Flask-Classy/
>>>    - Consider using a Fork me on Github 
ribbon<https://github.com/blog/273-github-ribbons>on that site. Should be 
as easy as possible to find the source code from
>>>    the docs, and vice versa.
>>>    - Speaking of the docs, I really enjoyed reading them!
>>>    - Being an advocate of minimalism, is there a reason you didn't name
>>>    the view class "View" instead of "FlaskView"?
>>>    Is it that too many people would have name collisions? I think
>>>    "View" is a less verbose default, and doing from flask.ext.classy
>>>    import View as FlaskView as needed
>>>
>>> I also wonder if this will help with composability. I'd love to see a
>>> large example site using class-based views with diverging functionality.
>>> I'll try this out with my next Flask project and write about it if
>>> there's anything worth adding.
>>>
>>> Good work!
>>>
>>> On Tue, Nov 20, 2012 at 11:23 AM, Freedom Dumlao <
>>> freedomdumlao@gmail.com> wrote:
>>>
>>>> Awesome Mark. I'd love to hear about your experiences. We're working on
>>>> backporting it into the codebase it was inspired from at work now as well.
>>>> I'm almost done with the template related features, hopefully I'll get
>>>> those out this weekend.
>>>>
>>>>
>>>> On Tue, Nov 20, 2012 at 10:52 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>
>>>>> No problem man.  I'm really liking this approach moreso than what I
>>>>> had before with methodviews (esp since the register methodology for the
>>>>> methodviews is about 5 lines in a dedicated function at the official docs,
>>>>> a bit less sexy than a one line decorator)
>>>>>
>>>>> That was the last issue I could find refactoring our url structure to
>>>>> use classy, so I feel more or less comfortable adopting this inside our
>>>>> app.  It feel so much more elegant to have the views defined via their
>>>>> corresponding program models (REST ftw) rather than wording them more
>>>>> centered around the structure or confines of the HTTP protocol itself.
>>>>>  After, HTTP is but one interface we may be exposing our services over.
>>>>>
>>>>> Pending approval from the bosses we'll actually be rolling this out
>>>>> as-is in deployment.
>>>>>
>>>>>
>>>>> On Tue, Nov 20, 2012 at 1:31 AM, Freedom Dumlao <
>>>>> freedomdumlao@gmail.com> wrote:
>>>>>
>>>>>> Mark,
>>>>>>
>>>>>> I've got a fix for that issue as well as extending the tests to cover
>>>>>> that case. It's in version 0.5.1.
>>>>>>
>>>>>> Thanks for the excellent write upon the issue, it made it much easier
>>>>>> to track down than it would have been otherwise.
>>>>>>
>>>>>> - Freedom
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 19, 2012 at 12:19 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>>
>>>>>>> Didn't have the chance to test it prior, though I suppose I could
>>>>>>> spin up a virtualenv with an older version to see.
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <
>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>
>>>>>>>> Thanks Mark.
>>>>>>>>
>>>>>>>> Please go ahead and file an issue on github, and if you've got a
>>>>>>>> test case I'll gladly accept it. Was this working before 0.5 release?
>>>>>>>>
>>>>>>>> - Freedom
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Hey Freedom,
>>>>>>>>>
>>>>>>>>> Wanted to run this by you before I filed a github issue.
>>>>>>>>>
>>>>>>>>> I have some FlaskViews that get registered at two different
>>>>>>>>> subdomains.  Both views use the @route decorator to add some 
extra custom
>>>>>>>>> methods.
>>>>>>>>>
>>>>>>>>> I appears that method routes declared with the decorator dont
>>>>>>>>> honor the subdomain passed to the register function.  I can 
provide a test
>>>>>>>>> case if needed.
>>>>>>>>>
>>>>>>>>> ~Mark
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com>wrote:
>>>>>>>>>
>>>>>>>>>> This is awesome. I'm just getting started with Flask coming from
>>>>>>>>>> a Java world and was wondering how I can organize things 
better. This gets
>>>>>>>>>> me started in the right direction.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <
>>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> After receiving tons of feedback on the initial API and
>>>>>>>>>>> functionality, and implementing almost all of it, I've finally
released
>>>>>>>>>>> version 0.5. I feel the API is really starting to mature and 
would love any
>>>>>>>>>>> of you didn't think it was quite right before to give it 
another look and
>>>>>>>>>>> tell me what you think now.
>>>>>>>>>>>
>>>>>>>>>>> 0.5 introduced some breaking changes, for anyone who has been
>>>>>>>>>>> using it so far but they are fairly simple and honestly I 
think they make a
>>>>>>>>>>> lot of sense. Take a look at the changelog for more 
information or feel
>>>>>>>>>>> free to ask me directly.
>>>>>>>>>>>
>>>>>>>>>>> Also in there since the initial release is a new feature to wrap
>>>>>>>>>>> views with custom before and after methods. That was the first
step before
>>>>>>>>>>> providing a central context for view specific template 
management, but it's
>>>>>>>>>>> also extremely useful for all the other things 
response-wrapping is good
>>>>>>>>>>> for.
>>>>>>>>>>>
>>>>>>>>>>> Thanks Flaskers for all the feedback so far. You've made working
>>>>>>>>>>> on this project more rewarding than it would have been going it alone.
>>>>>>>>>>>
>>>>>>>>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>>>>>>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>>>>>>>>
>>>>>>>>>>> - Freedom
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Imran
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] Flask-Classy 0.5

From:
Smartboy
Date:
2012-11-21 @ 16:55
Freedom, it's looking good! One thing that annoys me about python is that
decorators are run upon class creation, not class instantiation, which
means using, eg, Flask-Login's login_required decorator strips the self
from a method that it's applied to. I may write a patch later to allow for
these decorators to be adapted and used with Flask-Classy.

On Wed, Nov 21, 2012 at 6:02 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> Joe I totally agree about namespaces.
>
> I guess it's my own bias that I loathe using 'as' in my imports and I do
> avoid it when I can. Where do you personally rate the name FlaskView? Is it
> terrible or just kind of annoying?
>
> - Freedom
>
>
> On Tue, Nov 20, 2012 at 7:52 PM, Joe Esposito <espo58@gmail.com> wrote:
>
>> > *I added the link to the github repo .. **I'll be sure and get that
>> fixed asap*
>> Excellent =)
>>
>> > *but honestly I hate writing documentation, so I figured I'd do it in
>> a way that I could entertain myself a bit as I wrote and that got the job
>> done :)*
>> Hey, that's what's important. Whatever gets the job done!
>>
>>  > *I selected 'FlaskView' over just 'View' because in the application
>> that inspired the Flask-Classy extension the concept of a 'View' is quite
>> ambiguous*
>>
>> That's what namespaces are for though. The from flask.ext.classy gives
>> you enough disambiguation without needing to be explicit all over the
>> place. And if you did need that extra clarity, like when you're using two
>> different concepts of "view" in the same file, you can still write import
>> View as FlaskView.
>>
>> This is similar logic to why Flask exposes a Request class instead of
>> FlaskRequest, even though there are several meanings of the name "request
>> ". Actually, both Flask and Werkzeug expose their own Request class.
>> Flask even extends Werkzeug's 
class<https://github.com/mitsuhiko/flask/blob/master/flask/wrappers.py#L12>,
distinguishing
>> its own using like so: import Request as RequestBase.
>>
>> Namespaces via packages allows both simplicity and clarity.
>>
>> >  *if there were strong community support for a specific name, I
>> certainly wouldn't be opposed.*
>> Agreed. I could be alone on this. I'm just trying to provide some
>> counter-points =)
>>
>> > *I really appreciate your feedback and I'm looking forward to hearing
>> about your experiences when you start trying it out on your next project.
>> *
>> Thanks! And I'll ping you down the road when I do. Again, awesome work!
>>
>> On Tue, Nov 20, 2012 at 1:29 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>>
>>> Thanks Joe,
>>>
>>> I added the link to the github repo, should have done that a while ago!
>>> I used to have the 'fork me' banner but I must have left it out when I
>>> updated to using the table of contents, I'll be sure and get that fixed
>>> asap.
>>>
>>> I'm glad you liked the docs my writing style isn't for everyone, but
>>> honestly I hate writing documentation, so I figured I'd do it in a way that
>>> I could entertain myself a bit as I wrote and that got the job done :)
>>>
>>> I selected 'FlaskView' over just 'View' because in the application that
>>> inspired the Flask-Classy extension the concept of a 'View' is quite
>>> ambiguous. The Flask front end is only one part of a large application and
>>> it helped to distinguish that this was a 'View Class for Flask' as opposed
>>> to View classes that represent pre-computed database datasets or View
>>> classes that exist for supporting legacy integrations. I did consider other
>>> names for it, but I hate naming things and if I had kept it up we very well
>>> might have had it be called BaseFlaskClassyViewClassClass or something much
>>> worse. Luckily I stopped before things got out of hand.
>>>
>>> All that being said, if there were strong community support for a
>>> specific name, I certainly wouldn't be opposed.
>>>
>>> After I get the Template features in this weekend (I hope), I plan on
>>> trying to get a sample application written and documented, and then let the
>>> dust settle on the API for a bit to see how it feels for everyone
>>> (including those of us using it where I work.) Hopefully that will help to
>>> inspire those users that require some "see it in action" type of
>>> inspiration.
>>>
>>> I really appreciate your feedback and I'm looking forward to hearing
>>> about your experiences when you start trying it out on your next project.
>>>
>>> - Freedom
>>>
>>>
>>> On Tue, Nov 20, 2012 at 12:30 PM, Joe Esposito <espo58@gmail.com> wrote:
>>>
>>>> Finally had a chance to take a closer look. This looks great!
>>>> Most of the initial negative reactions when I introduce Flask are the
>>>> lack of class-based views. I'll now include this extension to ease the
>>>> doubts =)
>>>>
>>>> Some thoughts, if it's not too late:
>>>>
>>>>    - The Github repo should have a link at the top to
>>>>    http://packages.python.org/Flask-Classy/
>>>>    - Consider using a Fork me on Github 
ribbon<https://github.com/blog/273-github-ribbons>on that site. Should be 
as easy as possible to find the source code from
>>>>    the docs, and vice versa.
>>>>    - Speaking of the docs, I really enjoyed reading them!
>>>>    - Being an advocate of minimalism, is there a reason you didn't
>>>>    name the view class "View" instead of "FlaskView"?
>>>>    Is it that too many people would have name collisions? I think
>>>>    "View" is a less verbose default, and doing from flask.ext.classy
>>>>    import View as FlaskView as needed
>>>>
>>>> I also wonder if this will help with composability. I'd love to see a
>>>> large example site using class-based views with diverging functionality.
>>>> I'll try this out with my next Flask project and write about it if
>>>> there's anything worth adding.
>>>>
>>>> Good work!
>>>>
>>>> On Tue, Nov 20, 2012 at 11:23 AM, Freedom Dumlao <
>>>> freedomdumlao@gmail.com> wrote:
>>>>
>>>>> Awesome Mark. I'd love to hear about your experiences. We're working
>>>>> on backporting it into the codebase it was inspired from at work now as
>>>>> well. I'm almost done with the template related features, hopefully I'll
>>>>> get those out this weekend.
>>>>>
>>>>>
>>>>> On Tue, Nov 20, 2012 at 10:52 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>
>>>>>> No problem man.  I'm really liking this approach moreso than what I
>>>>>> had before with methodviews (esp since the register methodology for the
>>>>>> methodviews is about 5 lines in a dedicated function at the official docs,
>>>>>> a bit less sexy than a one line decorator)
>>>>>>
>>>>>> That was the last issue I could find refactoring our url structure to
>>>>>> use classy, so I feel more or less comfortable adopting this inside our
>>>>>> app.  It feel so much more elegant to have the views defined via their
>>>>>> corresponding program models (REST ftw) rather than wording them more
>>>>>> centered around the structure or confines of the HTTP protocol itself.
>>>>>>  After, HTTP is but one interface we may be exposing our services over.
>>>>>>
>>>>>> Pending approval from the bosses we'll actually be rolling this out
>>>>>> as-is in deployment.
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 20, 2012 at 1:31 AM, Freedom Dumlao <
>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>
>>>>>>> Mark,
>>>>>>>
>>>>>>> I've got a fix for that issue as well as extending the tests to
>>>>>>> cover that case. It's in version 0.5.1.
>>>>>>>
>>>>>>> Thanks for the excellent write upon the issue, it made it much
>>>>>>> easier to track down than it would have been otherwise.
>>>>>>>
>>>>>>> - Freedom
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 19, 2012 at 12:19 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>>>
>>>>>>>> Didn't have the chance to test it prior, though I suppose I could
>>>>>>>> spin up a virtualenv with an older version to see.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <
>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Thanks Mark.
>>>>>>>>>
>>>>>>>>> Please go ahead and file an issue on github, and if you've got a
>>>>>>>>> test case I'll gladly accept it. Was this working before 0.5 release?
>>>>>>>>>
>>>>>>>>> - Freedom
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <
>>>>>>>>> mark.asperia@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hey Freedom,
>>>>>>>>>>
>>>>>>>>>> Wanted to run this by you before I filed a github issue.
>>>>>>>>>>
>>>>>>>>>> I have some FlaskViews that get registered at two different
>>>>>>>>>> subdomains.  Both views use the @route decorator to add some 
extra custom
>>>>>>>>>> methods.
>>>>>>>>>>
>>>>>>>>>> I appears that method routes declared with the decorator dont
>>>>>>>>>> honor the subdomain passed to the register function.  I can 
provide a test
>>>>>>>>>> case if needed.
>>>>>>>>>>
>>>>>>>>>> ~Mark
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> This is awesome. I'm just getting started with Flask coming from
>>>>>>>>>>> a Java world and was wondering how I can organize things 
better. This gets
>>>>>>>>>>> me started in the right direction.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <
>>>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> After receiving tons of feedback on the initial API and
>>>>>>>>>>>> functionality, and implementing almost all of it, I've 
finally released
>>>>>>>>>>>> version 0.5. I feel the API is really starting to mature and 
would love any
>>>>>>>>>>>> of you didn't think it was quite right before to give it 
another look and
>>>>>>>>>>>> tell me what you think now.
>>>>>>>>>>>>
>>>>>>>>>>>> 0.5 introduced some breaking changes, for anyone who has been
>>>>>>>>>>>> using it so far but they are fairly simple and honestly I 
think they make a
>>>>>>>>>>>> lot of sense. Take a look at the changelog for more 
information or feel
>>>>>>>>>>>> free to ask me directly.
>>>>>>>>>>>>
>>>>>>>>>>>> Also in there since the initial release is a new feature to
>>>>>>>>>>>> wrap views with custom before and after methods. That was the
first step
>>>>>>>>>>>> before providing a central context for view specific template
management,
>>>>>>>>>>>> but it's also extremely useful for all the other things 
response-wrapping
>>>>>>>>>>>> is good for.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks Flaskers for all the feedback so far. You've made
>>>>>>>>>>>> working on this project more rewarding than it would have 
been going it
>>>>>>>>>>>> alone.
>>>>>>>>>>>>
>>>>>>>>>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>>>>>>>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>>>>>>>>>
>>>>>>>>>>>> - Freedom
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Imran
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] Flask-Classy 0.5

From:
Joe Esposito
Date:
2012-11-21 @ 15:49
> *I loathe using 'as' in my imports*

Yeah, I don't love doing that either. I find that in practice, even with
general names like Request and View, the project is partitioned enough that
there aren't any name collisions.

It's very minor though, not all that annoying. I'll let you know if that
changes after using it more extensively =)

On Wed, Nov 21, 2012 at 9:02 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> Joe I totally agree about namespaces.
>
> I guess it's my own bias that I loathe using 'as' in my imports and I do
> avoid it when I can. Where do you personally rate the name FlaskView? Is it
> terrible or just kind of annoying?
>
> - Freedom
>
>
> On Tue, Nov 20, 2012 at 7:52 PM, Joe Esposito <espo58@gmail.com> wrote:
>
>> > *I added the link to the github repo .. **I'll be sure and get that
>> fixed asap*
>> Excellent =)
>>
>> > *but honestly I hate writing documentation, so I figured I'd do it in
>> a way that I could entertain myself a bit as I wrote and that got the job
>> done :)*
>> Hey, that's what's important. Whatever gets the job done!
>>
>>  > *I selected 'FlaskView' over just 'View' because in the application
>> that inspired the Flask-Classy extension the concept of a 'View' is quite
>> ambiguous*
>>
>> That's what namespaces are for though. The from flask.ext.classy gives
>> you enough disambiguation without needing to be explicit all over the
>> place. And if you did need that extra clarity, like when you're using two
>> different concepts of "view" in the same file, you can still write import
>> View as FlaskView.
>>
>> This is similar logic to why Flask exposes a Request class instead of
>> FlaskRequest, even though there are several meanings of the name "request
>> ". Actually, both Flask and Werkzeug expose their own Request class.
>> Flask even extends Werkzeug's 
class<https://github.com/mitsuhiko/flask/blob/master/flask/wrappers.py#L12>,
distinguishing
>> its own using like so: import Request as RequestBase.
>>
>> Namespaces via packages allows both simplicity and clarity.
>>
>> >  *if there were strong community support for a specific name, I
>> certainly wouldn't be opposed.*
>> Agreed. I could be alone on this. I'm just trying to provide some
>> counter-points =)
>>
>> > *I really appreciate your feedback and I'm looking forward to hearing
>> about your experiences when you start trying it out on your next project.
>> *
>> Thanks! And I'll ping you down the road when I do. Again, awesome work!
>>
>> On Tue, Nov 20, 2012 at 1:29 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>>
>>> Thanks Joe,
>>>
>>> I added the link to the github repo, should have done that a while ago!
>>> I used to have the 'fork me' banner but I must have left it out when I
>>> updated to using the table of contents, I'll be sure and get that fixed
>>> asap.
>>>
>>> I'm glad you liked the docs my writing style isn't for everyone, but
>>> honestly I hate writing documentation, so I figured I'd do it in a way that
>>> I could entertain myself a bit as I wrote and that got the job done :)
>>>
>>> I selected 'FlaskView' over just 'View' because in the application that
>>> inspired the Flask-Classy extension the concept of a 'View' is quite
>>> ambiguous. The Flask front end is only one part of a large application and
>>> it helped to distinguish that this was a 'View Class for Flask' as opposed
>>> to View classes that represent pre-computed database datasets or View
>>> classes that exist for supporting legacy integrations. I did consider other
>>> names for it, but I hate naming things and if I had kept it up we very well
>>> might have had it be called BaseFlaskClassyViewClassClass or something much
>>> worse. Luckily I stopped before things got out of hand.
>>>
>>> All that being said, if there were strong community support for a
>>> specific name, I certainly wouldn't be opposed.
>>>
>>> After I get the Template features in this weekend (I hope), I plan on
>>> trying to get a sample application written and documented, and then let the
>>> dust settle on the API for a bit to see how it feels for everyone
>>> (including those of us using it where I work.) Hopefully that will help to
>>> inspire those users that require some "see it in action" type of
>>> inspiration.
>>>
>>> I really appreciate your feedback and I'm looking forward to hearing
>>> about your experiences when you start trying it out on your next project.
>>>
>>> - Freedom
>>>
>>>
>>> On Tue, Nov 20, 2012 at 12:30 PM, Joe Esposito <espo58@gmail.com> wrote:
>>>
>>>> Finally had a chance to take a closer look. This looks great!
>>>> Most of the initial negative reactions when I introduce Flask are the
>>>> lack of class-based views. I'll now include this extension to ease the
>>>> doubts =)
>>>>
>>>> Some thoughts, if it's not too late:
>>>>
>>>>    - The Github repo should have a link at the top to
>>>>    http://packages.python.org/Flask-Classy/
>>>>    - Consider using a Fork me on Github 
ribbon<https://github.com/blog/273-github-ribbons>on that site. Should be 
as easy as possible to find the source code from
>>>>    the docs, and vice versa.
>>>>    - Speaking of the docs, I really enjoyed reading them!
>>>>    - Being an advocate of minimalism, is there a reason you didn't
>>>>    name the view class "View" instead of "FlaskView"?
>>>>    Is it that too many people would have name collisions? I think
>>>>    "View" is a less verbose default, and doing from flask.ext.classy
>>>>    import View as FlaskView as needed
>>>>
>>>> I also wonder if this will help with composability. I'd love to see a
>>>> large example site using class-based views with diverging functionality.
>>>> I'll try this out with my next Flask project and write about it if
>>>> there's anything worth adding.
>>>>
>>>> Good work!
>>>>
>>>> On Tue, Nov 20, 2012 at 11:23 AM, Freedom Dumlao <
>>>> freedomdumlao@gmail.com> wrote:
>>>>
>>>>> Awesome Mark. I'd love to hear about your experiences. We're working
>>>>> on backporting it into the codebase it was inspired from at work now as
>>>>> well. I'm almost done with the template related features, hopefully I'll
>>>>> get those out this weekend.
>>>>>
>>>>>
>>>>> On Tue, Nov 20, 2012 at 10:52 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>
>>>>>> No problem man.  I'm really liking this approach moreso than what I
>>>>>> had before with methodviews (esp since the register methodology for the
>>>>>> methodviews is about 5 lines in a dedicated function at the official docs,
>>>>>> a bit less sexy than a one line decorator)
>>>>>>
>>>>>> That was the last issue I could find refactoring our url structure to
>>>>>> use classy, so I feel more or less comfortable adopting this inside our
>>>>>> app.  It feel so much more elegant to have the views defined via their
>>>>>> corresponding program models (REST ftw) rather than wording them more
>>>>>> centered around the structure or confines of the HTTP protocol itself.
>>>>>>  After, HTTP is but one interface we may be exposing our services over.
>>>>>>
>>>>>> Pending approval from the bosses we'll actually be rolling this out
>>>>>> as-is in deployment.
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 20, 2012 at 1:31 AM, Freedom Dumlao <
>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>
>>>>>>> Mark,
>>>>>>>
>>>>>>> I've got a fix for that issue as well as extending the tests to
>>>>>>> cover that case. It's in version 0.5.1.
>>>>>>>
>>>>>>> Thanks for the excellent write upon the issue, it made it much
>>>>>>> easier to track down than it would have been otherwise.
>>>>>>>
>>>>>>> - Freedom
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 19, 2012 at 12:19 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>>>
>>>>>>>> Didn't have the chance to test it prior, though I suppose I could
>>>>>>>> spin up a virtualenv with an older version to see.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <
>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Thanks Mark.
>>>>>>>>>
>>>>>>>>> Please go ahead and file an issue on github, and if you've got a
>>>>>>>>> test case I'll gladly accept it. Was this working before 0.5 release?
>>>>>>>>>
>>>>>>>>> - Freedom
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <
>>>>>>>>> mark.asperia@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hey Freedom,
>>>>>>>>>>
>>>>>>>>>> Wanted to run this by you before I filed a github issue.
>>>>>>>>>>
>>>>>>>>>> I have some FlaskViews that get registered at two different
>>>>>>>>>> subdomains.  Both views use the @route decorator to add some 
extra custom
>>>>>>>>>> methods.
>>>>>>>>>>
>>>>>>>>>> I appears that method routes declared with the decorator dont
>>>>>>>>>> honor the subdomain passed to the register function.  I can 
provide a test
>>>>>>>>>> case if needed.
>>>>>>>>>>
>>>>>>>>>> ~Mark
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> This is awesome. I'm just getting started with Flask coming from
>>>>>>>>>>> a Java world and was wondering how I can organize things 
better. This gets
>>>>>>>>>>> me started in the right direction.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <
>>>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> After receiving tons of feedback on the initial API and
>>>>>>>>>>>> functionality, and implementing almost all of it, I've 
finally released
>>>>>>>>>>>> version 0.5. I feel the API is really starting to mature and 
would love any
>>>>>>>>>>>> of you didn't think it was quite right before to give it 
another look and
>>>>>>>>>>>> tell me what you think now.
>>>>>>>>>>>>
>>>>>>>>>>>> 0.5 introduced some breaking changes, for anyone who has been
>>>>>>>>>>>> using it so far but they are fairly simple and honestly I 
think they make a
>>>>>>>>>>>> lot of sense. Take a look at the changelog for more 
information or feel
>>>>>>>>>>>> free to ask me directly.
>>>>>>>>>>>>
>>>>>>>>>>>> Also in there since the initial release is a new feature to
>>>>>>>>>>>> wrap views with custom before and after methods. That was the
first step
>>>>>>>>>>>> before providing a central context for view specific template
management,
>>>>>>>>>>>> but it's also extremely useful for all the other things 
response-wrapping
>>>>>>>>>>>> is good for.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks Flaskers for all the feedback so far. You've made
>>>>>>>>>>>> working on this project more rewarding than it would have 
been going it
>>>>>>>>>>>> alone.
>>>>>>>>>>>>
>>>>>>>>>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>>>>>>>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>>>>>>>>>
>>>>>>>>>>>> - Freedom
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Imran
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] Flask-Classy 0.5

From:
Sina K
Date:
2012-11-21 @ 01:26
my newbie two cents:

- I definitely "get it" much faster than blueprints - means clear docs 
and simple structure
- I vote for ClassyView instead of FlaskView

Looks great, I am looking forward to integrating it into my project.

Cheers,
Sina
> Joe Esposito <mailto:espo58@gmail.com>
> November 21, 2012 1:52 AM
> > /I added the link to the github repo .. //I'll be sure and get that 
> fixed asap/
> Excellent =)
>
> > /but honestly I hate writing documentation, so I figured I'd do it 
> in a way that I could entertain myself a bit as I wrote and that got 
> the job done :)/
> Hey, that's what's important. Whatever gets the job done!
>
> > /I selected 'FlaskView' over just 'View' because in the application 
> that inspired the Flask-Classy extension the concept of a 'View' is 
> quite ambiguous/
>
> That's what namespaces are for though. The from flask.ext.classy gives 
> you enough disambiguation without needing to be explicit all over the 
> place. And if you did need that extra clarity, like when you're using 
> two different concepts of "view" in the same file, you can still write 
> import View as FlaskView.
>
> This is similar logic to why Flask exposes a Request class instead of 
> FlaskRequest, even though there are several meanings of the 
> name "request". Actually, both Flask and Werkzeug expose their own 
> Request class. Flask even extends Werkzeug's class 
> <https://github.com/mitsuhiko/flask/blob/master/flask/wrappers.py#L12>, 
distinguishing 
> its own using like so: import Request as RequestBase.
>
> Namespaces via packages allows both simplicity and clarity.
>
> > /if there were strong community support for a specific name, I 
> certainly wouldn't be opposed./
> Agreed. I could be alone on this. I'm just trying to provide some 
> counter-points =)
>
> > /I really appreciate your feedback and I'm looking forward to 
> hearing about your experiences when you start trying it out on your 
> next project./
> Thanks! And I'll ping you down the road when I do. Again, awesome work!
>
>
> Freedom Dumlao <mailto:freedomdumlao@gmail.com>
> November 20, 2012 7:29 PM
> Thanks Joe,
>
> I added the link to the github repo, should have done that a while 
> ago! I used to have the 'fork me' banner but I must have left it out 
> when I updated to using the table of contents, I'll be sure and get 
> that fixed asap.
>
> I'm glad you liked the docs my writing style isn't for everyone, but 
> honestly I hate writing documentation, so I figured I'd do it in a way 
> that I could entertain myself a bit as I wrote and that got the job 
> done :)
>
> I selected 'FlaskView' over just 'View' because in the application 
> that inspired the Flask-Classy extension the concept of a 'View' is 
> quite ambiguous. The Flask front end is only one part of a large 
> application and it helped to distinguish that this was a 'View Class 
> for Flask' as opposed to View classes that represent pre-computed 
> database datasets or View classes that exist for supporting legacy 
> integrations. I did consider other names for it, but I hate naming 
> things and if I had kept it up we very well might have had it be 
> called BaseFlaskClassyViewClassClass or something much worse. Luckily 
> I stopped before things got out of hand.
>
> All that being said, if there were strong community support for a 
> specific name, I certainly wouldn't be opposed.
>
> After I get the Template features in this weekend (I hope), I plan on 
> trying to get a sample application written and documented, and then 
> let the dust settle on the API for a bit to see how it feels for 
> everyone (including those of us using it where I work.) Hopefully that 
> will help to inspire those users that require some "see it in action" 
> type of inspiration.
>
> I really appreciate your feedback and I'm looking forward to hearing 
> about your experiences when you start trying it out on your next project.
>
> - Freedom
>
>
>
> Joe Esposito <mailto:espo58@gmail.com>
> November 20, 2012 6:30 PM
> Finally had a chance to take a closer look. This looks great!
> Most of the initial negative reactions when I introduce Flask are the 
> lack of class-based views. I'll now include this extension to ease the 
> doubts =)
>
> Some thoughts, if it's not too late:
>
>   * The Github repo should have a link at the top to
>     http://packages.python.org/Flask-Classy/
>   * Consider using a Fork me on Github ribbon
>     <https://github.com/blog/273-github-ribbons> on that site. Should
>     be as easy as possible to find the source code from the docs, and
>     vice versa.
>   * Speaking of the docs, I really enjoyed reading them!
>   * Being an advocate of minimalism, is there a reason you didn't name
>     the view class "View" instead of "FlaskView"?
>     Is it that too many people would have name collisions? I think
>     "View" is a less verbose default, and doing from flask.ext.classy
>     import View as FlaskView as needed
>
> I also wonder if this will help with composability. I'd love to see a 
> large example site using class-based views with diverging functionality.
> I'll try this out with my next Flask project and write about it if 
> there's anything worth adding.
>
> Good work!
>
>
> Freedom Dumlao <mailto:freedomdumlao@gmail.com>
> November 20, 2012 5:23 PM
> Awesome Mark. I'd love to hear about your experiences. We're working 
> on backporting it into the codebase it was inspired from at work now 
> as well. I'm almost done with the template related features, hopefully 
> I'll get those out this weekend.
>
>
>
> Mark Grey <mailto:mark.asperia@gmail.com>
> November 20, 2012 4:52 PM
> No problem man.  I'm really liking this approach moreso than what I 
> had before with methodviews (esp since the register methodology for 
> the methodviews is about 5 lines in a dedicated function at the 
> official docs, a bit less sexy than a one line decorator)
>
> That was the last issue I could find refactoring our url structure to 
> use classy, so I feel more or less comfortable adopting this inside 
> our app.  It feel so much more elegant to have the views defined via 
> their corresponding program models (REST ftw) rather than wording them 
> more centered around the structure or confines of the HTTP protocol 
> itself.  After, HTTP is but one interface we may be exposing our 
> services over.
>
> Pending approval from the bosses we'll actually be rolling this out 
> as-is in deployment.
>
>

Re: [flask] Flask-Classy 0.5

From:
Col Wilson
Date:
2012-11-21 @ 08:14
I'm getting 404s from the example code
https://gist.github.com/34a86965ca05700e9d02 for get and random?



On Wed, Nov 21, 2012 at 1:26 AM, Sina K <sina@sagitar.com> wrote:

>
> my newbie two cents:
>
> - I definitely "get it" much faster than blueprints - means clear docs and
> simple structure
> - I vote for ClassyView instead of FlaskView
>
> Looks great, I am looking forward to integrating it into my project.
>
> Cheers,
> Sina
>
>   Joe Esposito <espo58@gmail.com>
>  November 21, 2012 1:52 AM
> > *I added the link to the github repo .. **I'll be sure and get that
> fixed asap*
> Excellent =)
>
> > *but honestly I hate writing documentation, so I figured I'd do it in a
> way that I could entertain myself a bit as I wrote and that got the job
> done :)*
> Hey, that's what's important. Whatever gets the job done!
>
> > *I selected 'FlaskView' over just 'View' because in the application
> that inspired the Flask-Classy extension the concept of a 'View' is quite
> ambiguous*
>
> That's what namespaces are for though. The from flask.ext.classy gives
> you enough disambiguation without needing to be explicit all over the
> place. And if you did need that extra clarity, like when you're using two
> different concepts of "view" in the same file, you can still write import
> View as FlaskView.
>
> This is similar logic to why Flask exposes a Request class instead of
> FlaskRequest, even though there are several meanings of the name "request".
> Actually, both Flask and Werkzeug expose their own Request class. Flask even
> extends Werkzeug's 
class<https://github.com/mitsuhiko/flask/blob/master/flask/wrappers.py#L12>,
distinguishing
> its own using like so: import Request as RequestBase.
>
> Namespaces via packages allows both simplicity and clarity.
>
> >  *if there were strong community support for a specific name, I
> certainly wouldn't be opposed.*
> Agreed. I could be alone on this. I'm just trying to provide some
> counter-points =)
>
> > *I really appreciate your feedback and I'm looking forward to hearing
> about your experiences when you start trying it out on your next project.*
> Thanks! And I'll ping you down the road when I do. Again, awesome work!
>
>
>   Freedom Dumlao <freedomdumlao@gmail.com>
>  November 20, 2012 7:29 PM
> Thanks Joe,
>
> I added the link to the github repo, should have done that a while ago! I
> used to have the 'fork me' banner but I must have left it out when I
> updated to using the table of contents, I'll be sure and get that fixed
> asap.
>
> I'm glad you liked the docs my writing style isn't for everyone, but
> honestly I hate writing documentation, so I figured I'd do it in a way that
> I could entertain myself a bit as I wrote and that got the job done :)
>
> I selected 'FlaskView' over just 'View' because in the application that
> inspired the Flask-Classy extension the concept of a 'View' is quite
> ambiguous. The Flask front end is only one part of a large application and
> it helped to distinguish that this was a 'View Class for Flask' as opposed
> to View classes that represent pre-computed database datasets or View
> classes that exist for supporting legacy integrations. I did consider other
> names for it, but I hate naming things and if I had kept it up we very well
> might have had it be called BaseFlaskClassyViewClassClass or something much
> worse. Luckily I stopped before things got out of hand.
>
> All that being said, if there were strong community support for a specific
> name, I certainly wouldn't be opposed.
>
> After I get the Template features in this weekend (I hope), I plan on
> trying to get a sample application written and documented, and then let the
> dust settle on the API for a bit to see how it feels for everyone
> (including those of us using it where I work.) Hopefully that will help to
> inspire those users that require some "see it in action" type of
> inspiration.
>
> I really appreciate your feedback and I'm looking forward to hearing about
> your experiences when you start trying it out on your next project.
>
> - Freedom
>
>
>
>   Joe Esposito <espo58@gmail.com>
>  November 20, 2012 6:30 PM
> Finally had a chance to take a closer look. This looks great!
> Most of the initial negative reactions when I introduce Flask are the lack
> of class-based views. I'll now include this extension to ease the doubts =)
>
> Some thoughts, if it's not too late:
>
>    - The Github repo should have a link at the top to
>    http://packages.python.org/Flask-Classy/
>    - Consider using a Fork me on Github 
ribbon<https://github.com/blog/273-github-ribbons>on that site. Should be 
as easy as possible to find the source code from
>    the docs, and vice versa.
>    - Speaking of the docs, I really enjoyed reading them!
>    - Being an advocate of minimalism, is there a reason you didn't name
>    the view class "View" instead of "FlaskView"?
>    Is it that too many people would have name collisions? I think "View"
>    is a less verbose default, and doing from flask.ext.classy import View
>    as FlaskView as needed
>
> I also wonder if this will help with composability. I'd love to see a
> large example site using class-based views with diverging functionality.
> I'll try this out with my next Flask project and write about it if there's
> anything worth adding.
>
> Good work!
>
>
>    Freedom Dumlao <freedomdumlao@gmail.com>
>  November 20, 2012 5:23 PM
> Awesome Mark. I'd love to hear about your experiences. We're working on
> backporting it into the codebase it was inspired from at work now as well.
> I'm almost done with the template related features, hopefully I'll get
> those out this weekend.
>
>
>
>   Mark Grey <mark.asperia@gmail.com>
>  November 20, 2012 4:52 PM
> No problem man.  I'm really liking this approach moreso than what I had
> before with methodviews (esp since the register methodology for the
> methodviews is about 5 lines in a dedicated function at the official docs,
> a bit less sexy than a one line decorator)
>
> That was the last issue I could find refactoring our url structure to use
> classy, so I feel more or less comfortable adopting this inside our app.
>  It feel so much more elegant to have the views defined via their
> corresponding program models (REST ftw) rather than wording them more
> centered around the structure or confines of the HTTP protocol itself.
>  After, HTTP is but one interface we may be exposing our services over.
>
> Pending approval from the bosses we'll actually be rolling this out as-is
> in deployment.
>
>
>


-- 
Col Wilson

http://flask-ahoy.com | http://django-ahoy.com |
http://real-jobs.appspot.com | http://terse-words.blogspot.com

Re: [flask] Flask-Classy 0.5

From:
Freedom Dumlao
Date:
2012-11-21 @ 13:54
Hey Col,

Make sure you don't forget the 'quotes' part of the url. At that part of
the tutorial we havent made the QuotesView handle the root of the domain
yet. Try these:

http://127.0.0.1:5000/quotes/
http://127.0.0.1:5000/quotes/random/

It worked fine when I copied your gist over here. Let me know if it still
doesn't work for you :)

- Freedom


On Wed, Nov 21, 2012 at 3:14 AM, Col Wilson <colwilson@bcs.org> wrote:

> I'm getting 404s from the example code
> https://gist.github.com/34a86965ca05700e9d02 for get and random?
>
>
>
> On Wed, Nov 21, 2012 at 1:26 AM, Sina K <sina@sagitar.com> wrote:
>
>>
>> my newbie two cents:
>>
>> - I definitely "get it" much faster than blueprints - means clear docs
>> and simple structure
>> - I vote for ClassyView instead of FlaskView
>>
>> Looks great, I am looking forward to integrating it into my project.
>>
>> Cheers,
>> Sina
>>
>>   Joe Esposito <espo58@gmail.com>
>>  November 21, 2012 1:52 AM
>> > *I added the link to the github repo .. **I'll be sure and get that
>> fixed asap*
>> Excellent =)
>>
>> > *but honestly I hate writing documentation, so I figured I'd do it in
>> a way that I could entertain myself a bit as I wrote and that got the job
>> done :)*
>> Hey, that's what's important. Whatever gets the job done!
>>
>> > *I selected 'FlaskView' over just 'View' because in the application
>> that inspired the Flask-Classy extension the concept of a 'View' is quite
>> ambiguous*
>>
>> That's what namespaces are for though. The from flask.ext.classy gives
>> you enough disambiguation without needing to be explicit all over the
>> place. And if you did need that extra clarity, like when you're using two
>> different concepts of "view" in the same file, you can still write import
>> View as FlaskView.
>>
>> This is similar logic to why Flask exposes a Request class instead of
>> FlaskRequest, even though there are several meanings of the name "request
>> ". Actually, both Flask and Werkzeug expose their own Request class.
>> Flask even extends Werkzeug's 
class<https://github.com/mitsuhiko/flask/blob/master/flask/wrappers.py#L12>,
distinguishing
>> its own using like so: import Request as RequestBase.
>>
>> Namespaces via packages allows both simplicity and clarity.
>>
>> >  *if there were strong community support for a specific name, I
>> certainly wouldn't be opposed.*
>> Agreed. I could be alone on this. I'm just trying to provide some
>> counter-points =)
>>
>> > *I really appreciate your feedback and I'm looking forward to hearing
>> about your experiences when you start trying it out on your next project.
>> *
>> Thanks! And I'll ping you down the road when I do. Again, awesome work!
>>
>>
>>   Freedom Dumlao <freedomdumlao@gmail.com>
>>  November 20, 2012 7:29 PM
>> Thanks Joe,
>>
>> I added the link to the github repo, should have done that a while ago! I
>> used to have the 'fork me' banner but I must have left it out when I
>> updated to using the table of contents, I'll be sure and get that fixed
>> asap.
>>
>> I'm glad you liked the docs my writing style isn't for everyone, but
>> honestly I hate writing documentation, so I figured I'd do it in a way that
>> I could entertain myself a bit as I wrote and that got the job done :)
>>
>> I selected 'FlaskView' over just 'View' because in the application that
>> inspired the Flask-Classy extension the concept of a 'View' is quite
>> ambiguous. The Flask front end is only one part of a large application and
>> it helped to distinguish that this was a 'View Class for Flask' as opposed
>> to View classes that represent pre-computed database datasets or View
>> classes that exist for supporting legacy integrations. I did consider other
>> names for it, but I hate naming things and if I had kept it up we very well
>> might have had it be called BaseFlaskClassyViewClassClass or something much
>> worse. Luckily I stopped before things got out of hand.
>>
>> All that being said, if there were strong community support for a
>> specific name, I certainly wouldn't be opposed.
>>
>> After I get the Template features in this weekend (I hope), I plan on
>> trying to get a sample application written and documented, and then let the
>> dust settle on the API for a bit to see how it feels for everyone
>> (including those of us using it where I work.) Hopefully that will help to
>> inspire those users that require some "see it in action" type of
>> inspiration.
>>
>> I really appreciate your feedback and I'm looking forward to hearing
>> about your experiences when you start trying it out on your next project.
>>
>> - Freedom
>>
>>
>>
>>   Joe Esposito <espo58@gmail.com>
>>  November 20, 2012 6:30 PM
>> Finally had a chance to take a closer look. This looks great!
>> Most of the initial negative reactions when I introduce Flask are the
>> lack of class-based views. I'll now include this extension to ease the
>> doubts =)
>>
>> Some thoughts, if it's not too late:
>>
>>    - The Github repo should have a link at the top to
>>    http://packages.python.org/Flask-Classy/
>>    - Consider using a Fork me on Github 
ribbon<https://github.com/blog/273-github-ribbons>on that site. Should be 
as easy as possible to find the source code from
>>    the docs, and vice versa.
>>    - Speaking of the docs, I really enjoyed reading them!
>>    - Being an advocate of minimalism, is there a reason you didn't name
>>    the view class "View" instead of "FlaskView"?
>>    Is it that too many people would have name collisions? I think "View"
>>    is a less verbose default, and doing from flask.ext.classy import
>>    View as FlaskView as needed
>>
>> I also wonder if this will help with composability. I'd love to see a
>> large example site using class-based views with diverging functionality.
>> I'll try this out with my next Flask project and write about it if
>> there's anything worth adding.
>>
>> Good work!
>>
>>
>>     Freedom Dumlao <freedomdumlao@gmail.com>
>>  November 20, 2012 5:23 PM
>> Awesome Mark. I'd love to hear about your experiences. We're working on
>> backporting it into the codebase it was inspired from at work now as well.
>> I'm almost done with the template related features, hopefully I'll get
>> those out this weekend.
>>
>>
>>
>>    Mark Grey <mark.asperia@gmail.com>
>>  November 20, 2012 4:52 PM
>> No problem man.  I'm really liking this approach moreso than what I had
>> before with methodviews (esp since the register methodology for the
>> methodviews is about 5 lines in a dedicated function at the official docs,
>> a bit less sexy than a one line decorator)
>>
>> That was the last issue I could find refactoring our url structure to use
>> classy, so I feel more or less comfortable adopting this inside our app.
>>  It feel so much more elegant to have the views defined via their
>> corresponding program models (REST ftw) rather than wording them more
>> centered around the structure or confines of the HTTP protocol itself.
>>  After, HTTP is but one interface we may be exposing our services over.
>>
>> Pending approval from the bosses we'll actually be rolling this out as-is
>> in deployment.
>>
>>
>>
>
>
> --
> Col Wilson
>
> http://flask-ahoy.com | http://django-ahoy.com |
> http://real-jobs.appspot.com | http://terse-words.blogspot.com
>

Re: [flask] Flask-Classy 0.5

From:
Col Wilson
Date:
2012-11-21 @ 13:59
yes that works, it was late last night perhaps. thanks.


On Wed, Nov 21, 2012 at 1:54 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> Hey Col,
>
> Make sure you don't forget the 'quotes' part of the url. At that part of
> the tutorial we havent made the QuotesView handle the root of the domain
> yet. Try these:
>
> http://127.0.0.1:5000/quotes/
> http://127.0.0.1:5000/quotes/random/
>
> It worked fine when I copied your gist over here. Let me know if it still
> doesn't work for you :)
>
> - Freedom
>
>
> On Wed, Nov 21, 2012 at 3:14 AM, Col Wilson <colwilson@bcs.org> wrote:
>
>> I'm getting 404s from the example code
>> https://gist.github.com/34a86965ca05700e9d02 for get and random?
>>
>>
>>
>> On Wed, Nov 21, 2012 at 1:26 AM, Sina K <sina@sagitar.com> wrote:
>>
>>>
>>> my newbie two cents:
>>>
>>> - I definitely "get it" much faster than blueprints - means clear docs
>>> and simple structure
>>> - I vote for ClassyView instead of FlaskView
>>>
>>> Looks great, I am looking forward to integrating it into my project.
>>>
>>> Cheers,
>>> Sina
>>>
>>>   Joe Esposito <espo58@gmail.com>
>>>  November 21, 2012 1:52 AM
>>> > *I added the link to the github repo .. **I'll be sure and get that
>>> fixed asap*
>>> Excellent =)
>>>
>>> > *but honestly I hate writing documentation, so I figured I'd do it in
>>> a way that I could entertain myself a bit as I wrote and that got the job
>>> done :)*
>>> Hey, that's what's important. Whatever gets the job done!
>>>
>>> > *I selected 'FlaskView' over just 'View' because in the application
>>> that inspired the Flask-Classy extension the concept of a 'View' is quite
>>> ambiguous*
>>>
>>> That's what namespaces are for though. The from flask.ext.classy gives
>>> you enough disambiguation without needing to be explicit all over the
>>> place. And if you did need that extra clarity, like when you're using two
>>> different concepts of "view" in the same file, you can still write import
>>> View as FlaskView.
>>>
>>> This is similar logic to why Flask exposes a Request class instead of
>>> FlaskRequest, even though there are several meanings of the name "
>>> request". Actually, both Flask and Werkzeug expose their own Request
>>>  class. Flask even extends Werkzeug's 
class<https://github.com/mitsuhiko/flask/blob/master/flask/wrappers.py#L12>,
distinguishing
>>> its own using like so: import Request as RequestBase.
>>>
>>> Namespaces via packages allows both simplicity and clarity.
>>>
>>> >  *if there were strong community support for a specific name, I
>>> certainly wouldn't be opposed.*
>>> Agreed. I could be alone on this. I'm just trying to provide some
>>> counter-points =)
>>>
>>> > *I really appreciate your feedback and I'm looking forward to hearing
>>> about your experiences when you start trying it out on your next project.
>>> *
>>> Thanks! And I'll ping you down the road when I do. Again, awesome work!
>>>
>>>
>>>   Freedom Dumlao <freedomdumlao@gmail.com>
>>>  November 20, 2012 7:29 PM
>>> Thanks Joe,
>>>
>>> I added the link to the github repo, should have done that a while ago!
>>> I used to have the 'fork me' banner but I must have left it out when I
>>> updated to using the table of contents, I'll be sure and get that fixed
>>> asap.
>>>
>>> I'm glad you liked the docs my writing style isn't for everyone, but
>>> honestly I hate writing documentation, so I figured I'd do it in a way that
>>> I could entertain myself a bit as I wrote and that got the job done :)
>>>
>>> I selected 'FlaskView' over just 'View' because in the application that
>>> inspired the Flask-Classy extension the concept of a 'View' is quite
>>> ambiguous. The Flask front end is only one part of a large application and
>>> it helped to distinguish that this was a 'View Class for Flask' as opposed
>>> to View classes that represent pre-computed database datasets or View
>>> classes that exist for supporting legacy integrations. I did consider other
>>> names for it, but I hate naming things and if I had kept it up we very well
>>> might have had it be called BaseFlaskClassyViewClassClass or something much
>>> worse. Luckily I stopped before things got out of hand.
>>>
>>> All that being said, if there were strong community support for a
>>> specific name, I certainly wouldn't be opposed.
>>>
>>> After I get the Template features in this weekend (I hope), I plan on
>>> trying to get a sample application written and documented, and then let the
>>> dust settle on the API for a bit to see how it feels for everyone
>>> (including those of us using it where I work.) Hopefully that will help to
>>> inspire those users that require some "see it in action" type of
>>> inspiration.
>>>
>>> I really appreciate your feedback and I'm looking forward to hearing
>>> about your experiences when you start trying it out on your next project.
>>>
>>> - Freedom
>>>
>>>
>>>
>>>   Joe Esposito <espo58@gmail.com>
>>>  November 20, 2012 6:30 PM
>>> Finally had a chance to take a closer look. This looks great!
>>> Most of the initial negative reactions when I introduce Flask are the
>>> lack of class-based views. I'll now include this extension to ease the
>>> doubts =)
>>>
>>> Some thoughts, if it's not too late:
>>>
>>>    - The Github repo should have a link at the top to
>>>    http://packages.python.org/Flask-Classy/
>>>    - Consider using a Fork me on Github 
ribbon<https://github.com/blog/273-github-ribbons>on that site. Should be 
as easy as possible to find the source code from
>>>    the docs, and vice versa.
>>>    - Speaking of the docs, I really enjoyed reading them!
>>>    - Being an advocate of minimalism, is there a reason you didn't name
>>>    the view class "View" instead of "FlaskView"?
>>>    Is it that too many people would have name collisions? I think
>>>    "View" is a less verbose default, and doing from flask.ext.classy
>>>    import View as FlaskView as needed
>>>
>>> I also wonder if this will help with composability. I'd love to see a
>>> large example site using class-based views with diverging functionality.
>>> I'll try this out with my next Flask project and write about it if
>>> there's anything worth adding.
>>>
>>> Good work!
>>>
>>>
>>>     Freedom Dumlao <freedomdumlao@gmail.com>
>>>  November 20, 2012 5:23 PM
>>> Awesome Mark. I'd love to hear about your experiences. We're working on
>>> backporting it into the codebase it was inspired from at work now as well.
>>> I'm almost done with the template related features, hopefully I'll get
>>> those out this weekend.
>>>
>>>
>>>
>>>    Mark Grey <mark.asperia@gmail.com>
>>>  November 20, 2012 4:52 PM
>>> No problem man.  I'm really liking this approach moreso than what I had
>>> before with methodviews (esp since the register methodology for the
>>> methodviews is about 5 lines in a dedicated function at the official docs,
>>> a bit less sexy than a one line decorator)
>>>
>>> That was the last issue I could find refactoring our url structure to
>>> use classy, so I feel more or less comfortable adopting this inside our
>>> app.  It feel so much more elegant to have the views defined via their
>>> corresponding program models (REST ftw) rather than wording them more
>>> centered around the structure or confines of the HTTP protocol itself.
>>>  After, HTTP is but one interface we may be exposing our services over.
>>>
>>> Pending approval from the bosses we'll actually be rolling this out
>>> as-is in deployment.
>>>
>>>
>>>
>>
>>
>> --
>> Col Wilson
>>
>> http://flask-ahoy.com | http://django-ahoy.com |
>> http://real-jobs.appspot.com | http://terse-words.blogspot.com
>>
>
>


-- 
Col Wilson

http://flask-ahoy.com | http://django-ahoy.com |
http://real-jobs.appspot.com | http://terse-words.blogspot.com

Re: [flask] Flask-Classy 0.5

From:
Freedom Dumlao
Date:
2012-11-21 @ 13:57
could not decode message

Re: [flask] Flask-Classy 0.5

From:
Ben Hughes
Date:
2012-11-19 @ 20:16
Quality work Freedom - well done on an awesome extension - it seems you've
filled a gap in people's brains :)




On Mon, Nov 19, 2012 at 5:19 PM, Mark Grey <mark.asperia@gmail.com> wrote:

> Didn't have the chance to test it prior, though I suppose I could spin up
> a virtualenv with an older version to see.
>
>
> On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>
>> Thanks Mark.
>>
>> Please go ahead and file an issue on github, and if you've got a test
>> case I'll gladly accept it. Was this working before 0.5 release?
>>
>> - Freedom
>>
>>
>> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>
>>> Hey Freedom,
>>>
>>> Wanted to run this by you before I filed a github issue.
>>>
>>> I have some FlaskViews that get registered at two different subdomains.
>>>  Both views use the @route decorator to add some extra custom methods.
>>>
>>> I appears that method routes declared with the decorator dont honor the
>>> subdomain passed to the register function.  I can provide a test case if
>>> needed.
>>>
>>> ~Mark
>>>
>>>
>>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com>wrote:
>>>
>>>> This is awesome. I'm just getting started with Flask coming from a Java
>>>> world and was wondering how I can organize things better. This gets me
>>>> started in the right direction.
>>>>
>>>>
>>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <
>>>> freedomdumlao@gmail.com> wrote:
>>>>
>>>>> After receiving tons of feedback on the initial API and functionality,
>>>>> and implementing almost all of it, I've finally released version 0.5. I
>>>>> feel the API is really starting to mature and would love any of you didn't
>>>>> think it was quite right before to give it another look and tell me what
>>>>> you think now.
>>>>>
>>>>> 0.5 introduced some breaking changes, for anyone who has been using it
>>>>> so far but they are fairly simple and honestly I think they make a lot of
>>>>> sense. Take a look at the changelog for more information or feel free to
>>>>> ask me directly.
>>>>>
>>>>> Also in there since the initial release is a new feature to wrap views
>>>>> with custom before and after methods. That was the first step before
>>>>> providing a central context for view specific template management, but it's
>>>>> also extremely useful for all the other things response-wrapping is good
>>>>> for.
>>>>>
>>>>> Thanks Flaskers for all the feedback so far. You've made working on
>>>>> this project more rewarding than it would have been going it alone.
>>>>>
>>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>>
>>>>> - Freedom
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Imran
>>>>
>>>
>>>
>>
>


-- 
Ben Hughes
Change & Innovation Lead
Bright Approach Ltd.
Tel: +447427600266
Twitter: @bwghughes
http://about.me/bwghughes

Re: [flask] Flask-Classy 0.5

From:
Freedom Dumlao
Date:
2012-11-19 @ 21:18
Thanks Ben! I appreciate the feedback very much.


On Mon, Nov 19, 2012 at 3:16 PM, Ben Hughes <bwghughes@gmail.com> wrote:

> Quality work Freedom - well done on an awesome extension - it seems you've
> filled a gap in people's brains :)
>
>
>
>
> On Mon, Nov 19, 2012 at 5:19 PM, Mark Grey <mark.asperia@gmail.com> wrote:
>
>> Didn't have the chance to test it prior, though I suppose I could spin up
>> a virtualenv with an older version to see.
>>
>>
>> On Mon, Nov 19, 2012 at 12:13 PM, Freedom Dumlao <freedomdumlao@gmail.com
>> > wrote:
>>
>>> Thanks Mark.
>>>
>>> Please go ahead and file an issue on github, and if you've got a test
>>> case I'll gladly accept it. Was this working before 0.5 release?
>>>
>>> - Freedom
>>>
>>>
>>> On Mon, Nov 19, 2012 at 12:00 PM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>
>>>> Hey Freedom,
>>>>
>>>> Wanted to run this by you before I filed a github issue.
>>>>
>>>> I have some FlaskViews that get registered at two different subdomains.
>>>>  Both views use the @route decorator to add some extra custom methods.
>>>>
>>>> I appears that method routes declared with the decorator dont honor the
>>>> subdomain passed to the register function.  I can provide a test case if
>>>> needed.
>>>>
>>>> ~Mark
>>>>
>>>>
>>>> On Mon, Nov 19, 2012 at 9:47 AM, Imran Khawaja <imrank1@gmail.com>wrote:
>>>>
>>>>> This is awesome. I'm just getting started with Flask coming from a
>>>>> Java world and was wondering how I can organize things better. This gets me
>>>>> started in the right direction.
>>>>>
>>>>>
>>>>> On Mon, Nov 19, 2012 at 9:03 AM, Freedom Dumlao <
>>>>> freedomdumlao@gmail.com> wrote:
>>>>>
>>>>>> After receiving tons of feedback on the initial API and
>>>>>> functionality, and implementing almost all of it, I've finally released
>>>>>> version 0.5. I feel the API is really starting to mature and would love any
>>>>>> of you didn't think it was quite right before to give it another look and
>>>>>> tell me what you think now.
>>>>>>
>>>>>> 0.5 introduced some breaking changes, for anyone who has been using
>>>>>> it so far but they are fairly simple and honestly I think they make a lot
>>>>>> of sense. Take a look at the changelog for more information or feel free to
>>>>>> ask me directly.
>>>>>>
>>>>>> Also in there since the initial release is a new feature to wrap
>>>>>> views with custom before and after methods. That was the first step before
>>>>>> providing a central context for view specific template management, but it's
>>>>>> also extremely useful for all the other things response-wrapping is good
>>>>>> for.
>>>>>>
>>>>>> Thanks Flaskers for all the feedback so far. You've made working on
>>>>>> this project more rewarding than it would have been going it alone.
>>>>>>
>>>>>> Check it out here: http://packages.python.org/Flask-Classy/
>>>>>> And the github repo: https://github.com/apiguy/flask-classy
>>>>>>
>>>>>> - Freedom
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Imran
>>>>>
>>>>
>>>>
>>>
>>
>
>
> --
> Ben Hughes
> Change & Innovation Lead
> Bright Approach Ltd.
> Tel: +447427600266
> Twitter: @bwghughes
> http://about.me/bwghughes
>
>
>