librelist archives

« back to archive

An alternative approach to class based views

An alternative approach to class based views

From:
Freedom Dumlao
Date:
2012-10-31 @ 16:27
Hey Flaskers,

At the day job I came up with a class based views solution to meet some of
the needs of our application.
I recently started a side project where I wanted to use the same thing and
thought it might be time to start
extracting the functionality into a Flask extension others might find
useful too.

It takes a somewhat different approach to class based views than what you
find in the flask.views namespace
so I'd really appreciate any feedback on the API and features. There are a
couple of features I havent
extracted yet, specifically view wrapping, and template contexts, but I'll
be getting to them pretty soon.

Take a look here: http://packages.python.org/Flask-Classy/

I look forward to hearing what you think.

- Freedom

Re: [flask] An alternative approach to class based views

From:
Serge S. Koval
Date:
2012-10-31 @ 17:01
That's pretty much how Flask-Admin works - all functionality it embedded
into reusable classes with views. Blueprint is created behind the scenes,
so it is possible to use get_url('.another_view') in class-based views.

Serge.

On Wed, Oct 31, 2012 at 6:27 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> Hey Flaskers,
>
> At the day job I came up with a class based views solution to meet some of
> the needs of our application.
>

Re: [flask] An alternative approach to class based views

From:
Igor Davydenko
Date:
2012-10-31 @ 17:41
Looks very promising for me, will try in one of my current projects.

Only a quick question, has Flask-Classy an ability to register views
lazy way, without View.register call?

I mean, I like to use lazy views pattern (
http://flask.pocoo.org/docs/patterns/lazyloading/,
http://pypi.python.org/pypi/Flask-LazyViews ) and place my views to
``views`` module or package. But from first view in ``Flask-Classy`` I
only can add url rules with explicitly View.register call, which means
I need to import this class to application, which I don't really like.

On 31 October 2012 18:27, Freedom Dumlao <freedomdumlao@gmail.com> wrote:
> Hey Flaskers,
>
> At the day job I came up with a class based views solution to meet some of
> the needs of our application.
> I recently started a side project where I wanted to use the same thing and
> thought it might be time to start
> extracting the functionality into a Flask extension others might find useful
> too.
>
> It takes a somewhat different approach to class based views than what you
> find in the flask.views namespace
> so I'd really appreciate any feedback on the API and features. There are a
> couple of features I havent
> extracted yet, specifically view wrapping, and template contexts, but I'll
> be getting to them pretty soon.
>
> Take a look here: http://packages.python.org/Flask-Classy/
>
> I look forward to hearing what you think.
>
> - Freedom



-- 
Sincerely,
Igor Davydenko

Re: [flask] An alternative approach to class based views

From:
Freedom Dumlao
Date:
2012-10-31 @ 17:53
Thanks Igor, I look forward to hearing about your experiences.

At present I don't have lazy view support, however I plan on making the
routing features a bit more maleable, and in doing so will probably make it
possible to create lazy views.

- Freedom


On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko
<playpauseandstop@gmail.com>wrote:

> Looks very promising for me, will try in one of my current projects.
>
> Only a quick question, has Flask-Classy an ability to register views
> lazy way, without View.register call?
>
> I mean, I like to use lazy views pattern (
> http://flask.pocoo.org/docs/patterns/lazyloading/,
> http://pypi.python.org/pypi/Flask-LazyViews ) and place my views to
> ``views`` module or package. But from first view in ``Flask-Classy`` I
> only can add url rules with explicitly View.register call, which means
> I need to import this class to application, which I don't really like.
>
> On 31 October 2012 18:27, Freedom Dumlao <freedomdumlao@gmail.com> wrote:
> > Hey Flaskers,
> >
> > At the day job I came up with a class based views solution to meet some
> of
> > the needs of our application.
> > I recently started a side project where I wanted to use the same thing
> and
> > thought it might be time to start
> > extracting the functionality into a Flask extension others might find
> useful
> > too.
> >
> > It takes a somewhat different approach to class based views than what you
> > find in the flask.views namespace
> > so I'd really appreciate any feedback on the API and features. There are
> a
> > couple of features I havent
> > extracted yet, specifically view wrapping, and template contexts, but
> I'll
> > be getting to them pretty soon.
> >
> > Take a look here: http://packages.python.org/Flask-Classy/
> >
> > I look forward to hearing what you think.
> >
> > - Freedom
>
>
>
> --
> Sincerely,
> Igor Davydenko
>

Re: [flask] An alternative approach to class based views

From:
Igor Davydenko
Date:
2012-10-31 @ 18:26
Ok, thanks,

Will wait on news here

On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com> wrote:
> Thanks Igor, I look forward to hearing about your experiences.
>
> At present I don't have lazy view support, however I plan on making the
> routing features a bit more maleable, and in doing so will probably make it
> possible to create lazy views.
>
> - Freedom
>
>
> On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <playpauseandstop@gmail.com>
> wrote:
>>
>> Looks very promising for me, will try in one of my current projects.
>>
>> Only a quick question, has Flask-Classy an ability to register views
>> lazy way, without View.register call?
>>
>> I mean, I like to use lazy views pattern (
>> http://flask.pocoo.org/docs/patterns/lazyloading/,
>> http://pypi.python.org/pypi/Flask-LazyViews ) and place my views to
>> ``views`` module or package. But from first view in ``Flask-Classy`` I
>> only can add url rules with explicitly View.register call, which means
>> I need to import this class to application, which I don't really like.
>>
>> On 31 October 2012 18:27, Freedom Dumlao <freedomdumlao@gmail.com> wrote:
>> > Hey Flaskers,
>> >
>> > At the day job I came up with a class based views solution to meet some
>> > of
>> > the needs of our application.
>> > I recently started a side project where I wanted to use the same thing
>> > and
>> > thought it might be time to start
>> > extracting the functionality into a Flask extension others might find
>> > useful
>> > too.
>> >
>> > It takes a somewhat different approach to class based views than what
>> > you
>> > find in the flask.views namespace
>> > so I'd really appreciate any feedback on the API and features. There are
>> > a
>> > couple of features I havent
>> > extracted yet, specifically view wrapping, and template contexts, but
>> > I'll
>> > be getting to them pretty soon.
>> >
>> > Take a look here: http://packages.python.org/Flask-Classy/
>> >
>> > I look forward to hearing what you think.
>> >
>> > - Freedom
>>
>>
>>
>> --
>> Sincerely,
>> Igor Davydenko
>
>



-- 
Sincerely,
Igor Davydenko

Re: [flask] An alternative approach to class based views

From:
Mark Grey
Date:
2012-10-31 @ 19:05
I actually just ran into this problem just now developing and am seriously
considering converting my MethodViews to this ext.  I'm pulling for you
here, Freedom.

IMHO this is a significant improvement over the business about attaching
MethodViews in the last paragraph at http://flask.pocoo.org/docs/views/.
 Even refactored as demonstrated, that's still a lot of extra code just to
get the routing down accurately, and the decorator syntax is still the most
sexy way to attach the endpoints.

On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko
<playpauseandstop@gmail.com>wrote:

> Ok, thanks,
>
> Will wait on news here
>
> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com> wrote:
> > Thanks Igor, I look forward to hearing about your experiences.
> >
> > At present I don't have lazy view support, however I plan on making the
> > routing features a bit more maleable, and in doing so will probably make
> it
> > possible to create lazy views.
> >
> > - Freedom
> >
> >
> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
> playpauseandstop@gmail.com>
> > wrote:
> >>
> >> Looks very promising for me, will try in one of my current projects.
> >>
> >> Only a quick question, has Flask-Classy an ability to register views
> >> lazy way, without View.register call?
> >>
> >> I mean, I like to use lazy views pattern (
> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my views to
> >> ``views`` module or package. But from first view in ``Flask-Classy`` I
> >> only can add url rules with explicitly View.register call, which means
> >> I need to import this class to application, which I don't really like.
> >>
> >> On 31 October 2012 18:27, Freedom Dumlao <freedomdumlao@gmail.com>
> wrote:
> >> > Hey Flaskers,
> >> >
> >> > At the day job I came up with a class based views solution to meet
> some
> >> > of
> >> > the needs of our application.
> >> > I recently started a side project where I wanted to use the same thing
> >> > and
> >> > thought it might be time to start
> >> > extracting the functionality into a Flask extension others might find
> >> > useful
> >> > too.
> >> >
> >> > It takes a somewhat different approach to class based views than what
> >> > you
> >> > find in the flask.views namespace
> >> > so I'd really appreciate any feedback on the API and features. There
> are
> >> > a
> >> > couple of features I havent
> >> > extracted yet, specifically view wrapping, and template contexts, but
> >> > I'll
> >> > be getting to them pretty soon.
> >> >
> >> > Take a look here: http://packages.python.org/Flask-Classy/
> >> >
> >> > I look forward to hearing what you think.
> >> >
> >> > - Freedom
> >>
> >>
> >>
> >> --
> >> Sincerely,
> >> Igor Davydenko
> >
> >
>
>
>
> --
> Sincerely,
> Igor Davydenko
>

Re: [flask] An alternative approach to class based views

From:
Mark Grey
Date:
2012-10-31 @ 19:29
Subdomain support here for me would be the deal maker.

Right now I have one api subdomain that is aliases at both `data.app.com`
as well as `app.com/data` to allow our client-side devs to circumvent
cross-domain policy on Ajax.  It would be very cool to have Classy views
for each program model and setup the REST service that way rather than the
mix-together or @route decorated functions and MethodViews we currently use.

My project hasn't gone to deployment yet, so it'd be cool to take advantage
of this extension.

On Wed, Oct 31, 2012 at 3:05 PM, Mark Grey <mark.asperia@gmail.com> wrote:

> I actually just ran into this problem just now developing and am seriously
> considering converting my MethodViews to this ext.  I'm pulling for you
> here, Freedom.
>
> IMHO this is a significant improvement over the business about attaching
> MethodViews in the last paragraph at http://flask.pocoo.org/docs/views/.
>  Even refactored as demonstrated, that's still a lot of extra code just to
> get the routing down accurately, and the decorator syntax is still the most
> sexy way to attach the endpoints.
>
>
> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
> playpauseandstop@gmail.com> wrote:
>
>> Ok, thanks,
>>
>> Will wait on news here
>>
>> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com> wrote:
>> > Thanks Igor, I look forward to hearing about your experiences.
>> >
>> > At present I don't have lazy view support, however I plan on making the
>> > routing features a bit more maleable, and in doing so will probably
>> make it
>> > possible to create lazy views.
>> >
>> > - Freedom
>> >
>> >
>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>> playpauseandstop@gmail.com>
>> > wrote:
>> >>
>> >> Looks very promising for me, will try in one of my current projects.
>> >>
>> >> Only a quick question, has Flask-Classy an ability to register views
>> >> lazy way, without View.register call?
>> >>
>> >> I mean, I like to use lazy views pattern (
>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my views to
>> >> ``views`` module or package. But from first view in ``Flask-Classy`` I
>> >> only can add url rules with explicitly View.register call, which means
>> >> I need to import this class to application, which I don't really like.
>> >>
>> >> On 31 October 2012 18:27, Freedom Dumlao <freedomdumlao@gmail.com>
>> wrote:
>> >> > Hey Flaskers,
>> >> >
>> >> > At the day job I came up with a class based views solution to meet
>> some
>> >> > of
>> >> > the needs of our application.
>> >> > I recently started a side project where I wanted to use the same
>> thing
>> >> > and
>> >> > thought it might be time to start
>> >> > extracting the functionality into a Flask extension others might find
>> >> > useful
>> >> > too.
>> >> >
>> >> > It takes a somewhat different approach to class based views than what
>> >> > you
>> >> > find in the flask.views namespace
>> >> > so I'd really appreciate any feedback on the API and features. There
>> are
>> >> > a
>> >> > couple of features I havent
>> >> > extracted yet, specifically view wrapping, and template contexts, but
>> >> > I'll
>> >> > be getting to them pretty soon.
>> >> >
>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>> >> >
>> >> > I look forward to hearing what you think.
>> >> >
>> >> > - Freedom
>> >>
>> >>
>> >>
>> >> --
>> >> Sincerely,
>> >> Igor Davydenko
>> >
>> >
>>
>>
>>
>> --
>> Sincerely,
>> Igor Davydenko
>>
>
>

Re: [flask] An alternative approach to class based views

From:
Ben Hughes
Date:
2012-11-01 @ 15:41
Great work freedom - I echo what's been said - I think this ext provides a
neat, easy to comprehend api when blueprints just don't quite fit.

Well done :))

Sent from my iPhone

On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com> wrote:

I actually just ran into this problem just now developing and am seriously
considering converting my MethodViews to this ext.  I'm pulling for you
here, Freedom.

IMHO this is a significant improvement over the business about attaching
MethodViews in the last paragraph at http://flask.pocoo.org/docs/views/.
 Even refactored as demonstrated, that's still a lot of extra code just to
get the routing down accurately, and the decorator syntax is still the most
sexy way to attach the endpoints.

On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko
<playpauseandstop@gmail.com>wrote:

> Ok, thanks,
>
> Will wait on news here
>
> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com> wrote:
> > Thanks Igor, I look forward to hearing about your experiences.
> >
> > At present I don't have lazy view support, however I plan on making the
> > routing features a bit more maleable, and in doing so will probably make
> it
> > possible to create lazy views.
> >
> > - Freedom
> >
> >
> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
> playpauseandstop@gmail.com>
> > wrote:
> >>
> >> Looks very promising for me, will try in one of my current projects.
> >>
> >> Only a quick question, has Flask-Classy an ability to register views
> >> lazy way, without View.register call?
> >>
> >> I mean, I like to use lazy views pattern (
> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my views to
> >> ``views`` module or package. But from first view in ``Flask-Classy`` I
> >> only can add url rules with explicitly View.register call, which means
> >> I need to import this class to application, which I don't really like.
> >>
> >> On 31 October 2012 18:27, Freedom Dumlao <freedomdumlao@gmail.com>
> wrote:
> >> > Hey Flaskers,
> >> >
> >> > At the day job I came up with a class based views solution to meet
> some
> >> > of
> >> > the needs of our application.
> >> > I recently started a side project where I wanted to use the same thing
> >> > and
> >> > thought it might be time to start
> >> > extracting the functionality into a Flask extension others might find
> >> > useful
> >> > too.
> >> >
> >> > It takes a somewhat different approach to class based views than what
> >> > you
> >> > find in the flask.views namespace
> >> > so I'd really appreciate any feedback on the API and features. There
> are
> >> > a
> >> > couple of features I havent
> >> > extracted yet, specifically view wrapping, and template contexts, but
> >> > I'll
> >> > be getting to them pretty soon.
> >> >
> >> > Take a look here: http://packages.python.org/Flask-Classy/
> >> >
> >> > I look forward to hearing what you think.
> >> >
> >> > - Freedom
> >>
> >>
> >>
> >> --
> >> Sincerely,
> >> Igor Davydenko
> >
> >
>
>
>
> --
> Sincerely,
> Igor Davydenko
>

Re: [flask] An alternative approach to class based views

From:
Owein Reese
Date:
2012-11-01 @ 16:31
This really is nice. Like others have said, add subdomain support and
you'll have created something really special.
On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com> wrote:

> Great work freedom - I echo what's been said - I think this ext provides a
> neat, easy to comprehend api when blueprints just don't quite fit.
>
> Well done :))
>
> Sent from my iPhone
>
> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com> wrote:
>
> I actually just ran into this problem just now developing and am seriously
> considering converting my MethodViews to this ext.  I'm pulling for you
> here, Freedom.
>
> IMHO this is a significant improvement over the business about attaching
> MethodViews in the last paragraph at http://flask.pocoo.org/docs/views/.
>  Even refactored as demonstrated, that's still a lot of extra code just to
> get the routing down accurately, and the decorator syntax is still the most
> sexy way to attach the endpoints.
>
> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
> playpauseandstop@gmail.com> wrote:
>
>> Ok, thanks,
>>
>> Will wait on news here
>>
>> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com> wrote:
>> > Thanks Igor, I look forward to hearing about your experiences.
>> >
>> > At present I don't have lazy view support, however I plan on making the
>> > routing features a bit more maleable, and in doing so will probably
>> make it
>> > possible to create lazy views.
>> >
>> > - Freedom
>> >
>> >
>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>> playpauseandstop@gmail.com>
>> > wrote:
>> >>
>> >> Looks very promising for me, will try in one of my current projects.
>> >>
>> >> Only a quick question, has Flask-Classy an ability to register views
>> >> lazy way, without View.register call?
>> >>
>> >> I mean, I like to use lazy views pattern (
>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my views to
>> >> ``views`` module or package. But from first view in ``Flask-Classy`` I
>> >> only can add url rules with explicitly View.register call, which means
>> >> I need to import this class to application, which I don't really like.
>> >>
>> >> On 31 October 2012 18:27, Freedom Dumlao <freedomdumlao@gmail.com>
>> wrote:
>> >> > Hey Flaskers,
>> >> >
>> >> > At the day job I came up with a class based views solution to meet
>> some
>> >> > of
>> >> > the needs of our application.
>> >> > I recently started a side project where I wanted to use the same
>> thing
>> >> > and
>> >> > thought it might be time to start
>> >> > extracting the functionality into a Flask extension others might find
>> >> > useful
>> >> > too.
>> >> >
>> >> > It takes a somewhat different approach to class based views than what
>> >> > you
>> >> > find in the flask.views namespace
>> >> > so I'd really appreciate any feedback on the API and features. There
>> are
>> >> > a
>> >> > couple of features I havent
>> >> > extracted yet, specifically view wrapping, and template contexts, but
>> >> > I'll
>> >> > be getting to them pretty soon.
>> >> >
>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>> >> >
>> >> > I look forward to hearing what you think.
>> >> >
>> >> > - Freedom
>> >>
>> >>
>> >>
>> >> --
>> >> Sincerely,
>> >> Igor Davydenko
>> >
>> >
>>
>>
>>
>> --
>> Sincerely,
>> Igor Davydenko
>>
>
>

Re: [flask] An alternative approach to class based views

From:
Mark Grey
Date:
2012-11-05 @ 15:40
Freedom,

I noticed on your github that you've started adding subdomain support.

I am going to try implementing your extension for views today and will
provide some testing info =)


On Thu, Nov 1, 2012 at 12:31 PM, Owein Reese <owreese@gmail.com> wrote:

> This really is nice. Like others have said, add subdomain support and
> you'll have created something really special.
> On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com> wrote:
>
>> Great work freedom - I echo what's been said - I think this ext provides
>> a neat, easy to comprehend api when blueprints just don't quite fit.
>>
>> Well done :))
>>
>> Sent from my iPhone
>>
>> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com> wrote:
>>
>>  I actually just ran into this problem just now developing and am
>> seriously considering converting my MethodViews to this ext.  I'm pulling
>> for you here, Freedom.
>>
>> IMHO this is a significant improvement over the business about attaching
>> MethodViews in the last paragraph at http://flask.pocoo.org/docs/views/.
>>  Even refactored as demonstrated, that's still a lot of extra code just to
>> get the routing down accurately, and the decorator syntax is still the most
>> sexy way to attach the endpoints.
>>
>> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
>> playpauseandstop@gmail.com> wrote:
>>
>>> Ok, thanks,
>>>
>>> Will wait on news here
>>>
>>> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com>
>>> wrote:
>>> > Thanks Igor, I look forward to hearing about your experiences.
>>> >
>>> > At present I don't have lazy view support, however I plan on making the
>>> > routing features a bit more maleable, and in doing so will probably
>>> make it
>>> > possible to create lazy views.
>>> >
>>> > - Freedom
>>> >
>>> >
>>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>>> playpauseandstop@gmail.com>
>>> > wrote:
>>> >>
>>> >> Looks very promising for me, will try in one of my current projects.
>>> >>
>>> >> Only a quick question, has Flask-Classy an ability to register views
>>> >> lazy way, without View.register call?
>>> >>
>>> >> I mean, I like to use lazy views pattern (
>>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my views to
>>> >> ``views`` module or package. But from first view in ``Flask-Classy`` I
>>> >> only can add url rules with explicitly View.register call, which means
>>> >> I need to import this class to application, which I don't really like.
>>> >>
>>> >> On 31 October 2012 18:27, Freedom Dumlao <freedomdumlao@gmail.com>
>>> wrote:
>>> >> > Hey Flaskers,
>>> >> >
>>> >> > At the day job I came up with a class based views solution to meet
>>> some
>>> >> > of
>>> >> > the needs of our application.
>>> >> > I recently started a side project where I wanted to use the same
>>> thing
>>> >> > and
>>> >> > thought it might be time to start
>>> >> > extracting the functionality into a Flask extension others might
>>> find
>>> >> > useful
>>> >> > too.
>>> >> >
>>> >> > It takes a somewhat different approach to class based views than
>>> what
>>> >> > you
>>> >> > find in the flask.views namespace
>>> >> > so I'd really appreciate any feedback on the API and features.
>>> There are
>>> >> > a
>>> >> > couple of features I havent
>>> >> > extracted yet, specifically view wrapping, and template contexts,
>>> but
>>> >> > I'll
>>> >> > be getting to them pretty soon.
>>> >> >
>>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>>> >> >
>>> >> > I look forward to hearing what you think.
>>> >> >
>>> >> > - Freedom
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Sincerely,
>>> >> Igor Davydenko
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Sincerely,
>>> Igor Davydenko
>>>
>>
>>

Re: [flask] An alternative approach to class based views

From:
Freedom Dumlao
Date:
2012-11-05 @ 16:04
Thanks Mark.

Take a look at the docs at http://packages.python.org/Flask-Classy/ and see
if they make sense. I've also fixed some bugs that I've found while using
it myself. Let me know what you think!

- Freedom


On Mon, Nov 5, 2012 at 10:40 AM, Mark Grey <mark.asperia@gmail.com> wrote:

> Freedom,
>
> I noticed on your github that you've started adding subdomain support.
>
> I am going to try implementing your extension for views today and will
> provide some testing info =)
>
>
> On Thu, Nov 1, 2012 at 12:31 PM, Owein Reese <owreese@gmail.com> wrote:
>
>> This really is nice. Like others have said, add subdomain support and
>> you'll have created something really special.
>> On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com> wrote:
>>
>>> Great work freedom - I echo what's been said - I think this ext provides
>>> a neat, easy to comprehend api when blueprints just don't quite fit.
>>>
>>> Well done :))
>>>
>>> Sent from my iPhone
>>>
>>> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com> wrote:
>>>
>>>  I actually just ran into this problem just now developing and am
>>> seriously considering converting my MethodViews to this ext.  I'm pulling
>>> for you here, Freedom.
>>>
>>> IMHO this is a significant improvement over the business about attaching
>>> MethodViews in the last paragraph at http://flask.pocoo.org/docs/views/.
>>>  Even refactored as demonstrated, that's still a lot of extra code just to
>>> get the routing down accurately, and the decorator syntax is still the most
>>> sexy way to attach the endpoints.
>>>
>>> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
>>> playpauseandstop@gmail.com> wrote:
>>>
>>>> Ok, thanks,
>>>>
>>>> Will wait on news here
>>>>
>>>> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com>
>>>> wrote:
>>>> > Thanks Igor, I look forward to hearing about your experiences.
>>>> >
>>>> > At present I don't have lazy view support, however I plan on making
>>>> the
>>>> > routing features a bit more maleable, and in doing so will probably
>>>> make it
>>>> > possible to create lazy views.
>>>> >
>>>> > - Freedom
>>>> >
>>>> >
>>>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>>>> playpauseandstop@gmail.com>
>>>> > wrote:
>>>> >>
>>>> >> Looks very promising for me, will try in one of my current projects.
>>>> >>
>>>> >> Only a quick question, has Flask-Classy an ability to register views
>>>> >> lazy way, without View.register call?
>>>> >>
>>>> >> I mean, I like to use lazy views pattern (
>>>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>>>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my views to
>>>> >> ``views`` module or package. But from first view in ``Flask-Classy``
>>>> I
>>>> >> only can add url rules with explicitly View.register call, which
>>>> means
>>>> >> I need to import this class to application, which I don't really
>>>> like.
>>>> >>
>>>> >> On 31 October 2012 18:27, Freedom Dumlao <freedomdumlao@gmail.com>
>>>> wrote:
>>>> >> > Hey Flaskers,
>>>> >> >
>>>> >> > At the day job I came up with a class based views solution to meet
>>>> some
>>>> >> > of
>>>> >> > the needs of our application.
>>>> >> > I recently started a side project where I wanted to use the same
>>>> thing
>>>> >> > and
>>>> >> > thought it might be time to start
>>>> >> > extracting the functionality into a Flask extension others might
>>>> find
>>>> >> > useful
>>>> >> > too.
>>>> >> >
>>>> >> > It takes a somewhat different approach to class based views than
>>>> what
>>>> >> > you
>>>> >> > find in the flask.views namespace
>>>> >> > so I'd really appreciate any feedback on the API and features.
>>>> There are
>>>> >> > a
>>>> >> > couple of features I havent
>>>> >> > extracted yet, specifically view wrapping, and template contexts,
>>>> but
>>>> >> > I'll
>>>> >> > be getting to them pretty soon.
>>>> >> >
>>>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>>>> >> >
>>>> >> > I look forward to hearing what you think.
>>>> >> >
>>>> >> > - Freedom
>>>> >>
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Sincerely,
>>>> >> Igor Davydenko
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Sincerely,
>>>> Igor Davydenko
>>>>
>>>
>>>
>

Re: [flask] An alternative approach to class based views

From:
Jesaja Everling
Date:
2012-11-06 @ 23:51
The docs are a very entertaining read! I tried Flask-Classy today, and
really like it so far! It feels very elegant.
You wrote in your first post that you are planning to support template
contexts. What exactly do you mean by this?
What would be nice IMO was a way to specify a template folder, like I can
do with a blueprint by passing the template_folder parameter.
This can also be done manually by changing the Jinja2 environment, so it's
no big deal, but it still would be nice to have, I think.

I like how you automatically attach an index to the view name, if
(multiple) routes are defined for a view.

Just one suggestion: maybe it would be better to use some other name than
"id" as parameter for the get method?
It's no big deal, but pylint will complain about redefining a built-in.
Maybe "item" or "obj_id" or something like this would be better.

Thanks a lot for Flask-Classy!

Best Regards,

Jesaja Everling



On Mon, Nov 5, 2012 at 5:04 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> Thanks Mark.
>
> Take a look at the docs at http://packages.python.org/Flask-Classy/ and
> see if they make sense. I've also fixed some bugs that I've found while
> using it myself. Let me know what you think!
>
> - Freedom
>
>
> On Mon, Nov 5, 2012 at 10:40 AM, Mark Grey <mark.asperia@gmail.com> wrote:
>
>> Freedom,
>>
>> I noticed on your github that you've started adding subdomain support.
>>
>> I am going to try implementing your extension for views today and will
>> provide some testing info =)
>>
>>
>> On Thu, Nov 1, 2012 at 12:31 PM, Owein Reese <owreese@gmail.com> wrote:
>>
>>> This really is nice. Like others have said, add subdomain support and
>>> you'll have created something really special.
>>> On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com> wrote:
>>>
>>>> Great work freedom - I echo what's been said - I think this ext
>>>> provides a neat, easy to comprehend api when blueprints just don't quite
>>>> fit.
>>>>
>>>> Well done :))
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com> wrote:
>>>>
>>>>  I actually just ran into this problem just now developing and am
>>>> seriously considering converting my MethodViews to this ext.  I'm pulling
>>>> for you here, Freedom.
>>>>
>>>> IMHO this is a significant improvement over the business about
>>>> attaching MethodViews in the last paragraph at
>>>> http://flask.pocoo.org/docs/views/.  Even refactored as demonstrated,
>>>> that's still a lot of extra code just to get the routing down accurately,
>>>> and the decorator syntax is still the most sexy way to attach the endpoints.
>>>>
>>>> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
>>>> playpauseandstop@gmail.com> wrote:
>>>>
>>>>> Ok, thanks,
>>>>>
>>>>> Will wait on news here
>>>>>
>>>>> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com>
>>>>> wrote:
>>>>> > Thanks Igor, I look forward to hearing about your experiences.
>>>>> >
>>>>> > At present I don't have lazy view support, however I plan on making
>>>>> the
>>>>> > routing features a bit more maleable, and in doing so will probably
>>>>> make it
>>>>> > possible to create lazy views.
>>>>> >
>>>>> > - Freedom
>>>>> >
>>>>> >
>>>>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>>>>> playpauseandstop@gmail.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> Looks very promising for me, will try in one of my current projects.
>>>>> >>
>>>>> >> Only a quick question, has Flask-Classy an ability to register views
>>>>> >> lazy way, without View.register call?
>>>>> >>
>>>>> >> I mean, I like to use lazy views pattern (
>>>>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>>>>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my views to
>>>>> >> ``views`` module or package. But from first view in
>>>>> ``Flask-Classy`` I
>>>>> >> only can add url rules with explicitly View.register call, which
>>>>> means
>>>>> >> I need to import this class to application, which I don't really
>>>>> like.
>>>>> >>
>>>>> >> On 31 October 2012 18:27, Freedom Dumlao <freedomdumlao@gmail.com>
>>>>> wrote:
>>>>> >> > Hey Flaskers,
>>>>> >> >
>>>>> >> > At the day job I came up with a class based views solution to
>>>>> meet some
>>>>> >> > of
>>>>> >> > the needs of our application.
>>>>> >> > I recently started a side project where I wanted to use the same
>>>>> thing
>>>>> >> > and
>>>>> >> > thought it might be time to start
>>>>> >> > extracting the functionality into a Flask extension others might
>>>>> find
>>>>> >> > useful
>>>>> >> > too.
>>>>> >> >
>>>>> >> > It takes a somewhat different approach to class based views than
>>>>> what
>>>>> >> > you
>>>>> >> > find in the flask.views namespace
>>>>> >> > so I'd really appreciate any feedback on the API and features.
>>>>> There are
>>>>> >> > a
>>>>> >> > couple of features I havent
>>>>> >> > extracted yet, specifically view wrapping, and template contexts,
>>>>> but
>>>>> >> > I'll
>>>>> >> > be getting to them pretty soon.
>>>>> >> >
>>>>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>>>>> >> >
>>>>> >> > I look forward to hearing what you think.
>>>>> >> >
>>>>> >> > - Freedom
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Sincerely,
>>>>> >> Igor Davydenko
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sincerely,
>>>>> Igor Davydenko
>>>>>
>>>>
>>>>
>>
>

Re: [flask] An alternative approach to class based views

From:
Freedom Dumlao
Date:
2012-11-08 @ 15:02
Thanks Jesaja, I appreciate the feedback!

So the template context idea is a two-fold feature, and works with the
class based "before_request" and "after_request" feature that is also in
development. It does automatically look for templates in the folder based
on the FlaskView but also it allows you to build up a context to send to
the template from any method that executes during the request cycle.

As for the default id parameter name, you're completely right. I'll change
it before the next release in an update. It will be a breaking change for
some but I think it's better to fix that now instead of letting it become a
real problem once many people are using it.

Freedom


On Tue, Nov 6, 2012 at 6:51 PM, Jesaja Everling <jeverling@gmail.com> wrote:

> The docs are a very entertaining read! I tried Flask-Classy today, and
> really like it so far! It feels very elegant.
> You wrote in your first post that you are planning to support template
> contexts. What exactly do you mean by this?
> What would be nice IMO was a way to specify a template folder, like I can
> do with a blueprint by passing the template_folder parameter.
> This can also be done manually by changing the Jinja2 environment, so it's
> no big deal, but it still would be nice to have, I think.
>
> I like how you automatically attach an index to the view name, if
> (multiple) routes are defined for a view.
>
> Just one suggestion: maybe it would be better to use some other name than
> "id" as parameter for the get method?
> It's no big deal, but pylint will complain about redefining a built-in.
> Maybe "item" or "obj_id" or something like this would be better.
>
> Thanks a lot for Flask-Classy!
>
> Best Regards,
>
> Jesaja Everling
>
>
>
>
> On Mon, Nov 5, 2012 at 5:04 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>
>> Thanks Mark.
>>
>> Take a look at the docs at http://packages.python.org/Flask-Classy/ and
>> see if they make sense. I've also fixed some bugs that I've found while
>> using it myself. Let me know what you think!
>>
>> - Freedom
>>
>>
>> On Mon, Nov 5, 2012 at 10:40 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>
>>> Freedom,
>>>
>>> I noticed on your github that you've started adding subdomain support.
>>>
>>> I am going to try implementing your extension for views today and will
>>> provide some testing info =)
>>>
>>>
>>> On Thu, Nov 1, 2012 at 12:31 PM, Owein Reese <owreese@gmail.com> wrote:
>>>
>>>> This really is nice. Like others have said, add subdomain support and
>>>> you'll have created something really special.
>>>> On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com> wrote:
>>>>
>>>>> Great work freedom - I echo what's been said - I think this ext
>>>>> provides a neat, easy to comprehend api when blueprints just don't quite
>>>>> fit.
>>>>>
>>>>> Well done :))
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com> wrote:
>>>>>
>>>>>  I actually just ran into this problem just now developing and am
>>>>> seriously considering converting my MethodViews to this ext.  I'm pulling
>>>>> for you here, Freedom.
>>>>>
>>>>> IMHO this is a significant improvement over the business about
>>>>> attaching MethodViews in the last paragraph at
>>>>> http://flask.pocoo.org/docs/views/.  Even refactored as demonstrated,
>>>>> that's still a lot of extra code just to get the routing down accurately,
>>>>> and the decorator syntax is still the most sexy way to attach the endpoints.
>>>>>
>>>>> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
>>>>> playpauseandstop@gmail.com> wrote:
>>>>>
>>>>>> Ok, thanks,
>>>>>>
>>>>>> Will wait on news here
>>>>>>
>>>>>> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com>
>>>>>> wrote:
>>>>>> > Thanks Igor, I look forward to hearing about your experiences.
>>>>>> >
>>>>>> > At present I don't have lazy view support, however I plan on making
>>>>>> the
>>>>>> > routing features a bit more maleable, and in doing so will probably
>>>>>> make it
>>>>>> > possible to create lazy views.
>>>>>> >
>>>>>> > - Freedom
>>>>>> >
>>>>>> >
>>>>>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>>>>>> playpauseandstop@gmail.com>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> Looks very promising for me, will try in one of my current
>>>>>> projects.
>>>>>> >>
>>>>>> >> Only a quick question, has Flask-Classy an ability to register
>>>>>> views
>>>>>> >> lazy way, without View.register call?
>>>>>> >>
>>>>>> >> I mean, I like to use lazy views pattern (
>>>>>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>>>>>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my views
>>>>>> to
>>>>>> >> ``views`` module or package. But from first view in
>>>>>> ``Flask-Classy`` I
>>>>>> >> only can add url rules with explicitly View.register call, which
>>>>>> means
>>>>>> >> I need to import this class to application, which I don't really
>>>>>> like.
>>>>>> >>
>>>>>> >> On 31 October 2012 18:27, Freedom Dumlao <freedomdumlao@gmail.com>
>>>>>> wrote:
>>>>>> >> > Hey Flaskers,
>>>>>> >> >
>>>>>> >> > At the day job I came up with a class based views solution to
>>>>>> meet some
>>>>>> >> > of
>>>>>> >> > the needs of our application.
>>>>>> >> > I recently started a side project where I wanted to use the same
>>>>>> thing
>>>>>> >> > and
>>>>>> >> > thought it might be time to start
>>>>>> >> > extracting the functionality into a Flask extension others might
>>>>>> find
>>>>>> >> > useful
>>>>>> >> > too.
>>>>>> >> >
>>>>>> >> > It takes a somewhat different approach to class based views than
>>>>>> what
>>>>>> >> > you
>>>>>> >> > find in the flask.views namespace
>>>>>> >> > so I'd really appreciate any feedback on the API and features.
>>>>>> There are
>>>>>> >> > a
>>>>>> >> > couple of features I havent
>>>>>> >> > extracted yet, specifically view wrapping, and template
>>>>>> contexts, but
>>>>>> >> > I'll
>>>>>> >> > be getting to them pretty soon.
>>>>>> >> >
>>>>>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>>>>>> >> >
>>>>>> >> > I look forward to hearing what you think.
>>>>>> >> >
>>>>>> >> > - Freedom
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Sincerely,
>>>>>> >> Igor Davydenko
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sincerely,
>>>>>> Igor Davydenko
>>>>>>
>>>>>
>>>>>
>>>
>>
>

Re: [flask] An alternative approach to class based views

From:
Jesaja Everling
Date:
2012-11-08 @ 22:20
Cool, automatic template folder lookup sounds exactly what I'm looking for!
:)
I have created a pull request on github with a small change, to only append
an index to the route_name for custom routes if there is more than one.

I'm not sure if it isn't better to stick with the behavior as it is now,
because maybe it's better if a custom route always means an index will be
added.
On the other hand, most of the time people will probably define only one
custom route, and for this cases it would be nicer without the index.


On Thu, Nov 8, 2012 at 4:02 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> Thanks Jesaja, I appreciate the feedback!
>
> So the template context idea is a two-fold feature, and works with the
> class based "before_request" and "after_request" feature that is also in
> development. It does automatically look for templates in the folder based
> on the FlaskView but also it allows you to build up a context to send to
> the template from any method that executes during the request cycle.
>
> As for the default id parameter name, you're completely right. I'll change
> it before the next release in an update. It will be a breaking change for
> some but I think it's better to fix that now instead of letting it become a
> real problem once many people are using it.
>
> Freedom
>
>
> On Tue, Nov 6, 2012 at 6:51 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>
>> The docs are a very entertaining read! I tried Flask-Classy today, and
>> really like it so far! It feels very elegant.
>> You wrote in your first post that you are planning to support template
>> contexts. What exactly do you mean by this?
>> What would be nice IMO was a way to specify a template folder, like I can
>> do with a blueprint by passing the template_folder parameter.
>> This can also be done manually by changing the Jinja2 environment, so
>> it's no big deal, but it still would be nice to have, I think.
>>
>> I like how you automatically attach an index to the view name, if
>> (multiple) routes are defined for a view.
>>
>> Just one suggestion: maybe it would be better to use some other name than
>> "id" as parameter for the get method?
>> It's no big deal, but pylint will complain about redefining a built-in.
>> Maybe "item" or "obj_id" or something like this would be better.
>>
>> Thanks a lot for Flask-Classy!
>>
>> Best Regards,
>>
>> Jesaja Everling
>>
>>
>>
>>
>> On Mon, Nov 5, 2012 at 5:04 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>>
>>> Thanks Mark.
>>>
>>> Take a look at the docs at http://packages.python.org/Flask-Classy/ and
>>> see if they make sense. I've also fixed some bugs that I've found while
>>> using it myself. Let me know what you think!
>>>
>>> - Freedom
>>>
>>>
>>> On Mon, Nov 5, 2012 at 10:40 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>
>>>> Freedom,
>>>>
>>>> I noticed on your github that you've started adding subdomain support.
>>>>
>>>> I am going to try implementing your extension for views today and will
>>>> provide some testing info =)
>>>>
>>>>
>>>> On Thu, Nov 1, 2012 at 12:31 PM, Owein Reese <owreese@gmail.com> wrote:
>>>>
>>>>> This really is nice. Like others have said, add subdomain support and
>>>>> you'll have created something really special.
>>>>> On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com> wrote:
>>>>>
>>>>>> Great work freedom - I echo what's been said - I think this ext
>>>>>> provides a neat, easy to comprehend api when blueprints just don't quite
>>>>>> fit.
>>>>>>
>>>>>> Well done :))
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com> wrote:
>>>>>>
>>>>>>  I actually just ran into this problem just now developing and am
>>>>>> seriously considering converting my MethodViews to this ext.  I'm pulling
>>>>>> for you here, Freedom.
>>>>>>
>>>>>> IMHO this is a significant improvement over the business about
>>>>>> attaching MethodViews in the last paragraph at
>>>>>> http://flask.pocoo.org/docs/views/.  Even refactored as
>>>>>> demonstrated, that's still a lot of extra code just to get the routing down
>>>>>> accurately, and the decorator syntax is still the most sexy way to attach
>>>>>> the endpoints.
>>>>>>
>>>>>> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
>>>>>> playpauseandstop@gmail.com> wrote:
>>>>>>
>>>>>>> Ok, thanks,
>>>>>>>
>>>>>>> Will wait on news here
>>>>>>>
>>>>>>> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com>
>>>>>>> wrote:
>>>>>>> > Thanks Igor, I look forward to hearing about your experiences.
>>>>>>> >
>>>>>>> > At present I don't have lazy view support, however I plan on
>>>>>>> making the
>>>>>>> > routing features a bit more maleable, and in doing so will
>>>>>>> probably make it
>>>>>>> > possible to create lazy views.
>>>>>>> >
>>>>>>> > - Freedom
>>>>>>> >
>>>>>>> >
>>>>>>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>>>>>>> playpauseandstop@gmail.com>
>>>>>>> > wrote:
>>>>>>> >>
>>>>>>> >> Looks very promising for me, will try in one of my current
>>>>>>> projects.
>>>>>>> >>
>>>>>>> >> Only a quick question, has Flask-Classy an ability to register
>>>>>>> views
>>>>>>> >> lazy way, without View.register call?
>>>>>>> >>
>>>>>>> >> I mean, I like to use lazy views pattern (
>>>>>>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>>>>>>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my views
>>>>>>> to
>>>>>>> >> ``views`` module or package. But from first view in
>>>>>>> ``Flask-Classy`` I
>>>>>>> >> only can add url rules with explicitly View.register call, which
>>>>>>> means
>>>>>>> >> I need to import this class to application, which I don't really
>>>>>>> like.
>>>>>>> >>
>>>>>>> >> On 31 October 2012 18:27, Freedom Dumlao <freedomdumlao@gmail.com>
>>>>>>> wrote:
>>>>>>> >> > Hey Flaskers,
>>>>>>> >> >
>>>>>>> >> > At the day job I came up with a class based views solution to
>>>>>>> meet some
>>>>>>> >> > of
>>>>>>> >> > the needs of our application.
>>>>>>> >> > I recently started a side project where I wanted to use the
>>>>>>> same thing
>>>>>>> >> > and
>>>>>>> >> > thought it might be time to start
>>>>>>> >> > extracting the functionality into a Flask extension others
>>>>>>> might find
>>>>>>> >> > useful
>>>>>>> >> > too.
>>>>>>> >> >
>>>>>>> >> > It takes a somewhat different approach to class based views
>>>>>>> than what
>>>>>>> >> > you
>>>>>>> >> > find in the flask.views namespace
>>>>>>> >> > so I'd really appreciate any feedback on the API and features.
>>>>>>> There are
>>>>>>> >> > a
>>>>>>> >> > couple of features I havent
>>>>>>> >> > extracted yet, specifically view wrapping, and template
>>>>>>> contexts, but
>>>>>>> >> > I'll
>>>>>>> >> > be getting to them pretty soon.
>>>>>>> >> >
>>>>>>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>>>>>>> >> >
>>>>>>> >> > I look forward to hearing what you think.
>>>>>>> >> >
>>>>>>> >> > - Freedom
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> --
>>>>>>> >> Sincerely,
>>>>>>> >> Igor Davydenko
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Sincerely,
>>>>>>> Igor Davydenko
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>

Re: [flask] An alternative approach to class based views

From:
Mark Grey
Date:
2012-11-09 @ 16:16
Freedom,

Any known issue with registering a FlaskView on a Blueprint instead of an
app directly?  Here is my usage.

WebService = Blueprint('webservice',__name__,subdomain='data')

@WebService.route('/')
def root():
    return Response('hello data!')

#Place FlaskView
class PlaceView(FlaskView):
    route_base = '/place'

    def get(self,place_id):
        try:
            pid = ObjectId(place_id)
            place = Place.collection.find_one({'_id':pid})
            return
Response([json.dumps(place,cls=Encoder,indent=4)],mimetype='application/json')
        except Exception as e:
            return
Response(json.dumps(e.message),mimetype='application/json')

PlaceView.register(WebService)


Doesn't seem to be routing properly though.  The blueprint in question is
attached at two subdomains.

On Thu, Nov 8, 2012 at 5:20 PM, Jesaja Everling <jeverling@gmail.com> wrote:

> Cool, automatic template folder lookup sounds exactly what I'm looking
> for! :)
> I have created a pull request on github with a small change, to only
> append an index to the route_name for custom routes if there is more than
> one.
>
> I'm not sure if it isn't better to stick with the behavior as it is now,
> because maybe it's better if a custom route always means an index will be
> added.
> On the other hand, most of the time people will probably define only one
> custom route, and for this cases it would be nicer without the index.
>
>
>
> On Thu, Nov 8, 2012 at 4:02 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>
>> Thanks Jesaja, I appreciate the feedback!
>>
>> So the template context idea is a two-fold feature, and works with the
>> class based "before_request" and "after_request" feature that is also in
>> development. It does automatically look for templates in the folder based
>> on the FlaskView but also it allows you to build up a context to send to
>> the template from any method that executes during the request cycle.
>>
>> As for the default id parameter name, you're completely right. I'll
>> change it before the next release in an update. It will be a breaking
>> change for some but I think it's better to fix that now instead of letting
>> it become a real problem once many people are using it.
>>
>> Freedom
>>
>>
>> On Tue, Nov 6, 2012 at 6:51 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>>
>>> The docs are a very entertaining read! I tried Flask-Classy today, and
>>> really like it so far! It feels very elegant.
>>> You wrote in your first post that you are planning to support template
>>> contexts. What exactly do you mean by this?
>>> What would be nice IMO was a way to specify a template folder, like I
>>> can do with a blueprint by passing the template_folder parameter.
>>> This can also be done manually by changing the Jinja2 environment, so
>>> it's no big deal, but it still would be nice to have, I think.
>>>
>>> I like how you automatically attach an index to the view name, if
>>> (multiple) routes are defined for a view.
>>>
>>> Just one suggestion: maybe it would be better to use some other name
>>> than "id" as parameter for the get method?
>>> It's no big deal, but pylint will complain about redefining a built-in.
>>> Maybe "item" or "obj_id" or something like this would be better.
>>>
>>> Thanks a lot for Flask-Classy!
>>>
>>> Best Regards,
>>>
>>> Jesaja Everling
>>>
>>>
>>>
>>>
>>> On Mon, Nov 5, 2012 at 5:04 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>>>
>>>> Thanks Mark.
>>>>
>>>> Take a look at the docs at 
http://packages.python.org/Flask-Classy/and see if they make sense. I've 
also fixed some bugs that I've found while
>>>> using it myself. Let me know what you think!
>>>>
>>>> - Freedom
>>>>
>>>>
>>>> On Mon, Nov 5, 2012 at 10:40 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>
>>>>> Freedom,
>>>>>
>>>>> I noticed on your github that you've started adding subdomain support.
>>>>>
>>>>> I am going to try implementing your extension for views today and will
>>>>> provide some testing info =)
>>>>>
>>>>>
>>>>> On Thu, Nov 1, 2012 at 12:31 PM, Owein Reese <owreese@gmail.com>wrote:
>>>>>
>>>>>> This really is nice. Like others have said, add subdomain support and
>>>>>> you'll have created something really special.
>>>>>> On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com> wrote:
>>>>>>
>>>>>>> Great work freedom - I echo what's been said - I think this ext
>>>>>>> provides a neat, easy to comprehend api when blueprints just don't quite
>>>>>>> fit.
>>>>>>>
>>>>>>> Well done :))
>>>>>>>
>>>>>>> Sent from my iPhone
>>>>>>>
>>>>>>> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com> wrote:
>>>>>>>
>>>>>>>  I actually just ran into this problem just now developing and am
>>>>>>> seriously considering converting my MethodViews to this ext.  I'm pulling
>>>>>>> for you here, Freedom.
>>>>>>>
>>>>>>> IMHO this is a significant improvement over the business about
>>>>>>> attaching MethodViews in the last paragraph at
>>>>>>> http://flask.pocoo.org/docs/views/.  Even refactored as
>>>>>>> demonstrated, that's still a lot of extra code just to get the 
routing down
>>>>>>> accurately, and the decorator syntax is still the most sexy way to attach
>>>>>>> the endpoints.
>>>>>>>
>>>>>>> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
>>>>>>> playpauseandstop@gmail.com> wrote:
>>>>>>>
>>>>>>>> Ok, thanks,
>>>>>>>>
>>>>>>>> Will wait on news here
>>>>>>>>
>>>>>>>> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com>
>>>>>>>> wrote:
>>>>>>>> > Thanks Igor, I look forward to hearing about your experiences.
>>>>>>>> >
>>>>>>>> > At present I don't have lazy view support, however I plan on
>>>>>>>> making the
>>>>>>>> > routing features a bit more maleable, and in doing so will
>>>>>>>> probably make it
>>>>>>>> > possible to create lazy views.
>>>>>>>> >
>>>>>>>> > - Freedom
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>>>>>>>> playpauseandstop@gmail.com>
>>>>>>>> > wrote:
>>>>>>>> >>
>>>>>>>> >> Looks very promising for me, will try in one of my current
>>>>>>>> projects.
>>>>>>>> >>
>>>>>>>> >> Only a quick question, has Flask-Classy an ability to register
>>>>>>>> views
>>>>>>>> >> lazy way, without View.register call?
>>>>>>>> >>
>>>>>>>> >> I mean, I like to use lazy views pattern (
>>>>>>>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>>>>>>>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my
>>>>>>>> views to
>>>>>>>> >> ``views`` module or package. But from first view in
>>>>>>>> ``Flask-Classy`` I
>>>>>>>> >> only can add url rules with explicitly View.register call, which
>>>>>>>> means
>>>>>>>> >> I need to import this class to application, which I don't really
>>>>>>>> like.
>>>>>>>> >>
>>>>>>>> >> On 31 October 2012 18:27, Freedom Dumlao <
>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>> >> > Hey Flaskers,
>>>>>>>> >> >
>>>>>>>> >> > At the day job I came up with a class based views solution to
>>>>>>>> meet some
>>>>>>>> >> > of
>>>>>>>> >> > the needs of our application.
>>>>>>>> >> > I recently started a side project where I wanted to use the
>>>>>>>> same thing
>>>>>>>> >> > and
>>>>>>>> >> > thought it might be time to start
>>>>>>>> >> > extracting the functionality into a Flask extension others
>>>>>>>> might find
>>>>>>>> >> > useful
>>>>>>>> >> > too.
>>>>>>>> >> >
>>>>>>>> >> > It takes a somewhat different approach to class based views
>>>>>>>> than what
>>>>>>>> >> > you
>>>>>>>> >> > find in the flask.views namespace
>>>>>>>> >> > so I'd really appreciate any feedback on the API and features.
>>>>>>>> There are
>>>>>>>> >> > a
>>>>>>>> >> > couple of features I havent
>>>>>>>> >> > extracted yet, specifically view wrapping, and template
>>>>>>>> contexts, but
>>>>>>>> >> > I'll
>>>>>>>> >> > be getting to them pretty soon.
>>>>>>>> >> >
>>>>>>>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>>>>>>>> >> >
>>>>>>>> >> > I look forward to hearing what you think.
>>>>>>>> >> >
>>>>>>>> >> > - Freedom
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> --
>>>>>>>> >> Sincerely,
>>>>>>>> >> Igor Davydenko
>>>>>>>> >
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Sincerely,
>>>>>>>> Igor Davydenko
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] An alternative approach to class based views

From:
Mark Grey
Date:
2012-11-09 @ 16:22
I got the routing to work by placing an additional `.register` call with
its own subdomain.

Just an observation, any way to make the views honor the subdomain/routing
assignments given to the blueprint they are attached to?

On Fri, Nov 9, 2012 at 11:16 AM, Mark Grey <mark.asperia@gmail.com> wrote:

> Freedom,
>
> Any known issue with registering a FlaskView on a Blueprint instead of an
> app directly?  Here is my usage.
>
> WebService = Blueprint('webservice',__name__,subdomain='data')
>
> @WebService.route('/')
> def root():
>     return Response('hello data!')
>
> #Place FlaskView
> class PlaceView(FlaskView):
>     route_base = '/place'
>
>     def get(self,place_id):
>         try:
>             pid = ObjectId(place_id)
>             place = Place.collection.find_one({'_id':pid})
>             return
> Response([json.dumps(place,cls=Encoder,indent=4)],mimetype='application/json')
>         except Exception as e:
>             return
> Response(json.dumps(e.message),mimetype='application/json')
>
> PlaceView.register(WebService)
>
>
> Doesn't seem to be routing properly though.  The blueprint in question is
> attached at two subdomains.
>
> On Thu, Nov 8, 2012 at 5:20 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>
>> Cool, automatic template folder lookup sounds exactly what I'm looking
>> for! :)
>> I have created a pull request on github with a small change, to only
>> append an index to the route_name for custom routes if there is more than
>> one.
>>
>> I'm not sure if it isn't better to stick with the behavior as it is now,
>> because maybe it's better if a custom route always means an index will be
>> added.
>> On the other hand, most of the time people will probably define only one
>> custom route, and for this cases it would be nicer without the index.
>>
>>
>>
>> On Thu, Nov 8, 2012 at 4:02 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>>
>>> Thanks Jesaja, I appreciate the feedback!
>>>
>>> So the template context idea is a two-fold feature, and works with the
>>> class based "before_request" and "after_request" feature that is also in
>>> development. It does automatically look for templates in the folder based
>>> on the FlaskView but also it allows you to build up a context to send to
>>> the template from any method that executes during the request cycle.
>>>
>>> As for the default id parameter name, you're completely right. I'll
>>> change it before the next release in an update. It will be a breaking
>>> change for some but I think it's better to fix that now instead of letting
>>> it become a real problem once many people are using it.
>>>
>>> Freedom
>>>
>>>
>>> On Tue, Nov 6, 2012 at 6:51 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>>>
>>>> The docs are a very entertaining read! I tried Flask-Classy today, and
>>>> really like it so far! It feels very elegant.
>>>> You wrote in your first post that you are planning to support template
>>>> contexts. What exactly do you mean by this?
>>>> What would be nice IMO was a way to specify a template folder, like I
>>>> can do with a blueprint by passing the template_folder parameter.
>>>> This can also be done manually by changing the Jinja2 environment, so
>>>> it's no big deal, but it still would be nice to have, I think.
>>>>
>>>> I like how you automatically attach an index to the view name, if
>>>> (multiple) routes are defined for a view.
>>>>
>>>> Just one suggestion: maybe it would be better to use some other name
>>>> than "id" as parameter for the get method?
>>>> It's no big deal, but pylint will complain about redefining a built-in.
>>>> Maybe "item" or "obj_id" or something like this would be better.
>>>>
>>>> Thanks a lot for Flask-Classy!
>>>>
>>>> Best Regards,
>>>>
>>>> Jesaja Everling
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Nov 5, 2012 at 5:04 PM, Freedom Dumlao <freedomdumlao@gmail.com
>>>> > wrote:
>>>>
>>>>> Thanks Mark.
>>>>>
>>>>> Take a look at the docs at 
http://packages.python.org/Flask-Classy/and see if they make sense. I've 
also fixed some bugs that I've found while
>>>>> using it myself. Let me know what you think!
>>>>>
>>>>> - Freedom
>>>>>
>>>>>
>>>>> On Mon, Nov 5, 2012 at 10:40 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>
>>>>>> Freedom,
>>>>>>
>>>>>> I noticed on your github that you've started adding subdomain support.
>>>>>>
>>>>>> I am going to try implementing your extension for views today and
>>>>>> will provide some testing info =)
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 1, 2012 at 12:31 PM, Owein Reese <owreese@gmail.com>wrote:
>>>>>>
>>>>>>> This really is nice. Like others have said, add subdomain support
>>>>>>> and you'll have created something really special.
>>>>>>> On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com> wrote:
>>>>>>>
>>>>>>>> Great work freedom - I echo what's been said - I think this ext
>>>>>>>> provides a neat, easy to comprehend api when blueprints just don't quite
>>>>>>>> fit.
>>>>>>>>
>>>>>>>> Well done :))
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com> wrote:
>>>>>>>>
>>>>>>>>  I actually just ran into this problem just now developing and am
>>>>>>>> seriously considering converting my MethodViews to this ext.  I'm pulling
>>>>>>>> for you here, Freedom.
>>>>>>>>
>>>>>>>> IMHO this is a significant improvement over the business about
>>>>>>>> attaching MethodViews in the last paragraph at
>>>>>>>> http://flask.pocoo.org/docs/views/.  Even refactored as
>>>>>>>> demonstrated, that's still a lot of extra code just to get the 
routing down
>>>>>>>> accurately, and the decorator syntax is still the most sexy way to attach
>>>>>>>> the endpoints.
>>>>>>>>
>>>>>>>> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
>>>>>>>> playpauseandstop@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Ok, thanks,
>>>>>>>>>
>>>>>>>>> Will wait on news here
>>>>>>>>>
>>>>>>>>> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> > Thanks Igor, I look forward to hearing about your experiences.
>>>>>>>>> >
>>>>>>>>> > At present I don't have lazy view support, however I plan on
>>>>>>>>> making the
>>>>>>>>> > routing features a bit more maleable, and in doing so will
>>>>>>>>> probably make it
>>>>>>>>> > possible to create lazy views.
>>>>>>>>> >
>>>>>>>>> > - Freedom
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>>>>>>>>> playpauseandstop@gmail.com>
>>>>>>>>> > wrote:
>>>>>>>>> >>
>>>>>>>>> >> Looks very promising for me, will try in one of my current
>>>>>>>>> projects.
>>>>>>>>> >>
>>>>>>>>> >> Only a quick question, has Flask-Classy an ability to register
>>>>>>>>> views
>>>>>>>>> >> lazy way, without View.register call?
>>>>>>>>> >>
>>>>>>>>> >> I mean, I like to use lazy views pattern (
>>>>>>>>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>>>>>>>>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my
>>>>>>>>> views to
>>>>>>>>> >> ``views`` module or package. But from first view in
>>>>>>>>> ``Flask-Classy`` I
>>>>>>>>> >> only can add url rules with explicitly View.register call,
>>>>>>>>> which means
>>>>>>>>> >> I need to import this class to application, which I don't
>>>>>>>>> really like.
>>>>>>>>> >>
>>>>>>>>> >> On 31 October 2012 18:27, Freedom Dumlao <
>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>> >> > Hey Flaskers,
>>>>>>>>> >> >
>>>>>>>>> >> > At the day job I came up with a class based views solution to
>>>>>>>>> meet some
>>>>>>>>> >> > of
>>>>>>>>> >> > the needs of our application.
>>>>>>>>> >> > I recently started a side project where I wanted to use the
>>>>>>>>> same thing
>>>>>>>>> >> > and
>>>>>>>>> >> > thought it might be time to start
>>>>>>>>> >> > extracting the functionality into a Flask extension others
>>>>>>>>> might find
>>>>>>>>> >> > useful
>>>>>>>>> >> > too.
>>>>>>>>> >> >
>>>>>>>>> >> > It takes a somewhat different approach to class based views
>>>>>>>>> than what
>>>>>>>>> >> > you
>>>>>>>>> >> > find in the flask.views namespace
>>>>>>>>> >> > so I'd really appreciate any feedback on the API and
>>>>>>>>> features. There are
>>>>>>>>> >> > a
>>>>>>>>> >> > couple of features I havent
>>>>>>>>> >> > extracted yet, specifically view wrapping, and template
>>>>>>>>> contexts, but
>>>>>>>>> >> > I'll
>>>>>>>>> >> > be getting to them pretty soon.
>>>>>>>>> >> >
>>>>>>>>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>>>>>>>>> >> >
>>>>>>>>> >> > I look forward to hearing what you think.
>>>>>>>>> >> >
>>>>>>>>> >> > - Freedom
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> --
>>>>>>>>> >> Sincerely,
>>>>>>>>> >> Igor Davydenko
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Sincerely,
>>>>>>>>> Igor Davydenko
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] An alternative approach to class based views

From:
Freedom Dumlao
Date:
2012-11-09 @ 21:26
Hi Mark,

I don't have any tests written for using it with blueprints - that sounds
like an issue I need to address right away. There's a couple of other
things I've just finished up as well that I was planning on releasing
tonight, I'll add blueprint tests and fix whatever the bug is before I do
that release.

Thanks for the heads up!


On Fri, Nov 9, 2012 at 11:22 AM, Mark Grey <mark.asperia@gmail.com> wrote:

> I got the routing to work by placing an additional `.register` call with
> its own subdomain.
>
> Just an observation, any way to make the views honor the subdomain/routing
> assignments given to the blueprint they are attached to?
>
>
> On Fri, Nov 9, 2012 at 11:16 AM, Mark Grey <mark.asperia@gmail.com> wrote:
>
>> Freedom,
>>
>> Any known issue with registering a FlaskView on a Blueprint instead of an
>> app directly?  Here is my usage.
>>
>> WebService = Blueprint('webservice',__name__,subdomain='data')
>>
>> @WebService.route('/')
>> def root():
>>     return Response('hello data!')
>>
>> #Place FlaskView
>> class PlaceView(FlaskView):
>>     route_base = '/place'
>>
>>     def get(self,place_id):
>>         try:
>>             pid = ObjectId(place_id)
>>             place = Place.collection.find_one({'_id':pid})
>>             return
>> Response([json.dumps(place,cls=Encoder,indent=4)],mimetype='application/json')
>>         except Exception as e:
>>             return
>> Response(json.dumps(e.message),mimetype='application/json')
>>
>> PlaceView.register(WebService)
>>
>>
>> Doesn't seem to be routing properly though.  The blueprint in question is
>> attached at two subdomains.
>>
>> On Thu, Nov 8, 2012 at 5:20 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>>
>>> Cool, automatic template folder lookup sounds exactly what I'm looking
>>> for! :)
>>> I have created a pull request on github with a small change, to only
>>> append an index to the route_name for custom routes if there is more than
>>> one.
>>>
>>> I'm not sure if it isn't better to stick with the behavior as it is now,
>>> because maybe it's better if a custom route always means an index will be
>>> added.
>>> On the other hand, most of the time people will probably define only one
>>> custom route, and for this cases it would be nicer without the index.
>>>
>>>
>>>
>>> On Thu, Nov 8, 2012 at 4:02 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>>>
>>>> Thanks Jesaja, I appreciate the feedback!
>>>>
>>>> So the template context idea is a two-fold feature, and works with the
>>>> class based "before_request" and "after_request" feature that is also in
>>>> development. It does automatically look for templates in the folder based
>>>> on the FlaskView but also it allows you to build up a context to send to
>>>> the template from any method that executes during the request cycle.
>>>>
>>>> As for the default id parameter name, you're completely right. I'll
>>>> change it before the next release in an update. It will be a breaking
>>>> change for some but I think it's better to fix that now instead of letting
>>>> it become a real problem once many people are using it.
>>>>
>>>> Freedom
>>>>
>>>>
>>>> On Tue, Nov 6, 2012 at 6:51 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>>>>
>>>>> The docs are a very entertaining read! I tried Flask-Classy today, and
>>>>> really like it so far! It feels very elegant.
>>>>> You wrote in your first post that you are planning to support template
>>>>> contexts. What exactly do you mean by this?
>>>>> What would be nice IMO was a way to specify a template folder, like I
>>>>> can do with a blueprint by passing the template_folder parameter.
>>>>> This can also be done manually by changing the Jinja2 environment, so
>>>>> it's no big deal, but it still would be nice to have, I think.
>>>>>
>>>>> I like how you automatically attach an index to the view name, if
>>>>> (multiple) routes are defined for a view.
>>>>>
>>>>> Just one suggestion: maybe it would be better to use some other name
>>>>> than "id" as parameter for the get method?
>>>>> It's no big deal, but pylint will complain about redefining a built-in.
>>>>> Maybe "item" or "obj_id" or something like this would be better.
>>>>>
>>>>> Thanks a lot for Flask-Classy!
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Jesaja Everling
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 5, 2012 at 5:04 PM, Freedom Dumlao <
>>>>> freedomdumlao@gmail.com> wrote:
>>>>>
>>>>>> Thanks Mark.
>>>>>>
>>>>>> Take a look at the docs at 
http://packages.python.org/Flask-Classy/and see if they make sense. I've 
also fixed some bugs that I've found while
>>>>>> using it myself. Let me know what you think!
>>>>>>
>>>>>> - Freedom
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 5, 2012 at 10:40 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>>
>>>>>>> Freedom,
>>>>>>>
>>>>>>> I noticed on your github that you've started adding subdomain
>>>>>>> support.
>>>>>>>
>>>>>>> I am going to try implementing your extension for views today and
>>>>>>> will provide some testing info =)
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 1, 2012 at 12:31 PM, Owein Reese <owreese@gmail.com>wrote:
>>>>>>>
>>>>>>>> This really is nice. Like others have said, add subdomain support
>>>>>>>> and you'll have created something really special.
>>>>>>>> On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Great work freedom - I echo what's been said - I think this ext
>>>>>>>>> provides a neat, easy to comprehend api when blueprints just don't quite
>>>>>>>>> fit.
>>>>>>>>>
>>>>>>>>> Well done :))
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>  I actually just ran into this problem just now developing and am
>>>>>>>>> seriously considering converting my MethodViews to this ext.  
I'm pulling
>>>>>>>>> for you here, Freedom.
>>>>>>>>>
>>>>>>>>> IMHO this is a significant improvement over the business about
>>>>>>>>> attaching MethodViews in the last paragraph at
>>>>>>>>> http://flask.pocoo.org/docs/views/.  Even refactored as
>>>>>>>>> demonstrated, that's still a lot of extra code just to get the 
routing down
>>>>>>>>> accurately, and the decorator syntax is still the most sexy way 
to attach
>>>>>>>>> the endpoints.
>>>>>>>>>
>>>>>>>>> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
>>>>>>>>> playpauseandstop@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Ok, thanks,
>>>>>>>>>>
>>>>>>>>>> Will wait on news here
>>>>>>>>>>
>>>>>>>>>> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> > Thanks Igor, I look forward to hearing about your experiences.
>>>>>>>>>> >
>>>>>>>>>> > At present I don't have lazy view support, however I plan on
>>>>>>>>>> making the
>>>>>>>>>> > routing features a bit more maleable, and in doing so will
>>>>>>>>>> probably make it
>>>>>>>>>> > possible to create lazy views.
>>>>>>>>>> >
>>>>>>>>>> > - Freedom
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>>>>>>>>>> playpauseandstop@gmail.com>
>>>>>>>>>> > wrote:
>>>>>>>>>> >>
>>>>>>>>>> >> Looks very promising for me, will try in one of my current
>>>>>>>>>> projects.
>>>>>>>>>> >>
>>>>>>>>>> >> Only a quick question, has Flask-Classy an ability to register
>>>>>>>>>> views
>>>>>>>>>> >> lazy way, without View.register call?
>>>>>>>>>> >>
>>>>>>>>>> >> I mean, I like to use lazy views pattern (
>>>>>>>>>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>>>>>>>>>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my
>>>>>>>>>> views to
>>>>>>>>>> >> ``views`` module or package. But from first view in
>>>>>>>>>> ``Flask-Classy`` I
>>>>>>>>>> >> only can add url rules with explicitly View.register call,
>>>>>>>>>> which means
>>>>>>>>>> >> I need to import this class to application, which I don't
>>>>>>>>>> really like.
>>>>>>>>>> >>
>>>>>>>>>> >> On 31 October 2012 18:27, Freedom Dumlao <
>>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>> >> > Hey Flaskers,
>>>>>>>>>> >> >
>>>>>>>>>> >> > At the day job I came up with a class based views solution
>>>>>>>>>> to meet some
>>>>>>>>>> >> > of
>>>>>>>>>> >> > the needs of our application.
>>>>>>>>>> >> > I recently started a side project where I wanted to use the
>>>>>>>>>> same thing
>>>>>>>>>> >> > and
>>>>>>>>>> >> > thought it might be time to start
>>>>>>>>>> >> > extracting the functionality into a Flask extension others
>>>>>>>>>> might find
>>>>>>>>>> >> > useful
>>>>>>>>>> >> > too.
>>>>>>>>>> >> >
>>>>>>>>>> >> > It takes a somewhat different approach to class based views
>>>>>>>>>> than what
>>>>>>>>>> >> > you
>>>>>>>>>> >> > find in the flask.views namespace
>>>>>>>>>> >> > so I'd really appreciate any feedback on the API and
>>>>>>>>>> features. There are
>>>>>>>>>> >> > a
>>>>>>>>>> >> > couple of features I havent
>>>>>>>>>> >> > extracted yet, specifically view wrapping, and template
>>>>>>>>>> contexts, but
>>>>>>>>>> >> > I'll
>>>>>>>>>> >> > be getting to them pretty soon.
>>>>>>>>>> >> >
>>>>>>>>>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>>>>>>>>>> >> >
>>>>>>>>>> >> > I look forward to hearing what you think.
>>>>>>>>>> >> >
>>>>>>>>>> >> > - Freedom
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> --
>>>>>>>>>> >> Sincerely,
>>>>>>>>>> >> Igor Davydenko
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sincerely,
>>>>>>>>>> Igor Davydenko
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] An alternative approach to class based views

From:
Freedom Dumlao
Date:
2012-11-12 @ 00:32
Hey Mark,

I added a bunch of tests and found the problem with blueprints +
subdomains. I've pushed the change to the github repo but haven't pushed a
release with it yet. You can check it out here:

https://github.com/apiguy/flask-classy/commit/8c3362b0c93766077f8ed15892f46e419de05711

Freedom


On Fri, Nov 9, 2012 at 4:26 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> Hi Mark,
>
> I don't have any tests written for using it with blueprints - that sounds
> like an issue I need to address right away. There's a couple of other
> things I've just finished up as well that I was planning on releasing
> tonight, I'll add blueprint tests and fix whatever the bug is before I do
> that release.
>
> Thanks for the heads up!
>
>
> On Fri, Nov 9, 2012 at 11:22 AM, Mark Grey <mark.asperia@gmail.com> wrote:
>
>> I got the routing to work by placing an additional `.register` call with
>> its own subdomain.
>>
>> Just an observation, any way to make the views honor the
>> subdomain/routing assignments given to the blueprint they are attached to?
>>
>>
>> On Fri, Nov 9, 2012 at 11:16 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>
>>> Freedom,
>>>
>>> Any known issue with registering a FlaskView on a Blueprint instead of
>>> an app directly?  Here is my usage.
>>>
>>> WebService = Blueprint('webservice',__name__,subdomain='data')
>>>
>>> @WebService.route('/')
>>> def root():
>>>     return Response('hello data!')
>>>
>>> #Place FlaskView
>>> class PlaceView(FlaskView):
>>>     route_base = '/place'
>>>
>>>     def get(self,place_id):
>>>         try:
>>>             pid = ObjectId(place_id)
>>>             place = Place.collection.find_one({'_id':pid})
>>>             return
>>> Response([json.dumps(place,cls=Encoder,indent=4)],mimetype='application/json')
>>>         except Exception as e:
>>>             return
>>> Response(json.dumps(e.message),mimetype='application/json')
>>>
>>> PlaceView.register(WebService)
>>>
>>>
>>> Doesn't seem to be routing properly though.  The blueprint in question
>>> is attached at two subdomains.
>>>
>>> On Thu, Nov 8, 2012 at 5:20 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>>>
>>>> Cool, automatic template folder lookup sounds exactly what I'm looking
>>>> for! :)
>>>> I have created a pull request on github with a small change, to only
>>>> append an index to the route_name for custom routes if there is more than
>>>> one.
>>>>
>>>> I'm not sure if it isn't better to stick with the behavior as it is
>>>> now, because maybe it's better if a custom route always means an index will
>>>> be added.
>>>> On the other hand, most of the time people will probably define only
>>>> one custom route, and for this cases it would be nicer without the index.
>>>>
>>>>
>>>>
>>>> On Thu, Nov 8, 2012 at 4:02 PM, Freedom Dumlao <freedomdumlao@gmail.com
>>>> > wrote:
>>>>
>>>>> Thanks Jesaja, I appreciate the feedback!
>>>>>
>>>>> So the template context idea is a two-fold feature, and works with the
>>>>> class based "before_request" and "after_request" feature that is also in
>>>>> development. It does automatically look for templates in the folder based
>>>>> on the FlaskView but also it allows you to build up a context to send to
>>>>> the template from any method that executes during the request cycle.
>>>>>
>>>>> As for the default id parameter name, you're completely right. I'll
>>>>> change it before the next release in an update. It will be a breaking
>>>>> change for some but I think it's better to fix that now instead of letting
>>>>> it become a real problem once many people are using it.
>>>>>
>>>>> Freedom
>>>>>
>>>>>
>>>>> On Tue, Nov 6, 2012 at 6:51 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>>>>>
>>>>>> The docs are a very entertaining read! I tried Flask-Classy today,
>>>>>> and really like it so far! It feels very elegant.
>>>>>> You wrote in your first post that you are planning to support
>>>>>> template contexts. What exactly do you mean by this?
>>>>>> What would be nice IMO was a way to specify a template folder, like I
>>>>>> can do with a blueprint by passing the template_folder parameter.
>>>>>> This can also be done manually by changing the Jinja2 environment, so
>>>>>> it's no big deal, but it still would be nice to have, I think.
>>>>>>
>>>>>> I like how you automatically attach an index to the view name, if
>>>>>> (multiple) routes are defined for a view.
>>>>>>
>>>>>> Just one suggestion: maybe it would be better to use some other name
>>>>>> than "id" as parameter for the get method?
>>>>>> It's no big deal, but pylint will complain about redefining a
>>>>>> built-in.
>>>>>> Maybe "item" or "obj_id" or something like this would be better.
>>>>>>
>>>>>> Thanks a lot for Flask-Classy!
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Jesaja Everling
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 5, 2012 at 5:04 PM, Freedom Dumlao <
>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>
>>>>>>> Thanks Mark.
>>>>>>>
>>>>>>> Take a look at the docs at 
http://packages.python.org/Flask-Classy/and see if they make sense. I've 
also fixed some bugs that I've found while
>>>>>>> using it myself. Let me know what you think!
>>>>>>>
>>>>>>> - Freedom
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 5, 2012 at 10:40 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>>>
>>>>>>>> Freedom,
>>>>>>>>
>>>>>>>> I noticed on your github that you've started adding subdomain
>>>>>>>> support.
>>>>>>>>
>>>>>>>> I am going to try implementing your extension for views today and
>>>>>>>> will provide some testing info =)
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Nov 1, 2012 at 12:31 PM, Owein Reese <owreese@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> This really is nice. Like others have said, add subdomain support
>>>>>>>>> and you'll have created something really special.
>>>>>>>>> On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Great work freedom - I echo what's been said - I think this ext
>>>>>>>>>> provides a neat, easy to comprehend api when blueprints just 
don't quite
>>>>>>>>>> fit.
>>>>>>>>>>
>>>>>>>>>> Well done :))
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>  I actually just ran into this problem just now developing and
>>>>>>>>>> am seriously considering converting my MethodViews to this ext.  I'm
>>>>>>>>>> pulling for you here, Freedom.
>>>>>>>>>>
>>>>>>>>>> IMHO this is a significant improvement over the business about
>>>>>>>>>> attaching MethodViews in the last paragraph at
>>>>>>>>>> http://flask.pocoo.org/docs/views/.  Even refactored as
>>>>>>>>>> demonstrated, that's still a lot of extra code just to get the 
routing down
>>>>>>>>>> accurately, and the decorator syntax is still the most sexy way
to attach
>>>>>>>>>> the endpoints.
>>>>>>>>>>
>>>>>>>>>> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
>>>>>>>>>> playpauseandstop@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Ok, thanks,
>>>>>>>>>>>
>>>>>>>>>>> Will wait on news here
>>>>>>>>>>>
>>>>>>>>>>> On 31 October 2012 19:53, Freedom Dumlao <
>>>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>>> > Thanks Igor, I look forward to hearing about your experiences.
>>>>>>>>>>> >
>>>>>>>>>>> > At present I don't have lazy view support, however I plan on
>>>>>>>>>>> making the
>>>>>>>>>>> > routing features a bit more maleable, and in doing so will
>>>>>>>>>>> probably make it
>>>>>>>>>>> > possible to create lazy views.
>>>>>>>>>>> >
>>>>>>>>>>> > - Freedom
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>>>>>>>>>>> playpauseandstop@gmail.com>
>>>>>>>>>>> > wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >> Looks very promising for me, will try in one of my current
>>>>>>>>>>> projects.
>>>>>>>>>>> >>
>>>>>>>>>>> >> Only a quick question, has Flask-Classy an ability to
>>>>>>>>>>> register views
>>>>>>>>>>> >> lazy way, without View.register call?
>>>>>>>>>>> >>
>>>>>>>>>>> >> I mean, I like to use lazy views pattern (
>>>>>>>>>>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>>>>>>>>>>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my
>>>>>>>>>>> views to
>>>>>>>>>>> >> ``views`` module or package. But from first view in
>>>>>>>>>>> ``Flask-Classy`` I
>>>>>>>>>>> >> only can add url rules with explicitly View.register call,
>>>>>>>>>>> which means
>>>>>>>>>>> >> I need to import this class to application, which I don't
>>>>>>>>>>> really like.
>>>>>>>>>>> >>
>>>>>>>>>>> >> On 31 October 2012 18:27, Freedom Dumlao <
>>>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>>> >> > Hey Flaskers,
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > At the day job I came up with a class based views solution
>>>>>>>>>>> to meet some
>>>>>>>>>>> >> > of
>>>>>>>>>>> >> > the needs of our application.
>>>>>>>>>>> >> > I recently started a side project where I wanted to use the
>>>>>>>>>>> same thing
>>>>>>>>>>> >> > and
>>>>>>>>>>> >> > thought it might be time to start
>>>>>>>>>>> >> > extracting the functionality into a Flask extension others
>>>>>>>>>>> might find
>>>>>>>>>>> >> > useful
>>>>>>>>>>> >> > too.
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > It takes a somewhat different approach to class based views
>>>>>>>>>>> than what
>>>>>>>>>>> >> > you
>>>>>>>>>>> >> > find in the flask.views namespace
>>>>>>>>>>> >> > so I'd really appreciate any feedback on the API and
>>>>>>>>>>> features. There are
>>>>>>>>>>> >> > a
>>>>>>>>>>> >> > couple of features I havent
>>>>>>>>>>> >> > extracted yet, specifically view wrapping, and template
>>>>>>>>>>> contexts, but
>>>>>>>>>>> >> > I'll
>>>>>>>>>>> >> > be getting to them pretty soon.
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > I look forward to hearing what you think.
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > - Freedom
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> --
>>>>>>>>>>> >> Sincerely,
>>>>>>>>>>> >> Igor Davydenko
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Sincerely,
>>>>>>>>>>> Igor Davydenko
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] An alternative approach to class based views

From:
Freedom Dumlao
Date:
2012-11-12 @ 00:57
Mark,

I went ahead and pushed a version to pypi (0.4.3) that includes that fix.
There's also a new feature in this release - view wrappers.

Hope it helps :)

Freedom


On Fri, Nov 9, 2012 at 11:16 AM, Mark Grey <mark.asperia@gmail.com> wrote:

> Freedom,
>
> Any known issue with registering a FlaskView on a Blueprint instead of an
> app directly?  Here is my usage.
>
> WebService = Blueprint('webservice',__name__,subdomain='data')
>
> @WebService.route('/')
> def root():
>     return Response('hello data!')
>
> #Place FlaskView
> class PlaceView(FlaskView):
>     route_base = '/place'
>
>     def get(self,place_id):
>         try:
>             pid = ObjectId(place_id)
>             place = Place.collection.find_one({'_id':pid})
>             return
> Response([json.dumps(place,cls=Encoder,indent=4)],mimetype='application/json')
>         except Exception as e:
>             return
> Response(json.dumps(e.message),mimetype='application/json')
>
> PlaceView.register(WebService)
>
>
> Doesn't seem to be routing properly though.  The blueprint in question is
> attached at two subdomains.
>
> On Thu, Nov 8, 2012 at 5:20 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>
>> Cool, automatic template folder lookup sounds exactly what I'm looking
>> for! :)
>> I have created a pull request on github with a small change, to only
>> append an index to the route_name for custom routes if there is more than
>> one.
>>
>> I'm not sure if it isn't better to stick with the behavior as it is now,
>> because maybe it's better if a custom route always means an index will be
>> added.
>> On the other hand, most of the time people will probably define only one
>> custom route, and for this cases it would be nicer without the index.
>>
>>
>>
>> On Thu, Nov 8, 2012 at 4:02 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>>
>>> Thanks Jesaja, I appreciate the feedback!
>>>
>>> So the template context idea is a two-fold feature, and works with the
>>> class based "before_request" and "after_request" feature that is also in
>>> development. It does automatically look for templates in the folder based
>>> on the FlaskView but also it allows you to build up a context to send to
>>> the template from any method that executes during the request cycle.
>>>
>>> As for the default id parameter name, you're completely right. I'll
>>> change it before the next release in an update. It will be a breaking
>>> change for some but I think it's better to fix that now instead of letting
>>> it become a real problem once many people are using it.
>>>
>>> Freedom
>>>
>>>
>>> On Tue, Nov 6, 2012 at 6:51 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>>>
>>>> The docs are a very entertaining read! I tried Flask-Classy today, and
>>>> really like it so far! It feels very elegant.
>>>> You wrote in your first post that you are planning to support template
>>>> contexts. What exactly do you mean by this?
>>>> What would be nice IMO was a way to specify a template folder, like I
>>>> can do with a blueprint by passing the template_folder parameter.
>>>> This can also be done manually by changing the Jinja2 environment, so
>>>> it's no big deal, but it still would be nice to have, I think.
>>>>
>>>> I like how you automatically attach an index to the view name, if
>>>> (multiple) routes are defined for a view.
>>>>
>>>> Just one suggestion: maybe it would be better to use some other name
>>>> than "id" as parameter for the get method?
>>>> It's no big deal, but pylint will complain about redefining a built-in.
>>>> Maybe "item" or "obj_id" or something like this would be better.
>>>>
>>>> Thanks a lot for Flask-Classy!
>>>>
>>>> Best Regards,
>>>>
>>>> Jesaja Everling
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Nov 5, 2012 at 5:04 PM, Freedom Dumlao <freedomdumlao@gmail.com
>>>> > wrote:
>>>>
>>>>> Thanks Mark.
>>>>>
>>>>> Take a look at the docs at 
http://packages.python.org/Flask-Classy/and see if they make sense. I've 
also fixed some bugs that I've found while
>>>>> using it myself. Let me know what you think!
>>>>>
>>>>> - Freedom
>>>>>
>>>>>
>>>>> On Mon, Nov 5, 2012 at 10:40 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>
>>>>>> Freedom,
>>>>>>
>>>>>> I noticed on your github that you've started adding subdomain support.
>>>>>>
>>>>>> I am going to try implementing your extension for views today and
>>>>>> will provide some testing info =)
>>>>>>
>>>>>>
>>>>>> On Thu, Nov 1, 2012 at 12:31 PM, Owein Reese <owreese@gmail.com>wrote:
>>>>>>
>>>>>>> This really is nice. Like others have said, add subdomain support
>>>>>>> and you'll have created something really special.
>>>>>>> On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com> wrote:
>>>>>>>
>>>>>>>> Great work freedom - I echo what's been said - I think this ext
>>>>>>>> provides a neat, easy to comprehend api when blueprints just don't quite
>>>>>>>> fit.
>>>>>>>>
>>>>>>>> Well done :))
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com> wrote:
>>>>>>>>
>>>>>>>>  I actually just ran into this problem just now developing and am
>>>>>>>> seriously considering converting my MethodViews to this ext.  I'm pulling
>>>>>>>> for you here, Freedom.
>>>>>>>>
>>>>>>>> IMHO this is a significant improvement over the business about
>>>>>>>> attaching MethodViews in the last paragraph at
>>>>>>>> http://flask.pocoo.org/docs/views/.  Even refactored as
>>>>>>>> demonstrated, that's still a lot of extra code just to get the 
routing down
>>>>>>>> accurately, and the decorator syntax is still the most sexy way to attach
>>>>>>>> the endpoints.
>>>>>>>>
>>>>>>>> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
>>>>>>>> playpauseandstop@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Ok, thanks,
>>>>>>>>>
>>>>>>>>> Will wait on news here
>>>>>>>>>
>>>>>>>>> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> > Thanks Igor, I look forward to hearing about your experiences.
>>>>>>>>> >
>>>>>>>>> > At present I don't have lazy view support, however I plan on
>>>>>>>>> making the
>>>>>>>>> > routing features a bit more maleable, and in doing so will
>>>>>>>>> probably make it
>>>>>>>>> > possible to create lazy views.
>>>>>>>>> >
>>>>>>>>> > - Freedom
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>>>>>>>>> playpauseandstop@gmail.com>
>>>>>>>>> > wrote:
>>>>>>>>> >>
>>>>>>>>> >> Looks very promising for me, will try in one of my current
>>>>>>>>> projects.
>>>>>>>>> >>
>>>>>>>>> >> Only a quick question, has Flask-Classy an ability to register
>>>>>>>>> views
>>>>>>>>> >> lazy way, without View.register call?
>>>>>>>>> >>
>>>>>>>>> >> I mean, I like to use lazy views pattern (
>>>>>>>>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>>>>>>>>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my
>>>>>>>>> views to
>>>>>>>>> >> ``views`` module or package. But from first view in
>>>>>>>>> ``Flask-Classy`` I
>>>>>>>>> >> only can add url rules with explicitly View.register call,
>>>>>>>>> which means
>>>>>>>>> >> I need to import this class to application, which I don't
>>>>>>>>> really like.
>>>>>>>>> >>
>>>>>>>>> >> On 31 October 2012 18:27, Freedom Dumlao <
>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>> >> > Hey Flaskers,
>>>>>>>>> >> >
>>>>>>>>> >> > At the day job I came up with a class based views solution to
>>>>>>>>> meet some
>>>>>>>>> >> > of
>>>>>>>>> >> > the needs of our application.
>>>>>>>>> >> > I recently started a side project where I wanted to use the
>>>>>>>>> same thing
>>>>>>>>> >> > and
>>>>>>>>> >> > thought it might be time to start
>>>>>>>>> >> > extracting the functionality into a Flask extension others
>>>>>>>>> might find
>>>>>>>>> >> > useful
>>>>>>>>> >> > too.
>>>>>>>>> >> >
>>>>>>>>> >> > It takes a somewhat different approach to class based views
>>>>>>>>> than what
>>>>>>>>> >> > you
>>>>>>>>> >> > find in the flask.views namespace
>>>>>>>>> >> > so I'd really appreciate any feedback on the API and
>>>>>>>>> features. There are
>>>>>>>>> >> > a
>>>>>>>>> >> > couple of features I havent
>>>>>>>>> >> > extracted yet, specifically view wrapping, and template
>>>>>>>>> contexts, but
>>>>>>>>> >> > I'll
>>>>>>>>> >> > be getting to them pretty soon.
>>>>>>>>> >> >
>>>>>>>>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>>>>>>>>> >> >
>>>>>>>>> >> > I look forward to hearing what you think.
>>>>>>>>> >> >
>>>>>>>>> >> > - Freedom
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> --
>>>>>>>>> >> Sincerely,
>>>>>>>>> >> Igor Davydenko
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Sincerely,
>>>>>>>>> Igor Davydenko
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] An alternative approach to class based views

From:
Mark Grey
Date:
2012-11-13 @ 15:43
Freedom,

I've been working with Classy for the past few days and I have assembled
some ideas... but I'm going to install your latest into the virtualenv
before making a fool of myself by discussing something you've already
gotten to.

Great work btw!

Mark

On Sun, Nov 11, 2012 at 7:57 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> Mark,
>
> I went ahead and pushed a version to pypi (0.4.3) that includes that fix.
> There's also a new feature in this release - view wrappers.
>
> Hope it helps :)
>
> Freedom
>
>
> On Fri, Nov 9, 2012 at 11:16 AM, Mark Grey <mark.asperia@gmail.com> wrote:
>
>> Freedom,
>>
>> Any known issue with registering a FlaskView on a Blueprint instead of an
>> app directly?  Here is my usage.
>>
>> WebService = Blueprint('webservice',__name__,subdomain='data')
>>
>> @WebService.route('/')
>> def root():
>>     return Response('hello data!')
>>
>> #Place FlaskView
>> class PlaceView(FlaskView):
>>     route_base = '/place'
>>
>>     def get(self,place_id):
>>         try:
>>             pid = ObjectId(place_id)
>>             place = Place.collection.find_one({'_id':pid})
>>             return
>> Response([json.dumps(place,cls=Encoder,indent=4)],mimetype='application/json')
>>         except Exception as e:
>>             return
>> Response(json.dumps(e.message),mimetype='application/json')
>>
>> PlaceView.register(WebService)
>>
>>
>> Doesn't seem to be routing properly though.  The blueprint in question is
>> attached at two subdomains.
>>
>> On Thu, Nov 8, 2012 at 5:20 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>>
>>> Cool, automatic template folder lookup sounds exactly what I'm looking
>>> for! :)
>>> I have created a pull request on github with a small change, to only
>>> append an index to the route_name for custom routes if there is more than
>>> one.
>>>
>>> I'm not sure if it isn't better to stick with the behavior as it is now,
>>> because maybe it's better if a custom route always means an index will be
>>> added.
>>> On the other hand, most of the time people will probably define only one
>>> custom route, and for this cases it would be nicer without the index.
>>>
>>>
>>>
>>> On Thu, Nov 8, 2012 at 4:02 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>>>
>>>> Thanks Jesaja, I appreciate the feedback!
>>>>
>>>> So the template context idea is a two-fold feature, and works with the
>>>> class based "before_request" and "after_request" feature that is also in
>>>> development. It does automatically look for templates in the folder based
>>>> on the FlaskView but also it allows you to build up a context to send to
>>>> the template from any method that executes during the request cycle.
>>>>
>>>> As for the default id parameter name, you're completely right. I'll
>>>> change it before the next release in an update. It will be a breaking
>>>> change for some but I think it's better to fix that now instead of letting
>>>> it become a real problem once many people are using it.
>>>>
>>>> Freedom
>>>>
>>>>
>>>> On Tue, Nov 6, 2012 at 6:51 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>>>>
>>>>> The docs are a very entertaining read! I tried Flask-Classy today, and
>>>>> really like it so far! It feels very elegant.
>>>>> You wrote in your first post that you are planning to support template
>>>>> contexts. What exactly do you mean by this?
>>>>> What would be nice IMO was a way to specify a template folder, like I
>>>>> can do with a blueprint by passing the template_folder parameter.
>>>>> This can also be done manually by changing the Jinja2 environment, so
>>>>> it's no big deal, but it still would be nice to have, I think.
>>>>>
>>>>> I like how you automatically attach an index to the view name, if
>>>>> (multiple) routes are defined for a view.
>>>>>
>>>>> Just one suggestion: maybe it would be better to use some other name
>>>>> than "id" as parameter for the get method?
>>>>> It's no big deal, but pylint will complain about redefining a built-in.
>>>>> Maybe "item" or "obj_id" or something like this would be better.
>>>>>
>>>>> Thanks a lot for Flask-Classy!
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Jesaja Everling
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Nov 5, 2012 at 5:04 PM, Freedom Dumlao <
>>>>> freedomdumlao@gmail.com> wrote:
>>>>>
>>>>>> Thanks Mark.
>>>>>>
>>>>>> Take a look at the docs at 
http://packages.python.org/Flask-Classy/and see if they make sense. I've 
also fixed some bugs that I've found while
>>>>>> using it myself. Let me know what you think!
>>>>>>
>>>>>> - Freedom
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 5, 2012 at 10:40 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>>
>>>>>>> Freedom,
>>>>>>>
>>>>>>> I noticed on your github that you've started adding subdomain
>>>>>>> support.
>>>>>>>
>>>>>>> I am going to try implementing your extension for views today and
>>>>>>> will provide some testing info =)
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Nov 1, 2012 at 12:31 PM, Owein Reese <owreese@gmail.com>wrote:
>>>>>>>
>>>>>>>> This really is nice. Like others have said, add subdomain support
>>>>>>>> and you'll have created something really special.
>>>>>>>> On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Great work freedom - I echo what's been said - I think this ext
>>>>>>>>> provides a neat, easy to comprehend api when blueprints just don't quite
>>>>>>>>> fit.
>>>>>>>>>
>>>>>>>>> Well done :))
>>>>>>>>>
>>>>>>>>> Sent from my iPhone
>>>>>>>>>
>>>>>>>>> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>  I actually just ran into this problem just now developing and am
>>>>>>>>> seriously considering converting my MethodViews to this ext.  
I'm pulling
>>>>>>>>> for you here, Freedom.
>>>>>>>>>
>>>>>>>>> IMHO this is a significant improvement over the business about
>>>>>>>>> attaching MethodViews in the last paragraph at
>>>>>>>>> http://flask.pocoo.org/docs/views/.  Even refactored as
>>>>>>>>> demonstrated, that's still a lot of extra code just to get the 
routing down
>>>>>>>>> accurately, and the decorator syntax is still the most sexy way 
to attach
>>>>>>>>> the endpoints.
>>>>>>>>>
>>>>>>>>> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
>>>>>>>>> playpauseandstop@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Ok, thanks,
>>>>>>>>>>
>>>>>>>>>> Will wait on news here
>>>>>>>>>>
>>>>>>>>>> On 31 October 2012 19:53, Freedom Dumlao <freedomdumlao@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> > Thanks Igor, I look forward to hearing about your experiences.
>>>>>>>>>> >
>>>>>>>>>> > At present I don't have lazy view support, however I plan on
>>>>>>>>>> making the
>>>>>>>>>> > routing features a bit more maleable, and in doing so will
>>>>>>>>>> probably make it
>>>>>>>>>> > possible to create lazy views.
>>>>>>>>>> >
>>>>>>>>>> > - Freedom
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>>>>>>>>>> playpauseandstop@gmail.com>
>>>>>>>>>> > wrote:
>>>>>>>>>> >>
>>>>>>>>>> >> Looks very promising for me, will try in one of my current
>>>>>>>>>> projects.
>>>>>>>>>> >>
>>>>>>>>>> >> Only a quick question, has Flask-Classy an ability to register
>>>>>>>>>> views
>>>>>>>>>> >> lazy way, without View.register call?
>>>>>>>>>> >>
>>>>>>>>>> >> I mean, I like to use lazy views pattern (
>>>>>>>>>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>>>>>>>>>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my
>>>>>>>>>> views to
>>>>>>>>>> >> ``views`` module or package. But from first view in
>>>>>>>>>> ``Flask-Classy`` I
>>>>>>>>>> >> only can add url rules with explicitly View.register call,
>>>>>>>>>> which means
>>>>>>>>>> >> I need to import this class to application, which I don't
>>>>>>>>>> really like.
>>>>>>>>>> >>
>>>>>>>>>> >> On 31 October 2012 18:27, Freedom Dumlao <
>>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>> >> > Hey Flaskers,
>>>>>>>>>> >> >
>>>>>>>>>> >> > At the day job I came up with a class based views solution
>>>>>>>>>> to meet some
>>>>>>>>>> >> > of
>>>>>>>>>> >> > the needs of our application.
>>>>>>>>>> >> > I recently started a side project where I wanted to use the
>>>>>>>>>> same thing
>>>>>>>>>> >> > and
>>>>>>>>>> >> > thought it might be time to start
>>>>>>>>>> >> > extracting the functionality into a Flask extension others
>>>>>>>>>> might find
>>>>>>>>>> >> > useful
>>>>>>>>>> >> > too.
>>>>>>>>>> >> >
>>>>>>>>>> >> > It takes a somewhat different approach to class based views
>>>>>>>>>> than what
>>>>>>>>>> >> > you
>>>>>>>>>> >> > find in the flask.views namespace
>>>>>>>>>> >> > so I'd really appreciate any feedback on the API and
>>>>>>>>>> features. There are
>>>>>>>>>> >> > a
>>>>>>>>>> >> > couple of features I havent
>>>>>>>>>> >> > extracted yet, specifically view wrapping, and template
>>>>>>>>>> contexts, but
>>>>>>>>>> >> > I'll
>>>>>>>>>> >> > be getting to them pretty soon.
>>>>>>>>>> >> >
>>>>>>>>>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>>>>>>>>>> >> >
>>>>>>>>>> >> > I look forward to hearing what you think.
>>>>>>>>>> >> >
>>>>>>>>>> >> > - Freedom
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >>
>>>>>>>>>> >> --
>>>>>>>>>> >> Sincerely,
>>>>>>>>>> >> Igor Davydenko
>>>>>>>>>> >
>>>>>>>>>> >
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sincerely,
>>>>>>>>>> Igor Davydenko
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] An alternative approach to class based views

From:
Mark Grey
Date:
2012-11-13 @ 21:49
Hey Freedom,

Here's just what I've been playing around with so far with the latest
version, with the app object substituted for something generic (they don't
let me put any code relating to work on my github).  Most of the tests are
dupes from your unittests, but I was trying different registration schemes
to see how it behaved.

The repo is at https://github.com/DeaconDesperado/too_damn_classy and I
added you to it for editing. = )

Really liking it so far!

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

> Freedom,
>
> I've been working with Classy for the past few days and I have assembled
> some ideas... but I'm going to install your latest into the virtualenv
> before making a fool of myself by discussing something you've already
> gotten to.
>
> Great work btw!
>
> Mark
>
>
> On Sun, Nov 11, 2012 at 7:57 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>
>> Mark,
>>
>> I went ahead and pushed a version to pypi (0.4.3) that includes that fix.
>> There's also a new feature in this release - view wrappers.
>>
>> Hope it helps :)
>>
>> Freedom
>>
>>
>> On Fri, Nov 9, 2012 at 11:16 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>
>>> Freedom,
>>>
>>> Any known issue with registering a FlaskView on a Blueprint instead of
>>> an app directly?  Here is my usage.
>>>
>>> WebService = Blueprint('webservice',__name__,subdomain='data')
>>>
>>> @WebService.route('/')
>>> def root():
>>>     return Response('hello data!')
>>>
>>> #Place FlaskView
>>> class PlaceView(FlaskView):
>>>     route_base = '/place'
>>>
>>>     def get(self,place_id):
>>>         try:
>>>             pid = ObjectId(place_id)
>>>             place = Place.collection.find_one({'_id':pid})
>>>             return
>>> Response([json.dumps(place,cls=Encoder,indent=4)],mimetype='application/json')
>>>         except Exception as e:
>>>             return
>>> Response(json.dumps(e.message),mimetype='application/json')
>>>
>>> PlaceView.register(WebService)
>>>
>>>
>>> Doesn't seem to be routing properly though.  The blueprint in question
>>> is attached at two subdomains.
>>>
>>> On Thu, Nov 8, 2012 at 5:20 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>>>
>>>> Cool, automatic template folder lookup sounds exactly what I'm looking
>>>> for! :)
>>>> I have created a pull request on github with a small change, to only
>>>> append an index to the route_name for custom routes if there is more than
>>>> one.
>>>>
>>>> I'm not sure if it isn't better to stick with the behavior as it is
>>>> now, because maybe it's better if a custom route always means an index will
>>>> be added.
>>>> On the other hand, most of the time people will probably define only
>>>> one custom route, and for this cases it would be nicer without the index.
>>>>
>>>>
>>>>
>>>> On Thu, Nov 8, 2012 at 4:02 PM, Freedom Dumlao <freedomdumlao@gmail.com
>>>> > wrote:
>>>>
>>>>> Thanks Jesaja, I appreciate the feedback!
>>>>>
>>>>> So the template context idea is a two-fold feature, and works with the
>>>>> class based "before_request" and "after_request" feature that is also in
>>>>> development. It does automatically look for templates in the folder based
>>>>> on the FlaskView but also it allows you to build up a context to send to
>>>>> the template from any method that executes during the request cycle.
>>>>>
>>>>> As for the default id parameter name, you're completely right. I'll
>>>>> change it before the next release in an update. It will be a breaking
>>>>> change for some but I think it's better to fix that now instead of letting
>>>>> it become a real problem once many people are using it.
>>>>>
>>>>> Freedom
>>>>>
>>>>>
>>>>> On Tue, Nov 6, 2012 at 6:51 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>>>>>
>>>>>> The docs are a very entertaining read! I tried Flask-Classy today,
>>>>>> and really like it so far! It feels very elegant.
>>>>>> You wrote in your first post that you are planning to support
>>>>>> template contexts. What exactly do you mean by this?
>>>>>> What would be nice IMO was a way to specify a template folder, like I
>>>>>> can do with a blueprint by passing the template_folder parameter.
>>>>>> This can also be done manually by changing the Jinja2 environment, so
>>>>>> it's no big deal, but it still would be nice to have, I think.
>>>>>>
>>>>>> I like how you automatically attach an index to the view name, if
>>>>>> (multiple) routes are defined for a view.
>>>>>>
>>>>>> Just one suggestion: maybe it would be better to use some other name
>>>>>> than "id" as parameter for the get method?
>>>>>> It's no big deal, but pylint will complain about redefining a
>>>>>> built-in.
>>>>>> Maybe "item" or "obj_id" or something like this would be better.
>>>>>>
>>>>>> Thanks a lot for Flask-Classy!
>>>>>>
>>>>>> Best Regards,
>>>>>>
>>>>>> Jesaja Everling
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Nov 5, 2012 at 5:04 PM, Freedom Dumlao <
>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>
>>>>>>> Thanks Mark.
>>>>>>>
>>>>>>> Take a look at the docs at 
http://packages.python.org/Flask-Classy/and see if they make sense. I've 
also fixed some bugs that I've found while
>>>>>>> using it myself. Let me know what you think!
>>>>>>>
>>>>>>> - Freedom
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 5, 2012 at 10:40 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>>>
>>>>>>>> Freedom,
>>>>>>>>
>>>>>>>> I noticed on your github that you've started adding subdomain
>>>>>>>> support.
>>>>>>>>
>>>>>>>> I am going to try implementing your extension for views today and
>>>>>>>> will provide some testing info =)
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, Nov 1, 2012 at 12:31 PM, Owein Reese <owreese@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> This really is nice. Like others have said, add subdomain support
>>>>>>>>> and you'll have created something really special.
>>>>>>>>> On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Great work freedom - I echo what's been said - I think this ext
>>>>>>>>>> provides a neat, easy to comprehend api when blueprints just 
don't quite
>>>>>>>>>> fit.
>>>>>>>>>>
>>>>>>>>>> Well done :))
>>>>>>>>>>
>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>
>>>>>>>>>> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>  I actually just ran into this problem just now developing and
>>>>>>>>>> am seriously considering converting my MethodViews to this ext.  I'm
>>>>>>>>>> pulling for you here, Freedom.
>>>>>>>>>>
>>>>>>>>>> IMHO this is a significant improvement over the business about
>>>>>>>>>> attaching MethodViews in the last paragraph at
>>>>>>>>>> http://flask.pocoo.org/docs/views/.  Even refactored as
>>>>>>>>>> demonstrated, that's still a lot of extra code just to get the 
routing down
>>>>>>>>>> accurately, and the decorator syntax is still the most sexy way
to attach
>>>>>>>>>> the endpoints.
>>>>>>>>>>
>>>>>>>>>> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
>>>>>>>>>> playpauseandstop@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Ok, thanks,
>>>>>>>>>>>
>>>>>>>>>>> Will wait on news here
>>>>>>>>>>>
>>>>>>>>>>> On 31 October 2012 19:53, Freedom Dumlao <
>>>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>>> > Thanks Igor, I look forward to hearing about your experiences.
>>>>>>>>>>> >
>>>>>>>>>>> > At present I don't have lazy view support, however I plan on
>>>>>>>>>>> making the
>>>>>>>>>>> > routing features a bit more maleable, and in doing so will
>>>>>>>>>>> probably make it
>>>>>>>>>>> > possible to create lazy views.
>>>>>>>>>>> >
>>>>>>>>>>> > - Freedom
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>>>>>>>>>>> playpauseandstop@gmail.com>
>>>>>>>>>>> > wrote:
>>>>>>>>>>> >>
>>>>>>>>>>> >> Looks very promising for me, will try in one of my current
>>>>>>>>>>> projects.
>>>>>>>>>>> >>
>>>>>>>>>>> >> Only a quick question, has Flask-Classy an ability to
>>>>>>>>>>> register views
>>>>>>>>>>> >> lazy way, without View.register call?
>>>>>>>>>>> >>
>>>>>>>>>>> >> I mean, I like to use lazy views pattern (
>>>>>>>>>>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>>>>>>>>>>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my
>>>>>>>>>>> views to
>>>>>>>>>>> >> ``views`` module or package. But from first view in
>>>>>>>>>>> ``Flask-Classy`` I
>>>>>>>>>>> >> only can add url rules with explicitly View.register call,
>>>>>>>>>>> which means
>>>>>>>>>>> >> I need to import this class to application, which I don't
>>>>>>>>>>> really like.
>>>>>>>>>>> >>
>>>>>>>>>>> >> On 31 October 2012 18:27, Freedom Dumlao <
>>>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>>> >> > Hey Flaskers,
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > At the day job I came up with a class based views solution
>>>>>>>>>>> to meet some
>>>>>>>>>>> >> > of
>>>>>>>>>>> >> > the needs of our application.
>>>>>>>>>>> >> > I recently started a side project where I wanted to use the
>>>>>>>>>>> same thing
>>>>>>>>>>> >> > and
>>>>>>>>>>> >> > thought it might be time to start
>>>>>>>>>>> >> > extracting the functionality into a Flask extension others
>>>>>>>>>>> might find
>>>>>>>>>>> >> > useful
>>>>>>>>>>> >> > too.
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > It takes a somewhat different approach to class based views
>>>>>>>>>>> than what
>>>>>>>>>>> >> > you
>>>>>>>>>>> >> > find in the flask.views namespace
>>>>>>>>>>> >> > so I'd really appreciate any feedback on the API and
>>>>>>>>>>> features. There are
>>>>>>>>>>> >> > a
>>>>>>>>>>> >> > couple of features I havent
>>>>>>>>>>> >> > extracted yet, specifically view wrapping, and template
>>>>>>>>>>> contexts, but
>>>>>>>>>>> >> > I'll
>>>>>>>>>>> >> > be getting to them pretty soon.
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > I look forward to hearing what you think.
>>>>>>>>>>> >> >
>>>>>>>>>>> >> > - Freedom
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >>
>>>>>>>>>>> >> --
>>>>>>>>>>> >> Sincerely,
>>>>>>>>>>> >> Igor Davydenko
>>>>>>>>>>> >
>>>>>>>>>>> >
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Sincerely,
>>>>>>>>>>> Igor Davydenko
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] An alternative approach to class based views

From:
Freedom Dumlao
Date:
2012-11-14 @ 18:13
Thanks Mark that's awesome!


On Tue, Nov 13, 2012 at 4:49 PM, Mark Grey <mark.asperia@gmail.com> wrote:

> Hey Freedom,
>
> Here's just what I've been playing around with so far with the latest
> version, with the app object substituted for something generic (they don't
> let me put any code relating to work on my github).  Most of the tests are
> dupes from your unittests, but I was trying different registration schemes
> to see how it behaved.
>
> The repo is at https://github.com/DeaconDesperado/too_damn_classy and I
> added you to it for editing. = )
>
> Really liking it so far!
>
>
> On Tue, Nov 13, 2012 at 10:43 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>
>> Freedom,
>>
>> I've been working with Classy for the past few days and I have assembled
>> some ideas... but I'm going to install your latest into the virtualenv
>> before making a fool of myself by discussing something you've already
>> gotten to.
>>
>> Great work btw!
>>
>> Mark
>>
>>
>> On Sun, Nov 11, 2012 at 7:57 PM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>>
>>> Mark,
>>>
>>> I went ahead and pushed a version to pypi (0.4.3) that includes that
>>> fix. There's also a new feature in this release - view wrappers.
>>>
>>> Hope it helps :)
>>>
>>> Freedom
>>>
>>>
>>> On Fri, Nov 9, 2012 at 11:16 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>
>>>> Freedom,
>>>>
>>>> Any known issue with registering a FlaskView on a Blueprint instead of
>>>> an app directly?  Here is my usage.
>>>>
>>>> WebService = Blueprint('webservice',__name__,subdomain='data')
>>>>
>>>> @WebService.route('/')
>>>> def root():
>>>>     return Response('hello data!')
>>>>
>>>> #Place FlaskView
>>>> class PlaceView(FlaskView):
>>>>     route_base = '/place'
>>>>
>>>>     def get(self,place_id):
>>>>         try:
>>>>             pid = ObjectId(place_id)
>>>>             place = Place.collection.find_one({'_id':pid})
>>>>             return
>>>> 
Response([json.dumps(place,cls=Encoder,indent=4)],mimetype='application/json')
>>>>         except Exception as e:
>>>>             return
>>>> Response(json.dumps(e.message),mimetype='application/json')
>>>>
>>>> PlaceView.register(WebService)
>>>>
>>>>
>>>> Doesn't seem to be routing properly though.  The blueprint in question
>>>> is attached at two subdomains.
>>>>
>>>> On Thu, Nov 8, 2012 at 5:20 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>>>>
>>>>> Cool, automatic template folder lookup sounds exactly what I'm looking
>>>>> for! :)
>>>>> I have created a pull request on github with a small change, to only
>>>>> append an index to the route_name for custom routes if there is more than
>>>>> one.
>>>>>
>>>>> I'm not sure if it isn't better to stick with the behavior as it is
>>>>> now, because maybe it's better if a custom route always means an index will
>>>>> be added.
>>>>> On the other hand, most of the time people will probably define only
>>>>> one custom route, and for this cases it would be nicer without the index.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Nov 8, 2012 at 4:02 PM, Freedom Dumlao <
>>>>> freedomdumlao@gmail.com> wrote:
>>>>>
>>>>>> Thanks Jesaja, I appreciate the feedback!
>>>>>>
>>>>>> So the template context idea is a two-fold feature, and works with
>>>>>> the class based "before_request" and "after_request" feature that is also
>>>>>> in development. It does automatically look for templates in the folder
>>>>>> based on the FlaskView but also it allows you to build up a context to send
>>>>>> to the template from any method that executes during the request cycle.
>>>>>>
>>>>>> As for the default id parameter name, you're completely right. I'll
>>>>>> change it before the next release in an update. It will be a breaking
>>>>>> change for some but I think it's better to fix that now instead of letting
>>>>>> it become a real problem once many people are using it.
>>>>>>
>>>>>> Freedom
>>>>>>
>>>>>>
>>>>>> On Tue, Nov 6, 2012 at 6:51 PM, Jesaja Everling <jeverling@gmail.com>wrote:
>>>>>>
>>>>>>> The docs are a very entertaining read! I tried Flask-Classy today,
>>>>>>> and really like it so far! It feels very elegant.
>>>>>>> You wrote in your first post that you are planning to support
>>>>>>> template contexts. What exactly do you mean by this?
>>>>>>> What would be nice IMO was a way to specify a template folder, like
>>>>>>> I can do with a blueprint by passing the template_folder parameter.
>>>>>>> This can also be done manually by changing the Jinja2 environment,
>>>>>>> so it's no big deal, but it still would be nice to have, I think.
>>>>>>>
>>>>>>> I like how you automatically attach an index to the view name, if
>>>>>>> (multiple) routes are defined for a view.
>>>>>>>
>>>>>>> Just one suggestion: maybe it would be better to use some other name
>>>>>>> than "id" as parameter for the get method?
>>>>>>> It's no big deal, but pylint will complain about redefining a
>>>>>>> built-in.
>>>>>>> Maybe "item" or "obj_id" or something like this would be better.
>>>>>>>
>>>>>>> Thanks a lot for Flask-Classy!
>>>>>>>
>>>>>>> Best Regards,
>>>>>>>
>>>>>>> Jesaja Everling
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Nov 5, 2012 at 5:04 PM, Freedom Dumlao <
>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>
>>>>>>>> Thanks Mark.
>>>>>>>>
>>>>>>>> Take a look at the docs at 
http://packages.python.org/Flask-Classy/and see if they make sense. I've 
also fixed some bugs that I've found while
>>>>>>>> using it myself. Let me know what you think!
>>>>>>>>
>>>>>>>> - Freedom
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Nov 5, 2012 at 10:40 AM, Mark Grey <mark.asperia@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> Freedom,
>>>>>>>>>
>>>>>>>>> I noticed on your github that you've started adding subdomain
>>>>>>>>> support.
>>>>>>>>>
>>>>>>>>> I am going to try implementing your extension for views today and
>>>>>>>>> will provide some testing info =)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Nov 1, 2012 at 12:31 PM, Owein Reese <owreese@gmail.com>wrote:
>>>>>>>>>
>>>>>>>>>> This really is nice. Like others have said, add subdomain support
>>>>>>>>>> and you'll have created something really special.
>>>>>>>>>> On Nov 1, 2012 11:44 AM, "Ben Hughes" <bwghughes@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Great work freedom - I echo what's been said - I think this ext
>>>>>>>>>>> provides a neat, easy to comprehend api when blueprints just 
don't quite
>>>>>>>>>>> fit.
>>>>>>>>>>>
>>>>>>>>>>> Well done :))
>>>>>>>>>>>
>>>>>>>>>>> Sent from my iPhone
>>>>>>>>>>>
>>>>>>>>>>> On 31 Oct 2012, at 19:05, Mark Grey <mark.asperia@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>  I actually just ran into this problem just now developing and
>>>>>>>>>>> am seriously considering converting my MethodViews to this ext.  I'm
>>>>>>>>>>> pulling for you here, Freedom.
>>>>>>>>>>>
>>>>>>>>>>> IMHO this is a significant improvement over the business about
>>>>>>>>>>> attaching MethodViews in the last paragraph at
>>>>>>>>>>> http://flask.pocoo.org/docs/views/.  Even refactored as
>>>>>>>>>>> demonstrated, that's still a lot of extra code just to get the
routing down
>>>>>>>>>>> accurately, and the decorator syntax is still the most sexy 
way to attach
>>>>>>>>>>> the endpoints.
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Oct 31, 2012 at 2:26 PM, Igor Davydenko <
>>>>>>>>>>> playpauseandstop@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Ok, thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Will wait on news here
>>>>>>>>>>>>
>>>>>>>>>>>> On 31 October 2012 19:53, Freedom Dumlao <
>>>>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>>>> > Thanks Igor, I look forward to hearing about your experiences.
>>>>>>>>>>>> >
>>>>>>>>>>>> > At present I don't have lazy view support, however I plan on
>>>>>>>>>>>> making the
>>>>>>>>>>>> > routing features a bit more maleable, and in doing so will
>>>>>>>>>>>> probably make it
>>>>>>>>>>>> > possible to create lazy views.
>>>>>>>>>>>> >
>>>>>>>>>>>> > - Freedom
>>>>>>>>>>>> >
>>>>>>>>>>>> >
>>>>>>>>>>>> > On Wed, Oct 31, 2012 at 1:41 PM, Igor Davydenko <
>>>>>>>>>>>> playpauseandstop@gmail.com>
>>>>>>>>>>>> > wrote:
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> Looks very promising for me, will try in one of my current
>>>>>>>>>>>> projects.
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> Only a quick question, has Flask-Classy an ability to
>>>>>>>>>>>> register views
>>>>>>>>>>>> >> lazy way, without View.register call?
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> I mean, I like to use lazy views pattern (
>>>>>>>>>>>> >> http://flask.pocoo.org/docs/patterns/lazyloading/,
>>>>>>>>>>>> >> http://pypi.python.org/pypi/Flask-LazyViews ) and place my
>>>>>>>>>>>> views to
>>>>>>>>>>>> >> ``views`` module or package. But from first view in
>>>>>>>>>>>> ``Flask-Classy`` I
>>>>>>>>>>>> >> only can add url rules with explicitly View.register call,
>>>>>>>>>>>> which means
>>>>>>>>>>>> >> I need to import this class to application, which I don't
>>>>>>>>>>>> really like.
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> On 31 October 2012 18:27, Freedom Dumlao <
>>>>>>>>>>>> freedomdumlao@gmail.com> wrote:
>>>>>>>>>>>> >> > Hey Flaskers,
>>>>>>>>>>>> >> >
>>>>>>>>>>>> >> > At the day job I came up with a class based views solution
>>>>>>>>>>>> to meet some
>>>>>>>>>>>> >> > of
>>>>>>>>>>>> >> > the needs of our application.
>>>>>>>>>>>> >> > I recently started a side project where I wanted to use
>>>>>>>>>>>> the same thing
>>>>>>>>>>>> >> > and
>>>>>>>>>>>> >> > thought it might be time to start
>>>>>>>>>>>> >> > extracting the functionality into a Flask extension others
>>>>>>>>>>>> might find
>>>>>>>>>>>> >> > useful
>>>>>>>>>>>> >> > too.
>>>>>>>>>>>> >> >
>>>>>>>>>>>> >> > It takes a somewhat different approach to class based
>>>>>>>>>>>> views than what
>>>>>>>>>>>> >> > you
>>>>>>>>>>>> >> > find in the flask.views namespace
>>>>>>>>>>>> >> > so I'd really appreciate any feedback on the API and
>>>>>>>>>>>> features. There are
>>>>>>>>>>>> >> > a
>>>>>>>>>>>> >> > couple of features I havent
>>>>>>>>>>>> >> > extracted yet, specifically view wrapping, and template
>>>>>>>>>>>> contexts, but
>>>>>>>>>>>> >> > I'll
>>>>>>>>>>>> >> > be getting to them pretty soon.
>>>>>>>>>>>> >> >
>>>>>>>>>>>> >> > Take a look here: http://packages.python.org/Flask-Classy/
>>>>>>>>>>>> >> >
>>>>>>>>>>>> >> > I look forward to hearing what you think.
>>>>>>>>>>>> >> >
>>>>>>>>>>>> >> > - Freedom
>>>>>>>>>>>> >>
>>>>>>>>>>>> >>
>>>>>>>>>>>> >>
>>>>>>>>>>>> >> --
>>>>>>>>>>>> >> Sincerely,
>>>>>>>>>>>> >> Igor Davydenko
>>>>>>>>>>>> >
>>>>>>>>>>>> >
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Sincerely,
>>>>>>>>>>>> Igor Davydenko
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: [flask] An alternative approach to class based views

From:
Smartboy
Date:
2012-10-31 @ 16:47
If only this was available six months ago when I started on my flask
project! It would have made the routes look a lot better!

I like this API, it looks reminiscent of CherryPy. I did notice that you
didn't implement PATCH in the list of grammar functions (GET, POST, PUT,
DELETE). Maybe it was just an oversight, but I find PATCH more useful than
PUT since it doesn't overwrite entries, only changes the parts that were
submitted by the PATCH request. Maybe you can add that? :)

Another nitpick, but it doesn't seem like you can include one FlaskView
class within another? For example, in my app, I do some routes along the
lines of /tests/<test_id> and /tests/<test_id>/configs/<config_id>. It'd be
nice if configs could be a separate class and included with the
/tests/<test_id> appended to it, but heck the official blueprints don't
support this either (as in, recursive/nested blueprints) so its okay. :)

Again, this extension looks very useful and is along the lines of what I
had been wanting before I settled on the blueprints+method-based
functionality that I did.

Smartboy

On Wed, Oct 31, 2012 at 9:27 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:

> Hey Flaskers,
>
> At the day job I came up with a class based views solution to meet some of
> the needs of our application.
> I recently started a side project where I wanted to use the same thing and
> thought it might be time to start
> extracting the functionality into a Flask extension others might find
> useful too.
>
> It takes a somewhat different approach to class based views than what you
> find in the flask.views namespace
> so I'd really appreciate any feedback on the API and features. There are a
> couple of features I havent
> extracted yet, specifically view wrapping, and template contexts, but I'll
> be getting to them pretty soon.
>
> Take a look here: http://packages.python.org/Flask-Classy/
>
> I look forward to hearing what you think.
>
> - Freedom
>

Re: [flask] An alternative approach to class based views

From:
Mark Grey
Date:
2012-10-31 @ 16:57
I very much like this extension!

I am curious that there is no mention of subdomains in your docs.
 Typically I think, the blueprints can have  a `subdomain` property, or
have a subdomain kwarg passed when they are registered on the application
object.  Is this also the case for your extension (assuming I have
correctly understood this as an alternative to blueprints)?

On Wed, Oct 31, 2012 at 12:47 PM, Smartboy <smartboyathome@gmail.com> wrote:

> If only this was available six months ago when I started on my flask
> project! It would have made the routes look a lot better!
>
> I like this API, it looks reminiscent of CherryPy. I did notice that you
> didn't implement PATCH in the list of grammar functions (GET, POST, PUT,
> DELETE). Maybe it was just an oversight, but I find PATCH more useful than
> PUT since it doesn't overwrite entries, only changes the parts that were
> submitted by the PATCH request. Maybe you can add that? :)
>
> Another nitpick, but it doesn't seem like you can include one FlaskView
> class within another? For example, in my app, I do some routes along the
> lines of /tests/<test_id> and /tests/<test_id>/configs/<config_id>. It'd be
> nice if configs could be a separate class and included with the
> /tests/<test_id> appended to it, but heck the official blueprints don't
> support this either (as in, recursive/nested blueprints) so its okay. :)
>
> Again, this extension looks very useful and is along the lines of what I
> had been wanting before I settled on the blueprints+method-based
> functionality that I did.
>
> Smartboy
>
>
> On Wed, Oct 31, 2012 at 9:27 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>
>> Hey Flaskers,
>>
>> At the day job I came up with a class based views solution to meet some
>> of the needs of our application.
>> I recently started a side project where I wanted to use the same thing
>> and thought it might be time to start
>> extracting the functionality into a Flask extension others might find
>> useful too.
>>
>> It takes a somewhat different approach to class based views than what you
>> find in the flask.views namespace
>> so I'd really appreciate any feedback on the API and features. There are
>> a couple of features I havent
>> extracted yet, specifically view wrapping, and template contexts, but
>> I'll be getting to them pretty soon.
>>
>> Take a look here: http://packages.python.org/Flask-Classy/
>>
>> I look forward to hearing what you think.
>>
>> - Freedom
>>
>
>

Re: [flask] An alternative approach to class based views

From:
Freedom Dumlao
Date:
2012-10-31 @ 17:46
Thanks Mark!

I hadn't considered the subdomain functionality because it wasn't used in
the app I'm extracting this from, but it seems like something that should
be there. As for being a replacement to blueprints, it should be noted that
you can actually use it *with* blueprints if you like, but in most cases
for us it did replace blueprints.

I'm adding a ticket for subdomain support so I can investigate the best way
to provide that.

- Freedom


On Wed, Oct 31, 2012 at 12:57 PM, Mark Grey <mark.asperia@gmail.com> wrote:

> I very much like this extension!
>
> I am curious that there is no mention of subdomains in your docs.
>  Typically I think, the blueprints can have  a `subdomain` property, or
> have a subdomain kwarg passed when they are registered on the application
> object.  Is this also the case for your extension (assuming I have
> correctly understood this as an alternative to blueprints)?
>
>
> On Wed, Oct 31, 2012 at 12:47 PM, Smartboy <smartboyathome@gmail.com>wrote:
>
>> If only this was available six months ago when I started on my flask
>> project! It would have made the routes look a lot better!
>>
>> I like this API, it looks reminiscent of CherryPy. I did notice that you
>> didn't implement PATCH in the list of grammar functions (GET, POST, PUT,
>> DELETE). Maybe it was just an oversight, but I find PATCH more useful than
>> PUT since it doesn't overwrite entries, only changes the parts that were
>> submitted by the PATCH request. Maybe you can add that? :)
>>
>> Another nitpick, but it doesn't seem like you can include one FlaskView
>> class within another? For example, in my app, I do some routes along the
>> lines of /tests/<test_id> and /tests/<test_id>/configs/<config_id>. It'd be
>> nice if configs could be a separate class and included with the
>> /tests/<test_id> appended to it, but heck the official blueprints don't
>> support this either (as in, recursive/nested blueprints) so its okay. :)
>>
>> Again, this extension looks very useful and is along the lines of what I
>> had been wanting before I settled on the blueprints+method-based
>> functionality that I did.
>>
>> Smartboy
>>
>>
>> On Wed, Oct 31, 2012 at 9:27 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>>
>>> Hey Flaskers,
>>>
>>> At the day job I came up with a class based views solution to meet some
>>> of the needs of our application.
>>> I recently started a side project where I wanted to use the same thing
>>> and thought it might be time to start
>>> extracting the functionality into a Flask extension others might find
>>> useful too.
>>>
>>> It takes a somewhat different approach to class based views than what
>>> you find in the flask.views namespace
>>> so I'd really appreciate any feedback on the API and features. There are
>>> a couple of features I havent
>>> extracted yet, specifically view wrapping, and template contexts, but
>>> I'll be getting to them pretty soon.
>>>
>>> Take a look here: http://packages.python.org/Flask-Classy/
>>>
>>> I look forward to hearing what you think.
>>>
>>> - Freedom
>>>
>>
>>
>

Re: [flask] An alternative approach to class based views

From:
Freedom Dumlao
Date:
2012-10-31 @ 17:43
Thanks for the feedback Smartboy!

I didn't include PATCH, simply because the code I'm extracting it from
didn't use PATCH, but given it's popularity and practicality I think it's
definitely something that should be there. I'll add it tonight.

As for nested classes, that is *really* interesting. I I'm going to spend
some time thinking about how something like that might work, and what the
API for that should be.

- Freedom


On Wed, Oct 31, 2012 at 12:47 PM, Smartboy <smartboyathome@gmail.com> wrote:

> If only this was available six months ago when I started on my flask
> project! It would have made the routes look a lot better!
>
> I like this API, it looks reminiscent of CherryPy. I did notice that you
> didn't implement PATCH in the list of grammar functions (GET, POST, PUT,
> DELETE). Maybe it was just an oversight, but I find PATCH more useful than
> PUT since it doesn't overwrite entries, only changes the parts that were
> submitted by the PATCH request. Maybe you can add that? :)
>
> Another nitpick, but it doesn't seem like you can include one FlaskView
> class within another? For example, in my app, I do some routes along the
> lines of /tests/<test_id> and /tests/<test_id>/configs/<config_id>. It'd be
> nice if configs could be a separate class and included with the
> /tests/<test_id> appended to it, but heck the official blueprints don't
> support this either (as in, recursive/nested blueprints) so its okay. :)
>
> Again, this extension looks very useful and is along the lines of what I
> had been wanting before I settled on the blueprints+method-based
> functionality that I did.
>
> Smartboy
>
>
> On Wed, Oct 31, 2012 at 9:27 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>
>> Hey Flaskers,
>>
>> At the day job I came up with a class based views solution to meet some
>> of the needs of our application.
>> I recently started a side project where I wanted to use the same thing
>> and thought it might be time to start
>> extracting the functionality into a Flask extension others might find
>> useful too.
>>
>> It takes a somewhat different approach to class based views than what you
>> find in the flask.views namespace
>> so I'd really appreciate any feedback on the API and features. There are
>> a couple of features I havent
>> extracted yet, specifically view wrapping, and template contexts, but
>> I'll be getting to them pretty soon.
>>
>> Take a look here: http://packages.python.org/Flask-Classy/
>>
>> I look forward to hearing what you think.
>>
>> - Freedom
>>
>
>

Re: [flask] An alternative approach to class based views

From:
Freedom Dumlao
Date:
2012-11-01 @ 14:46
Just a quick update, PATCH was added in version 0.3.4 this morning. Thanks
again for the suggestion.

On Wed, Oct 31, 2012 at 12:47 PM, Smartboy <smartboyathome@gmail.com> wrote:

> If only this was available six months ago when I started on my flask
> project! It would have made the routes look a lot better!
>
> I like this API, it looks reminiscent of CherryPy. I did notice that you
> didn't implement PATCH in the list of grammar functions (GET, POST, PUT,
> DELETE). Maybe it was just an oversight, but I find PATCH more useful than
> PUT since it doesn't overwrite entries, only changes the parts that were
> submitted by the PATCH request. Maybe you can add that? :)
>
> Another nitpick, but it doesn't seem like you can include one FlaskView
> class within another? For example, in my app, I do some routes along the
> lines of /tests/<test_id> and /tests/<test_id>/configs/<config_id>. It'd be
> nice if configs could be a separate class and included with the
> /tests/<test_id> appended to it, but heck the official blueprints don't
> support this either (as in, recursive/nested blueprints) so its okay. :)
>
> Again, this extension looks very useful and is along the lines of what I
> had been wanting before I settled on the blueprints+method-based
> functionality that I did.
>
> Smartboy
>
>
> On Wed, Oct 31, 2012 at 9:27 AM, Freedom Dumlao <freedomdumlao@gmail.com>wrote:
>
>> Hey Flaskers,
>>
>> At the day job I came up with a class based views solution to meet some
>> of the needs of our application.
>> I recently started a side project where I wanted to use the same thing
>> and thought it might be time to start
>> extracting the functionality into a Flask extension others might find
>> useful too.
>>
>> It takes a somewhat different approach to class based views than what you
>> find in the flask.views namespace
>> so I'd really appreciate any feedback on the API and features. There are
>> a couple of features I havent
>> extracted yet, specifically view wrapping, and template contexts, but
>> I'll be getting to them pretty soon.
>>
>> Take a look here: http://packages.python.org/Flask-Classy/
>>
>> I look forward to hearing what you think.
>>
>> - Freedom
>>
>
>