0.14 todo list

[Philipp von Weitershausen]

Peter Bengtsson wrote:
> I hate ZCML but I appreciate your point about understanding an
> application by reading it but in Zope3 projects the ZCML gets quite
> hairy and long quite quickly and it looses it value. If you need a
> overview of the app, perhaps we can have a script or something that
> inspects the files and the files content and from that works out a,
> for example, ascii tree of how classes, interfaces and templates are
> connected.

Or you have a webapp that you can enable in your Grok instance, which is
what Uli's And Martin's new introspector stuff will let you do. It's
being developed as part of the GSoC program.

We do realize that the lack of an explicit configuration file separated
from the code may make it harder to see what's going on. We hope that a
powerful introspector will alleviate this problem.

I also hope to enhance the grokkers and/or Martian so that they equip
configuration actions with more information which could then be
inspected. Both ZCML and grokkers emit actions.
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Sylvain Viollon]

On Thu, 31 Jul 2008 09:47:12 +0100
Martin Aspeli <optilude@...> wrote:

> Hi Sylvain,
>

 Hello,

> >> Mmmm.... is there any documentation on how to use this in plain
> >> Zope 2 (or Plone)? I'm getting confused by Silva stuff. ;-)
> >>
> >
> > Not, really, but that's easy. In a meta.zcml somewhere, add an:
>
> Excellent!
>
> >   <include package="five.grok" file="meta.zcml" />
> >   <include package="five.grok" />
>
> What's the relationship between five.grok and grokcore.view? Is the
> latter a dependency on the former?
>

  five.grok is a bunch of changes for Zope 2, and yes,
grokcore.{view,component} are dependencies of five.grok.

> > In the package where your view is, add to the configure.zcml:
> >
> >   <grok:grok package=".wheremyviewis" />
> >
> > And your view will be something like:
> >
> >   import five.grok
> >
> >   class MyView(five.grok.View):
> >
> >       five.grok.context(IMyContent)
> >       five.grok.name(u"test.html")
>
> Would it work to use the context() and name() directives from
> grokcore.view instead of five.grok?
>

  Yes, they are just imported in five.grok, if I remember correctly.
It's just that's better to have one import instead of two.

> >       def render(self):
> >           return u"Hello World"
> >
> >
> > That's it. After you have the same rules than in Grok for templates,
> > and so on.
>
> Are these documented anywhere?
>

  I think in grok documentation. The rule is unless you used the
templatedir directive in module to configure a different template
directory, if a view don't define a render method, a template named
with the name of your view class in lower case is search in a directory
which have the same name than your python module (in lower case as well
I think).

  So if your view is in wheremyviewis.py, the template
wheremyviewis/myview.pt is going to be used if you remove the render
method above.

> > Forms are more complex, since you need to build a mixin with Five:
> >
> >    from grokcore.formlib.components import GrokForm
> >    from grokcore.formlib import action
> >
> >    class PageForm(GrokForm, formbase.PageForm, five.grok.View):
> >
> >        five.grok.context(IMyContent)
> >        five.grok.name(u"edit.html")
> >
> >        @action(u"Test me")
> >        def action_test(self, **data):
> >            self.status = "Tested"
> >
> >
> > Don't forget to include in the configure.zcml grokcore.formlib.
>
> Cool! I'm more interested in a z3c.form version, though. Is anyone
> working on that? If not, I would be interested to figure out how to
> do that.
>

  Yes, I am currently trying to do that. We need the support of
plone.z3cform (it will act like formbase of Five for formlib). I
discussed of that yesterday with Daniel, and he removed all CMF
specifics parts from plone.z3cform (I am building it for Silva, and I
don't want CMF).

  Basically, we have to build a grokker which create the form_fields
attribute like for formlib, wrap actions ... We will have to register
the form to the ZCA as view wrapped with the form_wrapper provided in
plone.z3cform.

> > Security can be done with grokcore.security.require ...
>
> Cool! Does that take IPermission utility names? Or Zope 2 permission
> strings?
>

  You can give either Grok permission object, or Zope 3 permission
title: 'zope.Public' for instance.

> Thanks again!
>
> Martin
>

   Sylvain,


--
Sylvain Viollon -- Infrae
t [phone] -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Jean-François Roche-3]

It would be great if you could show the Forms & Formlib mixin inside the
README.txt we have in
http://svn.zope.org/five.grok/trunk/src/five/grok/README.txt?rev=88533&view=markup

To avoid having a doctest within a python file (the README.txt is
supposed to also explain registration) as most grok doctest are, we have
a little change in the grok notation inside this doctest:

   >>>
are doctest

   <<<
are setup of grok (executed first).

See you,

                        Jeff


Sylvain Viollon wrote:

> On Wed, 30 Jul 2008 23:14:40 +0100
> Martin Aspeli <optilude@...> wrote:
>
>> Mmmm.... is there any documentation on how to use this in plain Zope
>> 2 (or Plone)? I'm getting confused by Silva stuff. ;-)
>>
>
> Not, really, but that's easy. In a meta.zcml somewhere, add an:
>
>   <include package="five.grok" file="meta.zcml" />
>   <include package="five.grok" />
>
> In the package where your view is, add to the configure.zcml:
>
>   <grok:grok package=".wheremyviewis" />
>
> And your view will be something like:
>
>   import five.grok
>
>   class MyView(five.grok.View):
>
>       five.grok.context(IMyContent)
>       five.grok.name(u"test.html")
>
>       def render(self):
>           return u"Hello World"
>
>
> That's it. After you have the same rules than in Grok for templates,
> and so on.
>
> Forms are more complex, since you need to build a mixin with Five:
>
>    from grokcore.formlib.components import GrokForm
>    from grokcore.formlib import action
>
>    class PageForm(GrokForm, formbase.PageForm, five.grok.View):
>
>        five.grok.context(IMyContent)
>        five.grok.name(u"edit.html")
>
>        @action(u"Test me")
>        def action_test(self, **data):
>            self.status = "Tested"
>
>
> Don't forget to include in the configure.zcml grokcore.formlib.
> Security can be done with grokcore.security.require ...
>
> Voila.
>
>   Sylvain,
>
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[wichert]

Previously Peter Bengtsson wrote:
> I hate ZCML but I appreciate your point about understanding an
> application by reading it but in Zope3 projects the ZCML gets quite
> hairy and long quite quickly and it looses it value. If you need a
> overview of the app, perhaps we can have a script or something that
> inspects the files and the files content and from that works out a,
> for example, ascii tree of how classes, interfaces and templates are
> connected.

Or you could write documentation for your application. There is just no
substitute.

Wichert.

--
Wichert Akkerman <wichert@...>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Sylvain Viollon]

Hello,

On Thu, 31 Jul 2008 11:07:28 +0200
Jean-Fran__ois Roche <jfroche@...> wrote:

> It would be great if you could show the Forms & Formlib mixin inside
> the README.txt we have in
> http://svn.zope.org/five.grok/trunk/src/five/grok/README.txt?rev=88533&view=markup
>

  I think we should integrate this mixin in five.grok, like it's done
in grokcore.formlib for real Zope 3 forms, and export an PageForm,
AddForm and EditForm in the __init__.py of the package.

  Sylvain,

--
Sylvain Viollon -- Infrae
t [phone] -- http://infrae.com
Hoevestraat 10 3033GC Rotterdam -- The Netherlands
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Godefroid Chapelle]

Sylvain Viollon wrote:
> Hello,
>
>    Thanks to Godefroid and Lennart for grokcore.views.
>
>    Sylvain,

I am just back from one week holidays.

I want to insist that the work happened during a sprint.

Iow, credit is also due to Jean-François Roche, Frederic Tedesco,
Adrien (sorry I forgot his surname) and Alain Meurant that worked hard
with Lennart and myself.

Cheers.

--
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Baiju M-3]

Philipp von Weitershausen wrote:
<snip>
>  We do realize that the lack of an explicit configuration file
>  separated from the code may make it harder to see what's going on. We
>  hope that a powerful introspector will alleviate this problem.

That's a good news, an introspector which helps to see "what's going on"
would be great.

Regards,
Baiju M

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Godefroid Chapelle]

Sylvain Viollon wrote:
> Hello,
>
>    Thanks to Godefroid and Lennart for grokcore.views.
>
>    Sylvain,

I am just back from one week holidays.

I want to insist that the work happened during a sprint.

Iow, credit is also due to Jean-François Roche, Frederic Tedesco,
Adrien (sorry I forgot his surname) and Alain Meurant that worked hard
with Lennart and myself.

Cheers.

--
Godefroid Chapelle (aka __gotcha) http://bubblenet.be
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Hey,

A debate about ZCML. Let's step back for a bit and think about the
audiences Grok is reaching and wants to reach:

a) existing Zope 2 developers (familiar or not with Zope 3 tech)

b) existing Zope 3 developers

c) other Python developers who may never have used Zope

Grok is currently reaching a) pretty well. This is really good, as it's
a related community already familiar with Zope 3 technology and a
relatively easy way get contributors and users of Grok technology. A
debate about ZCML may be relevant here.

A debate about ZCML is certainly relevant to existing Zope 3 developers,
b). There aren't that many of them, and we decided early on that we're
not really in the business of trying to convince these developers to use
Grok. It's just not worth it, and we're already allies as we're
effectively using the same framework anyway!

For c), ZCML is not relevant at all. At most ZCML as something alien and
non-Python will scare off most of those developers, irrespective of its
true benefits or drawbacks.

Marketing-wise, we need to reach out to c) the most. We are marketing
pretty well to Zope 2 people anyway, as we know them, and we're
partially even the same people. With Zope 3 people we aren't really even
trying.

Discussions about ZCML are just not relevant for a primary audience we
want to reach, as they don't know what ZCML is. With that established,
let's have a discussion about ZCML. :)

Jan Ulrich Hasecke wrote:
[snip]

> Am 31.07.2008 um 03:23 schrieb Robert Gravina:
>> ZCML is dead! Long live the Grok!
>
> I am more and more uneasy about these statements, though only about the
> first part. ;-)
>
> If you get an application from someone else, you only have to look into
> the ZCML-files and you will soon understand the architecture of the
> application. The redundancy which violates the DRY-law, seems to me
> helpful if you read the application.

You make the argument that ZCML is harder to write but easier to read
than Grok. I wonder however why you wouldn't get the same benefit in
Grok applications. If you see something is a subclass of grok.Adapter or
grok.View, you do have a good idea what's going on without even having
to consult a ZCML file, after all.

I myself also don't have the experience that looking at ZCML files gives
me a very good idea of the architecture of the application. I might see
adapters being registered, for example, but I still have no idea how
they're being used, after all. I can get some idea of which views are
there, though often the indirection with interfaces still requires I
look at the code to understand how I can actually look at those views in
a web browser.

So in my case in order to understand the architecture of an application
I feel I need to study the code in any case. Since with Grok-based code,
I can then see the registrations right where I read the code, I will be
helped in understanding what the application is all about, not having to
consult a separate file and merge things together in my mind so much.

I'd therefore argue that Grok-based code is usually easier to read than
code where the registrations are separate. :)

 > Writing ZCML sucks, but it sucks if you do it with vim, emacs or
 > whatever editor you like. If we had a ZCML-aware IDE, it would be
 > possible to build a valid ZCML-file with a few mouse clicks.

I myself don't believe in automating away redundancy with code
generation, if the code generated is something a human being needs to
look at.

Plus we don't have a ZCML-aware IDE, and even if we magically had one,
we won't be able to make everyone use it.

I think there is another tool that helps people explore the workings of
an application: the introspection tool. This is a tool we actually can
build and are building. If an introspection tool can show which adapters
and views are registered for an object, this should help tremendously in
understanding an application's architecture.

> If you take the ZCML-files as a blueprint of your application, it seems
> to me a clean tool to master really big an complex applications. I
> cannot foster this with my own experience, but I've heard people say
> that ZCML saved their lives.

Well, I have never heard people say that, myself! I've heard people
indicate that ZCML helped them understand the application before, yes.
It hasn't really greatly helped me; I find when exploring a new library
I stare at the doctests and interfaces.py and the code and the ZCML
files all, and then have to think quite hard to get a picture of what's
going on.

I haven't heard people with experience with Grok say that Grok makes it
*harder* than ZCML.

We don't have a lot of experience with a component architecture
introspector yet.

I'd say it's incorrect to say that ZCML-files are a "blueprint" of any
kind of your application. By themselves they don't mean very much at
least in my experience.

> And from a marketing point of view these statements are really bad. How
> shall I solicit Zope, if more and more people tell me that the tool that
> hold all these components together sucks? How shall I convey trust to
> the public, if the Zope guys start to build up a new framework every
> five years?

The whole idea is that Grok *isn't* a new framework. It's Zope 3, with
some conveniences, an attitude towards better beginner documentation,
and a new way to glue things together. Grok could go so far so fast
*because* it's built on Zope 3. We've never denied this. Grok is new in
the ways we can get marketing and community benefits from it, and it is
old in the ways we can reuse lots of great ideas and code.

Zope 3 to me isn't defined by ZCML; the ZCML aspect is just a very small
part of it. I imagine ZCML looks bigger than it is to many people
because it's so different and it's so in your face, so you can't help to
think about it when you think about Zope 3. It might as a result obscure
the underlying framework more than it helps show its inner workings. It
surely makes the learning curve a lot steeper early on.

> Let Grok smash ZCML, it is nice to have more than one way to build web
> applications, but don't curse ZCML.

I didn't see Robert curse Zope 3 or ZCML, just saying it's dead. :)

The funny thing is that Grok uses almost *all* of ZCML's machinery
expect the XML-based directive parser, which is replaced by Martian. The
actions that ZCML directives produce are produced by Grok as well, and
are compatible with them. Grok's configuration system was only possible
as we had an established, well-known base to build it on.

One of Grok's major features is that it gets rid of the separate file
XML description of how things are glued together and replace it with
in-python code declarations instead, with rules for defaults of many of
them so you don't have to learn them all at once. I believe Grok's way
is a better way. We can't promote that without saying something negative
about separate file XML configuration. Criticism, yes. Cursing, no, but
I didn't see people curse it.

You admit yourself you're not speaking from personal experience
concerning ZCML. I'd say, don't praise ZCML too much either, then.

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Hey,

Robert Gravina wrote:
[snip]
> Being able to override configuration is very powerful... perhaps I
> should learn a bit more about ZCML and the motivations behind it before
> declaring it dead :) I'll go dust off my copy of Weitershausen and spend
> some quality time with it I think :)

While you do this, perhaps you'd like to investigate the following for
us. ZCML has an 'includeOverrides' directive. This allows you to include
a ZCML file that overrides the configuration you already have, for
instance registering a different view with the same name.

For a long time I thought that Grok lacks this feature, but recently I
realized that it probably does, as it's fully compatible with ZCML now.

Here's a sketch of the experimental setup:

You could have two modules, a and b, and a configure.zcml and a
configure_b.zcml. Now in configure.zcml you simply use the ZCML grok
directive to grok module a. Then you do an includeOverrides of
configure_b.zcml, in which you use the grok directive to grok module b.
In module b you have a different view for the same context and with the
same name and layer, just displaying a different text. If
includeOverrides works, you should get no configuration conflict and you
should see this second view. If this works, Grok supports overrides. :)

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Martijn Faassen-2]

Peter Bengtsson wrote:
> I hate ZCML but I appreciate your point about understanding an
> application by reading it but in Zope3 projects the ZCML gets quite
> hairy and long quite quickly and it looses it value. If you need a
> overview of the app, perhaps we can have a script or something that
> inspects the files and the files content and from that works out a,
> for example, ascii tree of how classes, interfaces and templates are
> connected.

We can do better than a script: this is what the Grok introspector
should be doing for you. :)

Regards,

Martijn

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Achim Domma (ProCoders)]

Am 31.07.2008 um 15:11 schrieb Martijn Faassen:

> c) other Python developers who may never have used Zope

[...]

> For c), ZCML is not relevant at all. At most ZCML as something  
> alien and non-Python will scare off most of those developers,  
> irrespective of its true benefits or drawbacks.

Being one of these developers, I just wanted to agree with that  
statement. I have read the first and second version of Philips book  
and was always looking at Zope, because I like the cool architecture.  
I develop software for a living, but not with Zope. So I'm looking at  
Zope in my spare time, which is quite hard if you need all that ZCML,  
just to get the simplest example up and running.

Grok has changed that: Using Grok you can just get started, play with  
object, ... Programming with Grok is the way I always imagined Zope  
development should be.

Achim
_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[ktenney]

On Thu, Jul 31, 2008 at 8:11 AM, Martijn Faassen <faassen@...> wrote:
> Hey,
>
> A debate about ZCML. Let's step back for a bit and think about the audiences
> Grok is reaching and wants to reach:

Re: public relations, it's been helpful to me to consider the heritage of ZCML,
the fact that it emerged from a wealth of experience.

I find parallels to LDAP, which at first glance looks arbitrarily
complex and arcane.
With study, it becomes apparent that it's architecture allows amazing
scalability,
things like transparently adding a branch which lives in a different
db accross the globe.
I'll never do that, but it takes the edge off the learning curve to realize that
there are good reasons behind the oddness.

As a lurker, it looks to me like the complexity of ZCML is justified by it's
capacity to virtually remove barriers to scaling in any direction.

I doubt I'll ever exploit that power, but Grok allows me to build simply,
no interference from ZCML, but I don't have to worry about hitting
any walls, because of the experience which has gone into the
underlying Z3 and ZCML.

The powerful beast that is ZCML will only be unleashed if needed.

After Pycon 2008 I read a post which opined that Django was heading
for a wall which Zope2 hit. I'd like to hear that expanded on,
I suspect it references issues which resulted in design aspects
which include ZCML. I think that would make very good reading
for framework shoppers.

Thanks,
Kent

>
> a) existing Zope 2 developers (familiar or not with Zope 3 tech)
>
> b) existing Zope 3 developers
>
> c) other Python developers who may never have used Zope
>
> Grok is currently reaching a) pretty well. This is really good, as it's a
> related community already familiar with Zope 3 technology and a relatively
> easy way get contributors and users of Grok technology. A debate about ZCML
> may be relevant here.
>
> A debate about ZCML is certainly relevant to existing Zope 3 developers, b).
> There aren't that many of them, and we decided early on that we're not
> really in the business of trying to convince these developers to use Grok.
> It's just not worth it, and we're already allies as we're effectively using
> the same framework anyway!
>
> For c), ZCML is not relevant at all. At most ZCML as something alien and
> non-Python will scare off most of those developers, irrespective of its true
> benefits or drawbacks.
>
> Marketing-wise, we need to reach out to c) the most. We are marketing pretty
> well to Zope 2 people anyway, as we know them, and we're partially even the
> same people. With Zope 3 people we aren't really even trying.
>
> Discussions about ZCML are just not relevant for a primary audience we want
> to reach, as they don't know what ZCML is. With that established, let's have
> a discussion about ZCML. :)
>
> Jan Ulrich Hasecke wrote:
> [snip]
>>
>> Am 31.07.2008 um 03:23 schrieb Robert Gravina:
>>>
>>> ZCML is dead! Long live the Grok!
>>
>> I am more and more uneasy about these statements, though only about the
>> first part. ;-)
>>
>> If you get an application from someone else, you only have to look into
>> the ZCML-files and you will soon understand the architecture of the
>> application. The redundancy which violates the DRY-law, seems to me helpful
>> if you read the application.
>
> You make the argument that ZCML is harder to write but easier to read than
> Grok. I wonder however why you wouldn't get the same benefit in Grok
> applications. If you see something is a subclass of grok.Adapter or
> grok.View, you do have a good idea what's going on without even having to
> consult a ZCML file, after all.
>
> I myself also don't have the experience that looking at ZCML files gives me
> a very good idea of the architecture of the application. I might see
> adapters being registered, for example, but I still have no idea how they're
> being used, after all. I can get some idea of which views are there, though
> often the indirection with interfaces still requires I look at the code to
> understand how I can actually look at those views in a web browser.
>
> So in my case in order to understand the architecture of an application I
> feel I need to study the code in any case. Since with Grok-based code, I can
> then see the registrations right where I read the code, I will be helped in
> understanding what the application is all about, not having to consult a
> separate file and merge things together in my mind so much.
>
> I'd therefore argue that Grok-based code is usually easier to read than code
> where the registrations are separate. :)
>
>> Writing ZCML sucks, but it sucks if you do it with vim, emacs or
>> whatever editor you like. If we had a ZCML-aware IDE, it would be
>> possible to build a valid ZCML-file with a few mouse clicks.
>
> I myself don't believe in automating away redundancy with code generation,
> if the code generated is something a human being needs to look at.
>
> Plus we don't have a ZCML-aware IDE, and even if we magically had one, we
> won't be able to make everyone use it.
>
> I think there is another tool that helps people explore the workings of an
> application: the introspection tool. This is a tool we actually can build
> and are building. If an introspection tool can show which adapters and views
> are registered for an object, this should help tremendously in understanding
> an application's architecture.
>
>> If you take the ZCML-files as a blueprint of your application, it seems to
>> me a clean tool to master really big an complex applications. I cannot
>> foster this with my own experience, but I've heard people say that ZCML
>> saved their lives.
>
> Well, I have never heard people say that, myself! I've heard people indicate
> that ZCML helped them understand the application before, yes. It hasn't
> really greatly helped me; I find when exploring a new library I stare at the
> doctests and interfaces.py and the code and the ZCML files all, and then
> have to think quite hard to get a picture of what's going on.
>
> I haven't heard people with experience with Grok say that Grok makes it
> *harder* than ZCML.
>
> We don't have a lot of experience with a component architecture introspector
> yet.
>
> I'd say it's incorrect to say that ZCML-files are a "blueprint" of any kind
> of your application. By themselves they don't mean very much at least in my
> experience.
>
>> And from a marketing point of view these statements are really bad. How
>> shall I solicit Zope, if more and more people tell me that the tool that
>> hold all these components together sucks? How shall I convey trust to the
>> public, if the Zope guys start to build up a new framework every five years?
>
> The whole idea is that Grok *isn't* a new framework. It's Zope 3, with some
> conveniences, an attitude towards better beginner documentation, and a new
> way to glue things together. Grok could go so far so fast *because* it's
> built on Zope 3. We've never denied this. Grok is new in the ways we can get
> marketing and community benefits from it, and it is old in the ways we can
> reuse lots of great ideas and code.
>
> Zope 3 to me isn't defined by ZCML; the ZCML aspect is just a very small
> part of it. I imagine ZCML looks bigger than it is to many people because
> it's so different and it's so in your face, so you can't help to think about
> it when you think about Zope 3. It might as a result obscure the underlying
> framework more than it helps show its inner workings. It surely makes the
> learning curve a lot steeper early on.
>
>> Let Grok smash ZCML, it is nice to have more than one way to build web
>> applications, but don't curse ZCML.
>
> I didn't see Robert curse Zope 3 or ZCML, just saying it's dead. :)
>
> The funny thing is that Grok uses almost *all* of ZCML's machinery expect
> the XML-based directive parser, which is replaced by Martian. The actions
> that ZCML directives produce are produced by Grok as well, and are
> compatible with them. Grok's configuration system was only possible as we
> had an established, well-known base to build it on.
>
> One of Grok's major features is that it gets rid of the separate file XML
> description of how things are glued together and replace it with in-python
> code declarations instead, with rules for defaults of many of them so you
> don't have to learn them all at once. I believe Grok's way is a better way.
> We can't promote that without saying something negative about separate file
> XML configuration. Criticism, yes. Cursing, no, but I didn't see people
> curse it.
>
> You admit yourself you're not speaking from personal experience concerning
> ZCML. I'd say, don't praise ZCML too much either, then.
>
> Regards,
>
> Martijn
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev@...
> http://mail.zope.org/mailman/listinfo/grok-dev
>

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

[Philipp von Weitershausen]

Martijn Faassen wrote:

> Hey,
>
> Robert Gravina wrote:
> [snip]
>> Being able to override configuration is very powerful... perhaps I
>> should learn a bit more about ZCML and the motivations behind it
>> before declaring it dead :) I'll go dust off my copy of Weitershausen
>> and spend some quality time with it I think :)
>
> While you do this, perhaps you'd like to investigate the following for
> us. ZCML has an 'includeOverrides' directive. This allows you to include
> a ZCML file that overrides the configuration you already have, for
> instance registering a different view with the same name.
>
> For a long time I thought that Grok lacks this feature, but recently I
> realized that it probably does, as it's fully compatible with ZCML now.
>
> Here's a sketch of the experimental setup:
>
> You could have two modules, a and b, and a configure.zcml and a
> configure_b.zcml. Now in configure.zcml you simply use the ZCML grok
> directive to grok module a. Then you do an includeOverrides of
> configure_b.zcml, in which you use the grok directive to grok module b.
> In module b you have a different view for the same context and with the
> same name and layer, just displaying a different text. If
> includeOverrides works, you should get no configuration conflict and you
> should see this second view. If this works, Grok supports overrides. :)

I can assert that this does work. Of course Grok supports overrides.
What else... :)

ME GROK OVERRIDE ZCML

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev

Let me abuse this thread for a comment and a question ..

The comment: I have built and maintain a Zope 3 (plain ZCML) site, on
average there is one ZCML file for every 6 .py files, and only 4 lines
of python per line of zcml! (33k versus 8.5k)

The ZCML does get very verbose at times, and it's very repetitive. Make
an interface, ok, make the actual class, ok, define the class completey
in zcml, the whole permissions (which are fantastic, but do get in the
way at times), cover all attributes, etc. Want a view? Ok, define
everything in zcml, write the view, assign a template, etc.
After a while it does slow you down and it does start to get annoying to
go through the motions just to add a small thing here or there.

Playing with Grok (small so far) is completely different, it really is
very agile to develop with (to drop some buzzwords :), very quick to add
things, and to try out new ideas. Behind the scenes the grokking does
the same as the zcml would do, but it's much more fun because it is so
fast to develop with, it really makes it a lot more fun _because_
development is so convenient.

Some areas where Grok could provide some more functionality itself:
- pluggable authentication with session credentials and principal
signup, basically every site dealing with user accounts needs this.
Although the Zope 3 way is still very easy to do.
- vocabulary support. I never really got the subtleties with sources and
vocabs, my primary use is to make dynamic select dropdown boxes. This
could be made easy and intuitive.
- skinning/macros. It should be easy to drop the default zope3/grok UI,
make a template with header/footer/content/etc areas, and make it easy
to use different layouts for mobile/web/etc. It would be really great if
this could be made easy. The "static" concept in grok is great, but I
can't use it for my main template to refer to javascript since every
package which wants to fill in the "body" slot (for example) causes the
static of the package to be used, instead of the original "global"
static. Viewlet-based on UI's are great but you need a view to make a
page with a different name (for the same object), which most likely
wants to use 99% of the "main" page template.

So summarized: Grok is all the zope 3 goodness, but much more convenient
to work with!


As for my question:

I want to build a menu-bar as a viewletmanager, with viewlets for
entries. Thanks for view permissions, the menu always contains exactly
the right set of menu options for the current user. So far, so good.

In Zope 3, you can build a nice menuitem class based on a viewlet, and
in the zcml register only those derived classes (where you would only
provide a "name" and "link" attribute, and let all the
calculations/layout/etc be done by the menuitem base class). A single
template suffices for the menuitem baseclass.

In grok, if I make a menuitem deriving from grok.Viewlet, it itself is
registered as a viewlet directly, and the derived classes don't get
registered.

I.e.

class menuitem(grok.Viewlet):
        grok.template("menuitem")
        def update(self):
                # Use self.name and self.url
                # Lots of complicated code you do NOT want to repeat for
every menu item

class Home(menuitem):
        grok.name("home")
        name = u"Homepage"
        url = "/"
        grok.require("mysite.VisitHomePage")

In ZCML, you would register "Home" as a viewlet, and all would be well.
In Grok, the grokker groks :) the menuitem itself, and I am not sure the
"Home" would be picked up at all.

I actually use a similar pattern quite often in the original Zope 3
system, and would like to have some equivalent way to do it in grok,
i.e. keeping "Home" as lean as possible and putting as much as possible
in the menuitem class.

I hope that made sense :)

Cheers,
Dennis

_______________________________________________
Grok-dev mailing list
Grok-dev@...
http://mail.zope.org/mailman/listinfo/grok-dev