Re: [Repoze-dev] repoze grok comparison

[Chris McDonough]

On 5/6/09 8:50 PM, Martin Aspeli wrote:
> Shane Hathaway wrote:
>> Fernando Correa Neto wrote:
>>> Adding new template engines to BFG require you to know python while in
>>> GROK, it'd require you to grok grok first (which in would then
>>> introduce the developer to ZCA) which is definitely a Zope3 thing.
>> You hit on a point that I consider important.  One of the interesting
>> things about ZCML (and hence BFG) is it's easy for any Python developer
>> to write their own directives.  ZCML doesn't violate DRY, as I once
>> thought it did, because if you find yourself writing repetitive
>> directives, you can just create a custom directive in Python instead.

FTR, not that it matters now, but I just noticed that the premise of this 
comparison is a little off kilter.  Because the ZCML BFG "view" directive never 
names a template (unlike Zope's browser:page), adding a new templating system 
doesn't actually require writing a ZCML handler or a grokker.  It just requires 
the creation of a Python package that has quasi-familiar importable names like 
"render_template_to_response", and so on.  This comes at the expense of 
requiring the view itself to know about the template name, and to decide which 
templating system it wants to use.  So it's a tradeoff.

>> Unfortunately, Grok obscures that simplicity.  It seems much harder to
>> add new kinds of decorators than it is to add new kinds of ZCML directives.
>
> You're sure about that? I find it easier to write a new grokker (whether
> for a decorator or a more generic class grokker that looks for a base
> class) than a new ZCML directive (and I've done plenty of both).
>
> The grok approach is unfamiliar at first, for sure, and could do with
> more documentation. But then so could the writing of ZCML directives.
> Grok (and martian) do have some really nice abstractions, including good
> testing support.
>
>> The benefit of Grok's decorators is further diminished by the fact that
>> people who develop with Grok generally have to use ZCML anyway in order
>> to understand and extend the code Grok is built from.
>
> I guess it depends on how deep you go, I suppose, but this is definitely
> something that will hit a certain group of people.

In BFG, at least, every time I write a grokker I tend to write an equivalent 
ZCML directive.  The number of times I've had to do that so far has however 
only 
been one. ;-)

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze grok comparison

[Martin Aspeli]

Shane Hathaway wrote:
> Fernando Correa Neto wrote:
>> Adding new template engines to BFG require you to know python while in
>> GROK, it'd require you to grok grok first (which in would then
>> introduce the developer to ZCA) which is definitely a Zope3 thing.
> 
> You hit on a point that I consider important.  One of the interesting 
> things about ZCML (and hence BFG) is it's easy for any Python developer 
> to write their own directives.  ZCML doesn't violate DRY, as I once 
> thought it did, because if you find yourself writing repetitive 
> directives, you can just create a custom directive in Python instead.
> 
> Unfortunately, Grok obscures that simplicity.  It seems much harder to 
> add new kinds of decorators than it is to add new kinds of ZCML directives.

You're sure about that? I find it easier to write a new grokker (whether 
for a decorator or a more generic class grokker that looks for a base 
class) than a new ZCML directive (and I've done plenty of both).

The grok approach is unfamiliar at first, for sure, and could do with 
more documentation. But then so could the writing of ZCML directives. 
Grok (and martian) do have some really nice abstractions, including good 
testing support.

> The benefit of Grok's decorators is further diminished by the fact that 
> people who develop with Grok generally have to use ZCML anyway in order 
> to understand and extend the code Grok is built from.

I guess it depends on how deep you go, I suppose, but this is definitely 
something that will hit a certain group of people.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze grok comparison

[Chris McDonough]

On 5/6/09 3:33 PM, Shane Hathaway wrote:
> Fernando Correa Neto wrote:
>> Adding new template engines to BFG require you to know python while in
>> GROK, it'd require you to grok grok first (which in would then
>> introduce the developer to ZCA) which is definitely a Zope3 thing.
>
> You hit on a point that I consider important.  One of the interesting
> things about ZCML (and hence BFG) is it's easy for any Python developer
> to write their own directives.  ZCML doesn't violate DRY, as I once
> thought it did, because if you find yourself writing repetitive
> directives, you can just create a custom directive in Python instead.
>
> Unfortunately, Grok obscures that simplicity.  It seems much harder to
> add new kinds of decorators than it is to add new kinds of ZCML directives.

It's actually not too bad.  Writing the "bfg_view" decorator was pretty simple 
(although I did find some bugs in martian that needed fixing while doing it).  
I 
mostly found writing a grokker more pleasant than writing an equivalent ZCML 
handler.  But that may just be preference.

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze grok comparison

[Shane Hathaway]

Fernando Correa Neto wrote:
> Adding new template engines to BFG require you to know python while in
> GROK, it'd require you to grok grok first (which in would then
> introduce the developer to ZCA) which is definitely a Zope3 thing.

You hit on a point that I consider important.  One of the interesting 
things about ZCML (and hence BFG) is it's easy for any Python developer 
to write their own directives.  ZCML doesn't violate DRY, as I once 
thought it did, because if you find yourself writing repetitive 
directives, you can just create a custom directive in Python instead.

Unfortunately, Grok obscures that simplicity.  It seems much harder to 
add new kinds of decorators than it is to add new kinds of ZCML directives.

The benefit of Grok's decorators is further diminished by the fact that 
people who develop with Grok generally have to use ZCML anyway in order 
to understand and extend the code Grok is built from.

Shane

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze grok comparison

[Chris McDonough]

On 5/6/09 10:11 AM, Yves Moisan wrote:

> Well for someone like me (more or less familiar with Plone, already
> installed TG but not played very much with it and ended up installing
> Pylons for a project) a "what's the best tool matrix" would be neat.
>
> I see that matrix as some form of use cases for lines and the software
> options for columns.  The cell value could be a ranking, since obviously
> there won't be a case where Grok or BFG or WSGIPlone or whatever will be
> perfect or null for use case X.
>
> [Use] case in point : we're beginning a new project and we're
> considering options for web presence.  A quick setup is throw a Trac and
> build on it, but I'd rather have a nice (easier to theme) front end on
> top of Trac (that would play well with Trac).  Would/could that front
> end be Plone (we might have some content to manage one day, but then
> maybe not that much .. or will we ?) or Grok or BFG ?

This use case isn't too hard.  Deliverance can do this for you, or you could 
take a look at http://bfg.repoze.org/tutorialbin/2/ for the same thing without 
Deliverance under BFG (or anything else).  Trac is somewhat unique inasmuch as 
it appears to be *meant* to be abused in this way.  Its HTML is very regular, 
and it seems to "just work".

> I know it's very often a matter of personal preference or competence and
> a matrix won't be a silver bullet but it would help IMO.  Ease of
> deployment at commercial ISP's might be important to mention, but I
> understand that most people on this list probably manage their own
> servers.

The "smaller" solutions (Pylons / BFG) are so similar to each other as to be 
almost indistinguishable.  They're so similar that we've actually been trying 
to 
come to some form of convergence (see 
http://www.openplans.org/projects/pypefitters/lists/pypefitters-discussion), 
but 
unfortunately, differences in opinion about minor things has conspired againt 
any real convergence.

The "middle" solutions (TG / Django / Zope) differ mostly in style.

The "large" solution (Plone) is in a class of its own.  It's more an 
application 
itself than a framework on which to build any old application.

- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

Re: [Repoze-dev] repoze grok comparison

[Yves Moisan]

> but to someone like me who is experienced in
> Pylons/TG/Django style stuff but new to Zope, I'm pretty confused about
> whether I should learn zope by trying out Zope 3, Grok, or Repoze.bfg
> and what the pros and cons of each approach are.

Well for someone like me (more or less familiar with Plone, already
installed TG but not played very much with it and ended up installing
Pylons for a project) a "what's the best tool matrix" would be neat.  

I see that matrix as some form of use cases for lines and the software
options for columns.  The cell value could be a ranking, since obviously
there won't be a case where Grok or BFG or WSGIPlone or whatever will be
perfect or null for use case X.

[Use] case in point : we're beginning a new project and we're
considering options for web presence.  A quick setup is throw a Trac and
build on it, but I'd rather have a nice (easier to theme) front end on
top of Trac (that would play well with Trac).  Would/could that front
end be Plone (we might have some content to manage one day, but then
maybe not that much .. or will we ?) or Grok or BFG ?  

I know it's very often a matter of personal preference or competence and
a matrix won't be a silver bullet but it would help IMO.  Ease of
deployment at commercial ISP's might be important to mention, but I
understand that most people on this list probably manage their own
servers.

Cheers,

Yves Moisan

___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev

[Repoze-dev] [issue73] repoze.who IAuthenticator cannot report the reason for authentication failure

[Forest]

New submission from Forest :

The interface defined for IAuthenticator doesn't allow it to report a reason for
authentication failure.  This prevents me from showing the user a sensible
message when (for example) his login was refused due to excessive failed login
attempts or a deactivated account.

--
messages: 186
nosy: forest
priority: feature
status: unread
title: repoze.who IAuthenticator cannot report the reason for authentication 
failure

__
Repoze Bugs 

__
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev