incubator-zeta-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Pic <>
Subject Re: [zeta-dev] Documentation
Date Wed, 12 Jan 2011 13:55:33 GMT
On Wed, Jan 12, 2011 at 12:26 PM, Gaetano Giunta
<> wrote:
> James Pic wrote:
>> What lib/program/framework does it better than the components and why ?
> Completely unrelated, but the Delphi VCL is the lib I have the fondest
> memories of.

Thanks for your great input!

I've picked a random documentation page:

I must admit, that a tutorial to create a paint program, is way more
exciting than for
example the hello world tutorial.

On Wed, Jan 12, 2011 at 1:44 PM, Maxime Thomas <> wrote:
> 2011/1/12 Gaetano Giunta <>
>> James Pic wrote:
>>> On Wed, Jan 12, 2011 at 8:46 AM, Christian Grobmeier
>>> <>  wrote:
>>>  Maybe we
>>>>>> must
>>>>>>    consider the fact to create a false dependancy to Debug, disabled
>>>>>>    default.
>>>>> What would be the benefits of that over xdebug ?
>>> I insist for your own good, maybe the source of your problem is not
>>> specific to the components... are you sure you're using xdebug
>>> correctly ?
>> A pertinent question: is xdebug considered a strict requirement for doing
>> zetaC development?
> I can see a limitation of the use of XDebug, but maybe you can correct me
> and teach me how to solve this one :
> I'm developping under Windows with Eclipse like most of the dev and I'm
> running my LAMP stack inside a VM with.
> My project is a shared folder mounted via network.
> XDebug can help me to debug the Apache PHP script but not the cli ones with
> my configuration ?
> If it does the trick, we can just write this down and put it in a FAQ / side
> subjects.

There are many ways, please overview the official documentation before

You should set:

xdebug.remote_host="the ip of your machine that has the IDE"

Using your favorite IDE, you can set breakpoints in advance in files.
That said, xdebug_break() often proves useful as well.

Also, you can set xdebug.remote_autostart="1"
if you want to make sure it starts every time php starts.

I think the trickiest part of xdebug remote debugging is to understand that:

0) is the DBGP *client*, it must connect to the server
1) your IDE is the DBGP *server*, it must listen for incoming client connections

My last advice is: use strace (or alternative from your OS) for troubleshooting.

It's important to know if:

0) the client (your http server) connects to the right ip on the right
port (default is 9000)
1) the server listens on the right ip (ie rather than and port

> A relevant question: is xdebug considered a strict requirement for doing
> zetaC development?

Depends. Most of the experienced coders will consider a debugger as a
strict requirement for comfortable development (amongst other stuff like TTD,
SCRUM etc ...).

It is however required for ZetaC core development, ie. if you want to contribute
back your features, bugfixes etc ...

I however, as a professional coder like probably every one on this
list, am payed
to write code and to maintain it and to debug it so at the end of the day i'm
actually payed to use a debugger. It has been that way for years. And man, I
love working with xdebug and the components (amongst other things like
vim or git).

Thus, as a professional, i'd expect you to be paid to use a debugger instead of
trying to log/print/output debug info with temporary codes.

That said, i don't care if xdebug is a requirement or whatnot. If you
my friend, need
some assistance with using xdebug, then feel free to just pop in #zetacomponents
or query me "jpic" on freenode, like Derick and others from the powerful eZC
community helped me during years ;)

So i'll return the question: should it the role of ZetaC to document good coding
practices such as usage of a VCS or a debugger to users ?

I'd tend to say: why not after all. Diversifying our activity could
improve the end
user experience. *BUT* in that case, should it really be the
responsibility of the
Apache Zeta Components project ? Or should another project document and try
(thus, try to unify) actual PHP development with "the full gear" ?

> In short, PhpUnit just failed to test Zeta's exceptions objects, and neededI'd say yes.
> an explicit bootstrap to do the job. UnitTests provides such a bootstrap
> file, unfortunatly UnitTest is'nt part of the Zeta's PEAR packages yet, and
> I just missed this point. I don't know if including the UnitTest into PEAR
> is roadmapped for now. I think newbie dev like me need a short paragraph in
> the Zeta tutorials, something like "How to implement PhpUnit tests into your
> Zeta-based App"

Are you talking about this 15-liner ?

Needless to say, you can check or to access
documentation of pretty much everything in this file.

In fine, don't you think that we should actually document how to
develop with Zeta Components,
rather than documenting the components themselves ?

Why should the docs cover xdebug and not subversion or even filesystems ?

Maybe we want to consider writing a book that would guide the user
through the realisation of
a project, pretty much like djangobook, delphi vlc, "pragmatic guide
to javascript".

It does sound like a lot of work, but i'd agree it's worth a shot ...

> Otoh debugging Symfony for 3 days brought me to the conclusion that the
> smartness of the code that Fabien likes to write puts it beyond mere mortals
> comprehension, and no advantages gained in reduced lines of code,
> extensibility and execution speed are worth it in the end (this was
> confirmed by reading his slide set about dependency injection in php 5.3).
> But maybe it's just me getting old and having a hard time learning new
> styles / paradigms... :-)

Thanks for this great feedback as well, you totally made my day :D

Customer is king - Le client est roi - El cliente es rey.

View raw message