Login | Register
My pages Projects Community openCollabNet

propel
Reply to message

* = Required fields
* Subject
* Body
Attachments
Send reply to
Topic
Author (directly in email)
Please type the letters in the image above.

Original message

Author Christian Kassab <chris.kassab@gmail.com>
Full name Christian Kassab <chris.kassab@gmail.com>
Date 2007-07-19 13:41:31 PDT
Message On 19/07/07, Pedram Nimreezi <zenstyle at gmail dot com> wrote:
> I couldn't help it, I have to respond to that...
>
> I currently debug propel / creole / rapid framework with ntail in eclipse...
> in fact, eclipse has two good features it gives you for the 200 megs of ram
> it wants to use. A file / directory explorer... and this ntail plugin that
> lets
> you look at ansi (colored) logs... generated by Pear::Log which has been
> available since the very beginning in propel... color with ansi where
> context is needed.,
>
> There is no reason why xdebug can't be used.. in fact... Eclipse's
> file/directory
> manager just launches vim for me on the file... I can then at my leisure hit
> F5
> and rerequest a page on the site... passing of course that
> /XDEBUG_SESSION_START=
> flag... this starts an interactive debugging session inside that vim
> window... how
> that works is a mix of vim scripting and python and is really another
> discussion.
>
> however, that's a different usage of xdebug but my point is, you can use it
> or not
> use it.. you can also use eclipse or not use it... if whatever diagnostic
> assertions
> can be added to propel with some degree of effeciency then add it but don't
> dismiss
> it out of hand. in fact I like propel / creole php4 better than what's
> current.... but I don't
> try to make everyone use that, even though it's more stable and faster. And
> works
> right in php4 and php5, with other optimizations like 95% of include_once's
> removed
> including other optimizations that are fundamental to opcode caching... why?
> because
> its like putting a gag order on development....
>
> > If you really need the lower level debugging inside Propel then add it
> > in a non obtrusive way by enabling dependency injection of classes
> > that subclass the default ones but add the debugging functionality and
> > then call the parent methods etc.
>
> that's your two cents? I think that's just a buzz word conjugation....
and here's another dime: if you think they are just buzz words, how
would you then describe the best practice? Instead of commenting on my
'buzz words' you could give us an alternative...
>
> anyway I think refactoring propel into a php extension is the futureproof
> solution.
this sounds like something that might work. what about actually
extending PDO for this?
Whilst we are at it, how about a mapping configuration so you don't
have to touch the classes/objects you want to persist in the db? I
like a domain model that isn't fully aware of all the dependencies to
whatever persistence engine is used. AOP maybe? Ups another 'buzz
word' :-)
>
> and it should be able to use mysql/pgsql extensions on php4 and pdo on
> php5...
>
> that's an opinion I will support...
>
>
>
> On 7/19/07, Christian Kassab <chris dot kassab at gmail dot com> wrote:
> > Hi,
> >
> > why stuff so much debugging functionality into Propel? It is bloated
> > as it is already. How about using debugging tools like xdebug and
> > Eclipse? Yes I know you can't look into what goes on inside PDO as in
> > what the final query string looks like after binding the
> > variables/parameters, but thats another story...
> >
> > If you really need the lower level debugging inside Propel then add it
> > in a non obtrusive way by enabling dependency injection of classes
> > that subclass the default ones but add the debugging functionality and
> > then call the parent methods etc.
> >
> > Cheers,
> >
> > Christian
> >
> > On 19/07/07, Hans Lellelid <hans at velum dot net> wrote:
> > > Oliver Schonrock wrote:
> > > > Cameron Brunner wrote:
> > > >> Silence is good bad or otherwise?
> > > >
> > > > Don't take offense please. I like the features, but I am not sure
> about
> > > > the implementation:
> > > >
> > > > - using static $query seems untidy
> > > > - using __destruct() can cause problems depending on your environment
> > > > - using direct var_dump() it not always suitable.
> > > >
> > > > if we are going to add this to the core propel repository, my view
> would
> > > > be that it should meet the same criteria as the rest of the code as a
> > > > generic, high quality toolkit.
> > > >
> > > > Part of the reason I focused on simple features was that it is not
> > > > obvious how to solve some of the above problems with the more advanced
> > > > features while adhering to the quality standards of the rest of the
> > > > code. ie can run in any environment, etc..
> > > >
> > > > Opinions?
> > >
> > > Without having looked at the code, I second this opinion. We definitely
> > > don't want to use var_dump, for instance, as this is not particularly
> > > useful when building webapps that don't return HTML (i.e. that return
> > > XML/XML-RPC, JSON, etc.).
> > >
> > > My input would be that we need the default PropelPDO to be as
> > > unencumbered as possible (fast). If we're going to keep all the debug
> > > stuff in a separate object, then it doesn't matter much how that
> > > performs. If, however, the aim is to merge this into PropelPDO, then we
> > > need to make sure that we're doing things in an optimized -- and yes,
> > > "correct" -- way. We definitely don't want to open the door for subtle
> > > PHP issues.
> > >
> > > One thing I have learned from using Propel + PDO in PHP 5.2.2 is that
> > > PDO is not particularly bug-free :) I have dealt with a number of
> > > segfaults that are directly traceable to PDO. Sometimes it is the
> > > result of a malformed query (why this segfaults, I have no idea) --- or
> > > use of PDO streams within user-defined stream wrappers. I *hate*
> > > debugging segfaults in PHP; what a waste of time. There's apparently
> > > some really messy stuff under the hood there :) Let's do what we can to
> > > keep it from rearing its ugly head for users.
> > >
> > > Hans
> > >
> > >
> --------------------​--------------------​--------------------​---------
> > > To unsubscribe, e-mail:
> dev-unsubscribe@prop​el.tigris.org
> > > For additional commands, e-mail: dev-help at propel dot tigris dot org
> > >
> > >
> >
> >
> > --
> > Christian Kassab
> >
> > Mobile:
> > +44 (0)789 4467 606
> > +49 (0)163 6360 939
> >
> > Mail:
> > chris dot kassab at binaryworx dot net
> > chris dot kassab at gmail dot com
> >
> > Web:
> > http://www.binaryworx.net
> > http://www.shoreflyer.net
> >
> >
> --------------------​--------------------​--------------------​---------
> > To unsubscribe, e-mail: dev-unsubscribe@prop​el.tigris.org
> > For additional commands, e-mail: dev-help at propel dot tigris dot org
> >
> >
>
>
>
> --
> ~
> Pedram Nimreezi
>


--
Christian Kassab

Mobile:
+44 (0)789 4467 606
+49 (0)163 6360 939

Mail:
chris dot kassab at binaryworx dot net
chris dot kassab at gmail dot com

Web:
http://www.binaryworx.net
http://www.shoreflyer.net