RE: [fw-general] $db->setRowClass & $db->setRowsetClass

[Bill Karwin]

I worked on more unit tests for Zend_Db_Table/Row/Rowset today.  Code
coverage is now 95% for those classes.

Virtually all the unit tests for Zend_Db are in
/tests/Zend/Db/Adapter/Common.php.  The reason for this is that
test suite is already set up for testing against multiple RDBMS brands,
and I want to make sure that the various tests work against different
RDBMS's.

I still am not able to test against MS SQL Server in my environment,
which is not filling me with confidence.  But I can't afford to spend
more time on it right now.

Regards,
Bill Karwin


> -Original Message-
> From: Art Hundiak [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 20, 2007 5:58 AM
> To: Bill Karwin
> Cc: fw-general@lists.zend.com
> Subject: RE: [fw-general] $db->setRowClass & $db->setRowsetClass
> 
> Excellent.  Kept hoping someone would say "Hey you dummy, the tests
are
> right here".
> >
> > Thanks for catching that bug, Art.
> >
> > For the record, there *are* unit tests for Zend_Db_Table/Row/Rowset.
> > The code coverage is 68%.  Look in
> > /tests/Zend/Db/Adapter/Common.php, there are 37 test
functions
> > matching "testTable*".
> >
> > I wish you would not say that there are no tests for these classes.
It
> > is a false statement.
> >
> > It is true that the line containing the bug was not covered by unit
> > tests.  But it is an exaggeration to say that there are no tests
> > covering the Table/Row classes.
> >
> > Regards,
> > Bill Karwin
> >
> >> -Original Message-
> >> From: Art Hundiak [mailto:[EMAIL PROTECTED]
> >>
> >> Almost as though the code was released without testing.  Which I
guess
> > is
> >> consistent with the fact that there are no DB_Table/Row tests in
the
> >> delivered version.
> >
> >
> 

Re: [fw-general] Where's the YAML parser?

[Pádraic Brady]

I would have used "subset" ;). I use about 50-60% of the available syntax and 
the other 20% while very nice is also very obscure and proportionately more 
difficult to consider implementing. If I write a proposal it's initial aim 
would likely reflect Perl's Yaml::Lite implementation which matches what most 
people use in everyday situations, or even Spyc which I think supports even 
less.

After that I can think about the remaining syntax few people would actually 
use, and add a binding for Syck which should assuage the concerns of the 
performance monkeys in the community who know the extension exists :).

I'd bet that last 10-20% functionality would take a lot of time to implement in 
comparison to the simpler YAML structures.

Paddy
 
Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com


- Original Message 
From: Gavin Vess <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Zend Framework General 
Sent: Tuesday, March 20, 2007 10:51:29 PM
Subject: Re: [fw-general] Where's the YAML parser?

Hi Paddy,

Excellent!  If PHP and ZF both include support for JSON ... all the more 
reason to support a YAML parser (i.e. superset with some nice "extras").

Cheers,
Gavin

[EMAIL PROTECTED] wrote:
> -->
> YAML is light on the ground in PHP. Outside the Spyc library which is 
> bundled with Symfony and used for it's own input filtering 
> configuration, I can't think of another native parser. Syck is pretty 
> much standard in Ruby (as Gavin noted), and has bindings for Perl, 
> Python, PHP, etc. Until a standard core extension for YAML appears, a 
> PHP parser is the only reliable means of adding YAML processing to a 
> PHP application without recompiling PHP with Syck.
>
> If nothing pops up from Bruce (who suggested a YAML parser for the ZF 
> per Gavin's email last Summer) in the next few days I'll take a look 
> at what a parser would require. The YAML spec isn't completely off the 
> wall complicated esp. since hierarchy is dictated by simple 
> indentation and the rest should be a simple variable/array type 
> mapping between YAML and PHP based on the YAML syntax characters. The 
> only complicated bit would be managing parenting properly since the 
> format would be processed top to bottom.
>
> I'll see if I have some free time later in the week to look at it in 
> more detail. If I do I'll submit a proposal so there's something to 
> read once the 1.0 release is made and if it's feasible I'll commit 
> some personal time to developing it. I guess if I want it I might as 
> well add it :).
>
> Paddy
>  
> Pádraic Brady
> http://blog.astrumfutura.com
> http://www.patternsforphp.com








 

Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel 
bargains.
http://farechase.yahoo.com/promo-generic-14795097

Re: [fw-general] Where's the YAML parser?

[Gavin Vess]

Hi Paddy,

Excellent!  If PHP and ZF both include support for JSON ... all the more 
reason to support a YAML parser (i.e. superset with some nice "extras").


Cheers,
Gavin

[EMAIL PROTECTED] wrote:

-->
YAML is light on the ground in PHP. Outside the Spyc library which is 
bundled with Symfony and used for it's own input filtering 
configuration, I can't think of another native parser. Syck is pretty 
much standard in Ruby (as Gavin noted), and has bindings for Perl, 
Python, PHP, etc. Until a standard core extension for YAML appears, a 
PHP parser is the only reliable means of adding YAML processing to a 
PHP application without recompiling PHP with Syck.


If nothing pops up from Bruce (who suggested a YAML parser for the ZF 
per Gavin's email last Summer) in the next few days I'll take a look 
at what a parser would require. The YAML spec isn't completely off the 
wall complicated esp. since hierarchy is dictated by simple 
indentation and the rest should be a simple variable/array type 
mapping between YAML and PHP based on the YAML syntax characters. The 
only complicated bit would be managing parenting properly since the 
format would be processed top to bottom.


I'll see if I have some free time later in the week to look at it in 
more detail. If I do I'll submit a proposal so there's something to 
read once the 1.0 release is made and if it's feasible I'll commit 
some personal time to developing it. I guess if I want it I might as 
well add it :).


Paddy
 
Pádraic Brady

http://blog.astrumfutura.com
http://www.patternsforphp.com

Re: [fw-general] Where's the YAML parser?

[padraic . brady]

YAML is light on the ground in PHP. Outside the Spyc library which is bundled 
with Symfony and used for it's own input filtering configuration, I can't think 
of another native parser. Syck is pretty much standard in Ruby (as Gavin 
noted), and has bindings for Perl, Python, PHP, etc. Until a standard core 
extension for YAML appears, a PHP parser is the only reliable means of adding 
YAML processing to a PHP application without recompiling PHP with Syck.

If nothing pops up from Bruce (who suggested a YAML parser for the ZF per 
Gavin's email last Summer) in the next few days I'll take a look at what a 
parser would require. The YAML spec isn't completely off the wall complicated 
esp. since hierarchy is dictated by simple indentation and the rest should be a 
simple variable/array type mapping between YAML and PHP based on the YAML 
syntax characters. The only complicated bit would be managing parenting 
properly since the format would be processed top to bottom.

I'll see if I have some free time later in the week to look at it in more 
detail. If I do I'll submit a proposal so there's something to read once the 
1.0 release is made and if it's feasible I'll commit some personal time to 
developing it. I guess if I want it I might as well add it :).

Paddy
 
Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com


- Original Message 
From: Matthew Weier O'Phinney <[EMAIL PROTECTED]>
To: fw-general@lists.zend.com
Sent: Tuesday, March 20, 2007 5:48:40 PM
Subject: Re: [fw-general] Where's the YAML parser?

I'd love to see a YAML parser in ZF -- though some might see it as a
further rails-ification of ZF, YAML has many benefits over other config
file formats (such as the readability you note, as well as deeper
nesting than INI, etc.).

I've seen recently that somebody is creating a YAML PHP extension, but I
haven't heard of any written *in* PHP. Anybody want to submit a proposal?
(I'd submit one, but my hands are kind of tied with the other framework
components I lead... ;-) )

-- 
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/







 

Don't get soaked.  Take a quick peek at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather

Re: [fw-general] Where's the YAML parser?

[padraic . brady]

Hi Gavin,

I'll check the mailing list to see if Bruce posted anything subsequently. If 
not I might shoot him an email and see of he's interesting in sharing code.

Pádraic
 
Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com


- Original Message 
From: Gavin Vess <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Zend Framework General ; [EMAIL PROTECTED]
Sent: Tuesday, March 20, 2007 6:14:57 PM
Subject: Re: [fw-general] Where's the YAML parser?

Perhaps Bruno has something? This topic was discussed last Summer (see 
topic thread appended below).

http://www.yaml.org/refcard.html - YAML reference card

http://en.wikipedia.org/wiki/YAML - YAML intro

http://whytheluckystiff.net/syck/ - PHP extension homepage

http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-php5/syck-php-bindings/ 
- Gentoo's ebuild for this PHP extension

Cheers,
Gavin

[EMAIL PROTECTED] wrote:
> I was making suggestions to a fellow ZF user the other day and I 
> noticed Zend_Config has no YAML format parser. Are there any plans to 
> introduce a YAML config format, or does this require a base YAML 
> parser, such as a Zend_Yaml since PHP is currently without an 
> extension for the format?
>
> There are a few places I find the format useful. The one we were 
> discussing was a more readable configuration file for dynamically 
> constructing filter chains and rulesets. Esp. since XML is a bit 
> bloated (yes, it's human editable but such configurations only have a 
> little nesting and XML can come off as overkill when presenting it to 
> a maintainer).
>
> I googled around a bit and the only reference was back months ago 
> where someone posted a modification of the spyc library to the mailing 
> list. 
 Original Message 
Subject: [fw-general] Zend-Yaml challenge taken.
Date: Tue, 27 Jun 2006 02:05:26 +0200
From: Bruno Couleau <[EMAIL PROTECTED]>
Organization: The Phocea Experiment
To: 'Zend Framework General' 

Hi,

At the beginning of the month, I was looking to the 
Zend_Config:XML_Format thread and the idea pops that YAML could be 
useful for some of us… so I quickly wrote an class to able Zend_Config 
to process YAML file using the code from Chris Wanstrath (SPYC), that’s 
the YAML parser used in Symfony.


As I didn’t pay to much attention to the CLA I’ve just upload the file 
as a “quick & dirty” hack… and finally Andi Gutmans friendly challenges 
me writing: ‘Now it's up to you to prove that PHP is much easier than 
.NET :)’.


So after some thinking, I’ve started to write some code but it seems to 
me that it will be better to have a parser implementation distinct from 
Zend_Config able to parse an YAML document very much like SAX does for 
XML … producing events that can be used to call some callback functions. 
It could be useful if the class can also provide an YAML Object to 
internally represents the parsed file and some additional method to 
convert it to an array than can be used with Zend_Config.


So basically I came with this minimal requirements:

- support the YAML 1.1 specification as define on the official web site 
(http://yaml.org/spec/current.html)

- the main class would be responsible for :

o loading & parsing an YAML document form different sources

o calling used defined callback function to handle parsing events (e.g. 
: LIST_OPEN, LIST_CLOSE, MAP_OPEN, MAP_CLOSE, LIST_NO_OPEN, MAP_NO_OPEN, 
DOCUMENT_START, DOCUMENT_END, MAP_SEPARATOR, LIST_ENTRY...) trough an 
event_handler class.

o provide access to the parsed document using alternatives like

§ returning an YAML Document Object

§ returning an PHP array

- the parser would be as much as possible an OOP implementation with 
support for

o a virtual class reader than can be derived to process different 
character stream (e.g.: file processing or http transactions)

o both UTF-8, US-ASCCI & ISO-8859-1 characters sets


So far I’m still working on all this stuff but it came nicely even if 
writing it’s not as easy as we can thing mostly because I had to write 
much of the production rules form the YAML language by hand and I 
haven’t wrote a full parser from scratch for a very long time (By the 
way, if any one knows about YACC or LEX equivalent tools to produce PHP, 
just let me know). For now the UML class diagram look just like this:


Except, for all the Yaml_Parser private functions that are omitted on 
purpose.


Hopefully I will post the first version of the code around 15/07 the 
time to send the Contributor License Agreement and to make some more 
progress in the writing/coding process



If you have some ideas on the subject or could help me to review my 
design, just let me know. I’m also very interested by any suggestion 
like implementing the multi-character sets support… This part doesn’t 
look like a piece of cake to me.


Thank you for reading me.


Bruno Couleau, Marseille – France.









 

Re: [fw-general] Zend_Translate return string to translate

[Thomas Weidner]

In the 0.9 code,  there is two same fonction  _() and translate() that
return same things


Just for simplification...

_() is the same functionality as implemented by the gettext extension but 
the function name is not API conform and was only accepted for 
simplification and backwards compatibility.


translate() is the general translation function... and it's much more logic 
to have


print $class->translate('mystring');

within the code than just a _(); because the long name is self speaking.
Users familiar with php's gettext extension would probably use _()...
I would propose to use the long function name even if it's longer and more 
typing because of it's readability.


Btw:
The code itself is not doubled because _() calls translate()...

Greetings
Thomas
I18N Team Leader 

Re: [fw-general] Zend_Translate return string to translate

[Yann Nave]

On 3/20/07, Thomas Weidner <[EMAIL PROTECTED]> wrote:


> I'm justr trying Zend_Translate, why not juste adding a simple methode
to
> auto echo  translation  ?
>
> And why not return the $messageId if nothing is find ? Like wordpress
> gettext librarie ?

I dont see your problem ???
When you want to translate a text which is not avaiable, EVERY translation
library and also Zend Translate returns the original text/messageId.



Yes it's what I write in my seconde mail.


An additional "echoing" function is nonsense because you can use an empty

adapter.
And when you give the messageID you probably know which text should be
displayed as messageID should be the original text to simplify reading the
code.

For details just look into the documentation where this behaviour is
described.



Juste dispense to add an echo in my view.

In the 0.9 code,  there is two same fonction  _() and translate() that
return same things



--
Yannux
http://blog.onbebop.net

Re: [fw-general] Zend_Translate return string to translate

[Thomas Weidner]

I'm justr trying Zend_Translate, why not juste adding a simple methode to
auto echo  translation  ?

And why not return the $messageId if nothing is find ? Like wordpress
gettext librarie ?


I dont see your problem ???
When you want to translate a text which is not avaiable, EVERY translation 
library and also Zend Translate returns the original text/messageId.


An additional "echoing" function is nonsense because you can use an empty 
adapter.
And when you give the messageID you probably know which text should be 
displayed as messageID should be the original text to simplify reading the 
code.


For details just look into the documentation where this behaviour is 
described.


Greetings
Thomas
I18N Team Leader 

Re: [fw-general] Cleanup Zend_Request

[Kevin McArthur]

getRequestMethod already exists as getMethod()

This is about the convenience methods $this->isPost() is quite convenient. 
as would isGet and isHead


I'm more concerned with the original enhancements I spoke of in terms of 
unifying the getParam and getHeader methods such that they follow the same 
api consistency as getQuery, getPost, getCookie, getServer, getEnv


Right now headers and params follow a different api.

Kevin

- Original Message - 
From: "Matthew Weier O'Phinney" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, March 20, 2007 1:01 PM
Subject: Re: [fw-general] Cleanup Zend_Request



-- Kevin McArthur <[EMAIL PROTECTED]> wrote
(on Tuesday, 20 March 2007, 01:03 PM -0700):
I'm not saying we need full support for PUT, DELETE just yet, but to 
think

that HTTP methods are binary either post or not isn't quite correct. HEAD
requests are of particular importance for modern rss readers for example.
I'd just add an isGet and isHead method at this point and unify the api 
to

be a bit more consistent.


Typically, when I think MVC, I'm not thinking REST or RSS, but those are
valid uses for it as well.

I don't want to clutter the API with a ton of isXXX() methods. I think
it would make more sense to do something like getRequestMethod() that
determines the request method, does some normalization (to lower or
upper case, for instance), and returns that value. Then the developer
can do either simple logic or switch statements:

   if ('post' == $request->getRequestMethod()) {
   // handle post request...
   }

   // or
   switch ($request->getRequestMethod()) {
   case 'post':
   // handle post...
   break;
   case 'head':
   // handle head...
   break;
   // ...
   default:
   throw Exception('Invalid request method');
   }

I'll put this in the issue tracker as an enhancement; likely it will not
go in until post 1.0.

- Original Message - 
From: "Codiac" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, March 20, 2007 2:31 AM
Subject: Re: [fw-general] Cleanup Zend_Request


>
>Kevin,
>
>I know PHP can handle PUT, DELETE and other requests as well. They're 
>just

>not handled the same way as POST and GET. Requests + the body of the
>request
>are always put into the PHP:// stream (like php://input).
>
>The question is will Zend Framework support these type of requests? If 
>you

>look into the REST server implementation, those request types aren't
>supported. Therefore the Zend Server_Rest implementation isn't a
>full-fledged REST implementation.
>-- 
>View this message in context:

>http://www.nabble.com/Cleanup-Zend_Request-tf3424362s16154.html#a9568055
>Sent from the Zend Framework mailing list archive at Nabble.com.
>



--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/ 

Re: [fw-general] Cleanup Zend_Request

[Matthew Weier O'Phinney]

-- Kevin McArthur <[EMAIL PROTECTED]> wrote
(on Tuesday, 20 March 2007, 01:03 PM -0700):
> I'm not saying we need full support for PUT, DELETE just yet, but to think 
> that HTTP methods are binary either post or not isn't quite correct. HEAD 
> requests are of particular importance for modern rss readers for example. 
> I'd just add an isGet and isHead method at this point and unify the api to 
> be a bit more consistent.

Typically, when I think MVC, I'm not thinking REST or RSS, but those are
valid uses for it as well.

I don't want to clutter the API with a ton of isXXX() methods. I think
it would make more sense to do something like getRequestMethod() that
determines the request method, does some normalization (to lower or
upper case, for instance), and returns that value. Then the developer
can do either simple logic or switch statements:

if ('post' == $request->getRequestMethod()) {
// handle post request...
}

// or
switch ($request->getRequestMethod()) {
case 'post':
// handle post...
break;
case 'head':
// handle head...
break;
// ...
default:
throw Exception('Invalid request method');
}

I'll put this in the issue tracker as an enhancement; likely it will not
go in until post 1.0.

> - Original Message - 
> From: "Codiac" <[EMAIL PROTECTED]>
> To: 
> Sent: Tuesday, March 20, 2007 2:31 AM
> Subject: Re: [fw-general] Cleanup Zend_Request
> 
> 
> >
> >Kevin,
> >
> >I know PHP can handle PUT, DELETE and other requests as well. They're just
> >not handled the same way as POST and GET. Requests + the body of the 
> >request
> >are always put into the PHP:// stream (like php://input).
> >
> >The question is will Zend Framework support these type of requests? If you
> >look into the REST server implementation, those request types aren't
> >supported. Therefore the Zend Server_Rest implementation isn't a
> >full-fledged REST implementation.
> >-- 
> >View this message in context: 
> >http://www.nabble.com/Cleanup-Zend_Request-tf3424362s16154.html#a9568055
> >Sent from the Zend Framework mailing list archive at Nabble.com.
> >
> 

-- 
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/

Re: [fw-general] Cleanup Zend_Request

[Kevin McArthur]

I'm not saying we need full support for PUT, DELETE just yet, but to think 
that HTTP methods are binary either post or not isn't quite correct. HEAD 
requests are of particular importance for modern rss readers for example. 
I'd just add an isGet and isHead method at this point and unify the api to 
be a bit more consistent.


Kevin


- Original Message - 
From: "Codiac" <[EMAIL PROTECTED]>

To: 
Sent: Tuesday, March 20, 2007 2:31 AM
Subject: Re: [fw-general] Cleanup Zend_Request




Kevin,

I know PHP can handle PUT, DELETE and other requests as well. They're just
not handled the same way as POST and GET. Requests + the body of the 
request

are always put into the PHP:// stream (like php://input).

The question is will Zend Framework support these type of requests? If you
look into the REST server implementation, those request types aren't
supported. Therefore the Zend Server_Rest implementation isn't a
full-fledged REST implementation.
--
View this message in context: 
http://www.nabble.com/Cleanup-Zend_Request-tf3424362s16154.html#a9568055

Sent from the Zend Framework mailing list archive at Nabble.com.

Re: [fw-general] Where's the YAML parser?

[Gavin Vess]

Perhaps Bruno has something? This topic was discussed last Summer (see 
topic thread appended below).


http://www.yaml.org/refcard.html - YAML reference card

http://en.wikipedia.org/wiki/YAML - YAML intro

http://whytheluckystiff.net/syck/ - PHP extension homepage

http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-php5/syck-php-bindings/ 
- Gentoo's ebuild for this PHP extension


Cheers,
Gavin

[EMAIL PROTECTED] wrote:
I was making suggestions to a fellow ZF user the other day and I 
noticed Zend_Config has no YAML format parser. Are there any plans to 
introduce a YAML config format, or does this require a base YAML 
parser, such as a Zend_Yaml since PHP is currently without an 
extension for the format?


There are a few places I find the format useful. The one we were 
discussing was a more readable configuration file for dynamically 
constructing filter chains and rulesets. Esp. since XML is a bit 
bloated (yes, it's human editable but such configurations only have a 
little nesting and XML can come off as overkill when presenting it to 
a maintainer).


I googled around a bit and the only reference was back months ago 
where someone posted a modification of the spyc library to the mailing 
list. 

 Original Message 
Subject: [fw-general] Zend-Yaml challenge taken.
Date: Tue, 27 Jun 2006 02:05:26 +0200
From: Bruno Couleau <[EMAIL PROTECTED]>
Organization: The Phocea Experiment
To: 'Zend Framework General' 

Hi,

At the beginning of the month, I was looking to the 
Zend_Config:XML_Format thread and the idea pops that YAML could be 
useful for some of us… so I quickly wrote an class to able Zend_Config 
to process YAML file using the code from Chris Wanstrath (SPYC), that’s 
the YAML parser used in Symfony.



As I didn’t pay to much attention to the CLA I’ve just upload the file 
as a “quick & dirty” hack… and finally Andi Gutmans friendly challenges 
me writing: ‘Now it's up to you to prove that PHP is much easier than 
.NET :)’.



So after some thinking, I’ve started to write some code but it seems to 
me that it will be better to have a parser implementation distinct from 
Zend_Config able to parse an YAML document very much like SAX does for 
XML … producing events that can be used to call some callback functions. 
It could be useful if the class can also provide an YAML Object to 
internally represents the parsed file and some additional method to 
convert it to an array than can be used with Zend_Config.



So basically I came with this minimal requirements:

- support the YAML 1.1 specification as define on the official web site 
(http://yaml.org/spec/current.html)


- the main class would be responsible for :

o loading & parsing an YAML document form different sources

o calling used defined callback function to handle parsing events (e.g. 
: LIST_OPEN, LIST_CLOSE, MAP_OPEN, MAP_CLOSE, LIST_NO_OPEN, MAP_NO_OPEN, 
DOCUMENT_START, DOCUMENT_END, MAP_SEPARATOR, LIST_ENTRY...) trough an 
event_handler class.


o provide access to the parsed document using alternatives like

§ returning an YAML Document Object

§ returning an PHP array

- the parser would be as much as possible an OOP implementation with 
support for


o a virtual class reader than can be derived to process different 
character stream (e.g.: file processing or http transactions)


o both UTF-8, US-ASCCI & ISO-8859-1 characters sets


So far I’m still working on all this stuff but it came nicely even if 
writing it’s not as easy as we can thing mostly because I had to write 
much of the production rules form the YAML language by hand and I 
haven’t wrote a full parser from scratch for a very long time (By the 
way, if any one knows about YACC or LEX equivalent tools to produce PHP, 
just let me know). For now the UML class diagram look just like this:



Except, for all the Yaml_Parser private functions that are omitted on 
purpose.



Hopefully I will post the first version of the code around 15/07 the 
time to send the Contributor License Agreement and to make some more 
progress in the writing/coding process




If you have some ideas on the subject or could help me to review my 
design, just let me know. I’m also very interested by any suggestion 
like implementing the multi-character sets support… This part doesn’t 
look like a piece of cake to me.



Thank you for reading me.


Bruno Couleau, Marseille – France.

Re: [fw-general] Where's the YAML parser?

[Matthew Weier O'Phinney]

-- [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote
(on Tuesday, 20 March 2007, 10:40 AM -0700):
> I was making suggestions to a fellow ZF user the other day and I noticed
> Zend_Config has no YAML format parser. Are there any plans to introduce a YAML
> config format, or does this require a base YAML parser, such as a Zend_Yaml
> since PHP is currently without an extension for the format?
> 
> There are a few places I find the format useful. The one we were discussing 
> was
> a more readable configuration file for dynamically constructing filter chains
> and rulesets. Esp. since XML is a bit bloated (yes, it's human editable but
> such configurations only have a little nesting and XML can come off as 
> overkill
> when presenting it to a maintainer).

I'd love to see a YAML parser in ZF -- though some might see it as a
further rails-ification of ZF, YAML has many benefits over other config
file formats (such as the readability you note, as well as deeper
nesting than INI, etc.).

I've seen recently that somebody is creating a YAML PHP extension, but I
haven't heard of any written *in* PHP. Anybody want to submit a proposal?
(I'd submit one, but my hands are kind of tied with the other framework
components I lead... ;-) )

-- 
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company   | http://www.zend.com/

RE: [fw-general] Zend_Log status

[Bill Karwin]

Hi Jonathan,

 

Yes the new OO redesign of Zend_Log should be ready very soon, and move
to core.  I would like it to be in the 0.9.1 Beta refresh by the end of
this week.  Certainly by ZF 1.0.

 

There are just a couple of internal implementation details still to be
refined, but the interface is pretty much finished.  I think it is
stable enough to start using it.

 

I think it would be awkward to write logging code using the current
static class and then have to rewrite it using the new interface.

 

Regards,

Bill Karwin

 



From: Jonathan Kart [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 20, 2007 10:17 AM
To: Zend Framework General
Subject: [fw-general] Zend_Log status

 

Hi All, 

I'm about to start integrating an extensive logging system into an
existing application.  I know that Zend_Log is in the process of being
reimplemented as a non static system.  I noticed the 0.9 release doesn't
have the new logging system (it's still in the incubator).  So that
leaves me with a few questions: 
1. What's the state of the Zend_Log rewrite in the incubator?  Is it
stable enough to begin using?
2. Are there plans to move the rewrite into the core before the 1.0
release?
3. Failing question #1, is it difficult to port original Zend_Log code
to the new system?  Should we being using the logger in the core now and
just port later when the new logger is moved from the incubator? 

I know many this depends on the specifics of my project, I'm just
looking for general suggestions on whether to proceed with the current
version, use the incubator version,  or wait for the rewrite to
complete. 

Thanks!
-Jonathan

[fw-general] Where's the YAML parser?

[padraic . brady]

I was making suggestions to a fellow ZF user the other day and I noticed 
Zend_Config has no YAML format parser. Are there any plans to introduce a YAML 
config format, or does this require a base YAML parser, such as a Zend_Yaml 
since PHP is currently without an extension for the format?

There are a few places I find the format useful. The one we were discussing was 
a more readable configuration file for dynamically constructing filter chains 
and rulesets. Esp. since XML is a bit bloated (yes, it's human editable but 
such configurations only have a little nesting and XML can come off as overkill 
when presenting it to a maintainer).

I googled around a bit and the only reference was back months ago where someone 
posted a modification of the spyc library to the mailing list.

Regards,
Paddy
 
Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com





 

It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

Re: [fw-general] Great work with 0.9

[padraic . brady]

This is probably the fifteth or sixteth ;).

I started with the framework last Summer and since then it has grown 
increasingly essential to my work. I won't be giving up Symfony for an 
exclusive stable of ZF applications but it's well in there and I'm able to 
place a lot of trust on the framework. I think trust is under-rated in PHP 
given the glut of frameworks and the ZF is a very cool standard which is 
accessible to even beginner coders. I know a lot of us can't wait to see other 
stuff enter the core post-1.0 so there's lots more to look forward to. I also 
look forward to contributing in my own way - I can't just take without giving 
something back.
 
Pádraic Brady
http://blog.astrumfutura.com
http://www.patternsforphp.com


- Original Message 
From: Teemu Välimäki <[EMAIL PROTECTED]>
To: fw-general@lists.zend.com
Sent: Monday, March 19, 2007 6:55:26 PM
Subject: [fw-general] Great work with 0.9

Thank you so much!

What can I say, I'm developing several big applications which ZF and even with 
the API changes from 0.8 took a while to fix I applaud for them. Sure there are 
bugs and inconsistencies both in manual and the framework itself but it does 
not make it unusable. I understand that people want to be on the bleeding edge 
and so on but lets give the developers a break with a cookie or two.

Just think about where you would be without ZF. Maybe writing filter for user 
input? Maybe some SQL? Maybe implementing your version of ACL and Auth? Yes, it 
can be fruitful to do those for personal experience but in a business world 
that's simply a no-no.

Let's all take a break with a cookie :)







 

Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367

[fw-general] Zend_Log status

[Jonathan Kart]

Hi All,

I'm about to start integrating an extensive logging system into an existing
application.  I know that Zend_Log is in the process of being reimplemented
as a non static system.  I noticed the 0.9 release doesn't have the new
logging system (it's still in the incubator).  So that leaves me with a few
questions:
1. What's the state of the Zend_Log rewrite in the incubator?  Is it stable
enough to begin using?
2. Are there plans to move the rewrite into the core before the 1.0 release?
3. Failing question #1, is it difficult to port original Zend_Log code to
the new system?  Should we being using the logger in the core now and just
port later when the new logger is moved from the incubator?

I know many this depends on the specifics of my project, I'm just looking
for general suggestions on whether to proceed with the current version, use
the incubator version,  or wait for the rewrite to complete.

Thanks!
-Jonathan

[fw-general] Re: Zend_Translate return string to translate

[Yann Nave]

On 3/20/07, Yann Nave <[EMAIL PROTECTED]> wrote:


Hye everybody,

I'm justr trying Zend_Translate, why not juste adding a simple methode to
auto echo  translation  ?

/**
 * Translate And Echo the given string
 *
 * @param  string  $messageId  Original to translate
 * @param  string|Zend_Locale  $locale OPTIONAL locale/language to
translate to
 * @return print string
 */
public function _e($messageId, $locale = null)
{
echo $this->_adapter->translate($messageId, $locale);
}

?

And why not return the $messageId if nothing is find ? Like wordpress
gettext librarie ?



Hum sorry, I've just seen that it do that, I forgot my echo. So just an e_()
? :)




--
Yannux
http://blog.onbebop.net

[fw-general] Zend_Translate return string to translate

[Yann Nave]

Hye everybody,

I'm justr trying Zend_Translate, why not juste adding a simple methode to
auto echo  translation  ?

   /**
* Translate And Echo the given string
*
* @param  string  $messageId  Original to translate
* @param  string|Zend_Locale  $locale OPTIONAL locale/language to
translate to
* @return print string
*/
   public function _e($messageId, $locale = null)
   {
   echo $this->_adapter->translate($messageId, $locale);
   }

?

And why not return the $messageId if nothing is find ? Like wordpress
gettext librarie ?

My 2cents :)
--
Yannux
http://blog.onbebop.net

RE: [fw-general] $db->setRowClass & $db->setRowsetClass

[Art Hundiak]

Excellent.  Kept hoping someone would say "Hey you dummy, the tests are
right here".
>
> Thanks for catching that bug, Art.
>
> For the record, there *are* unit tests for Zend_Db_Table/Row/Rowset.
> The code coverage is 68%.  Look in
> /tests/Zend/Db/Adapter/Common.php, there are 37 test functions
> matching "testTable*".
>
> I wish you would not say that there are no tests for these classes.  It
> is a false statement.
>
> It is true that the line containing the bug was not covered by unit
> tests.  But it is an exaggeration to say that there are no tests
> covering the Table/Row classes.
>
> Regards,
> Bill Karwin
>
>> -Original Message-
>> From: Art Hundiak [mailto:[EMAIL PROTECTED]
>>
>> Almost as though the code was released without testing.  Which I guess
> is
>> consistent with the fact that there are no DB_Table/Row tests in the
>> delivered version.
>
>

Re: [fw-general] improvement in Filters with external input.

[Drew Bertola]

Doctorrock wrote:
> Now consider this use :
> GET /mypage.php?my_message[]='Hi' HTTP 1.1
> (...)
> 
> Zend_Filter_StringToLower::filter($_GET['my_message']);
> 
> Note that my_message is passed as an array, anyone can modify the type
> of params in the URL for a GET request, thus generating in that case a
> *Notice *: Array to string conversion in *my\file\dot\php* on line my_line.
> 
> Some of you would say that it's the programmer's job to cast the GET
> variable manually type before passing it to the filter, by I personally
> think that the filter function should do it by itself, as it expects a
> string in all cases, and nothing else...

I'd rather have it so that an exception is thrown (the way it is now, no?).

My reasoning is that if I make a coding blunder and pass an array (it
happens!), it will be caught rather than converted to a string and,
potentially passed to a validation chain, accepted, and entered into
storage.  All sorts of things could go wrong.

--
Drew

Re: [fw-general] Cleanup Zend_Request

[Codiac]

Kevin,

I know PHP can handle PUT, DELETE and other requests as well. They're just
not handled the same way as POST and GET. Requests + the body of the request
are always put into the PHP:// stream (like php://input).

The question is will Zend Framework support these type of requests? If you
look into the REST server implementation, those request types aren't
supported. Therefore the Zend Server_Rest implementation isn't a
full-fledged REST implementation.
-- 
View this message in context: 
http://www.nabble.com/Cleanup-Zend_Request-tf3424362s16154.html#a9568055
Sent from the Zend Framework mailing list archive at Nabble.com.