incubator-zeta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronan Guilloux <>
Subject Re: [zeta-dev] Documentation
Date Tue, 11 Jan 2011 13:39:17 GMT
+1 for all that Maxime wrote about.

But my very first need & tweet was simpler : How to add a set of cronjobs,
and how to add a PhpUnit test suite into a HelloMvc-like website (cf. .

Adding cronjobs is easy, but this should be documented or shown in an
example a day, since it's a common need. I'll try to improve my frenchy
globish english a write a decent tutorial about that, somehwere, some day.

The main difficult I encountered was to implement PhpUnit easely. Some weeks
ago I crawled the all Zeta Components example apps (here : but I didn't found any app implementing PhpUnit yet.
PhpUnit doc about bootstrapping was not clear enough to me. but reading the
UnitTest bootstrap.php file (found here : helped a lot
and it finally did the job. Unfortunatly, while UnitTest is listed in the
official Zeta Components docs, it's a broken link in the official doc (here

Implemeting PhpUnit into Zeta Components needs a tutorial, and I'm still a
PHPUnit rookie to write it.
Any candidate for that ?

Ronan Guilloux

2011/1/11 Maxime Thomas <>

> Hi,
> As started on Twitter with @arno_u_loginlux, we think that the ezc / azc
> documentation can be improved in several ways.
> As an end-user of this library / framework, I like the spirit of it and the
> way you can quickly adopt a component and use it in your software.
> However, regarding the documentation, for more than one year that I'm using
> mostly all components and I think we can complete it / improve it.
> I list here my thoughts about the documentation and you may feel free to
> add
> or challenge each point. In my opinion, each component have to get the
> following piece of information (if it hasn't yet) :
>   - a schema : a visual way to understand the concepts underneath. We get
>   it one for MVC which was cool because it's I guess the most complex one
> but
>   I think it's not enough.
>   - a list of examples, which can be like the PHP documentation, user
>   contributed. The aim is to provide example of the real life or specific
> use
>   that are not specified in the built-in specification.
>   - a method that can be used to easily debug the code. Typical dev does
>   not want to get in the ezc code but just use it. It's a bit problematic
> to
>   know if there's a real bug inside the component or if it's a bad usage we
>   are making of it. For example, I use PersistentObject and I would like to
>   know why the find query returns me nothing. In the documentation, there's
> no
>   clue to that could help me to resolve my probleme. And also, there's no
> way
>   to print the $q->getQuery() without hacking PersistentObject. Maybe we
> must
>   consider the fact to create a false dependancy to Debug, disabled by
>   default.
> By resolving this, I guess we will increase the number of user.
> I know that it is a significant effort on documentation but it will have a
> great effect on users.
> --
> Maxime
> | |

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message